Signalr: Rewrite JavaScript bindings to no longer depend on jQuery
The current JavaScript bindings rely on jQuery >1.5 to be included with the page. Since many people use different JavaScript Frameworks (e.g. dojo, extjs) it's not optimal to force people to additional include such a heavy library as jQuery just for signalR to work.
See also:
371
328
cburgdorf
All 191 comments
Feel free to send a PR for this change.
davidfowl
on 9 May 2012
Its bad that there is no upvotes on github. +1 here
SlyNet
on 26 Dec 2012
@SlyNet I agree they should have votes.
davidfowl
on 26 Dec 2012
+1
youngcm2
on 14 Feb 2013
Ideally all the framework-specific stuff should be refactored into a single "adapter" file, so you'd have the core SignalR stuff, and an adapter library that "connects" SignalR to your preferred framework. Look at how History.js does it for example: https://github.com/browserstate/history.js/tree/master/scripts/uncompressed
The core SignalR libraries should have no dependency on jQuery, and there should be a "native" adapter for people that aren't using a JavaScript library.
Daniel15
on 15 Mar 2013
+1, really frustrating to have to include bulky jquery file just for a few bindings when using different framework
gerardtoconnor
on 5 Sep 2013
A very big +1 from me to. We are succesfully using SignalR for mobile applications, but the footprint of jQuery is a problem.
jeppebemad
on 5 Sep 2013
We are hoping to remove our jQuery dependency in an upcoming release.
DamianEdwards
on 5 Sep 2013
It's really frustrating having to use jQuery with SignalR. I would much rather plain old JavaScript (I use TypeScript, which compiles into plain JavaScript). jQuery is too large a library; too heavy and too slow. Edit: I just noticed the last comment about it being removed.
iateyourtoothpaste
on 18 Sep 2013
Yep, we're making steps towards making this a reality. It's targeted for 2.1.0 beta https://github.com/SignalR/SignalR/issues/milestones
davidfowl
on 18 Sep 2013
Sorry, couldn't help myself :grin:
shiftkey
on 9 Oct 2013
@Daniel15 +1 for adapters idea.
Misiu
on 10 Oct 2013
Oh dude this is awesome news. Thanks so much for all your hard work and for removing the jQuery dependency.
Sent from my iPhone
On 11 Oct 2013, at 1:58 am, tjagusz [email protected] wrote:
@Daniel15 +1 for adapters idea.
—
Reply to this email directly or view it on GitHub.
iateyourtoothpaste
on 11 Oct 2013
yes the jquery dependency is the only thing keeping me from using it in my new project since I need to keep my current script (and what it depends on) as small as possible. Thanks for the hard work! I can't wait until it's ready.
levipage
on 17 Oct 2013
+1
DBarnesTX
on 4 Dec 2013
Any updates on this one?
Many of us can test it and write adapters for different frameworks.
Thanks to this feature SignalR will become even more popular!!!
Misiu
on 17 Dec 2013
Looking forward this, as well!
dhont
on 22 Dec 2013
+1
camazorro
on 31 Dec 2013
Will the issue solved in the milestone for 2.1.0 beta ?
JoergTiedemann
on 11 Apr 2014
@JoergTiedemann nope
davidfowl
on 11 Apr 2014
What actually needs to be done for this to happen? Exactly what jQuery
functionality does SignalR use?
Sent from my mobile.
On Apr 11, 2014 9:35 AM, "David Fowler" [email protected] wrote:
@JoergTiedemann https://github.com/JoergTiedemann nope
Reply to this email directly or view it on GitHubhttps://github.com/SignalR/SignalR/issues/372#issuecomment-40223497
.
Daniel15
on 11 Apr 2014
@Daniel15 we're doing a client rewrite along with this work. Today, signalr uses deferred, ajax and events.
davidfowl
on 11 Apr 2014
So is it possible to use signalr in webworker thread without using jquery Framework?
Or how can i use signalr in a webworker ?
JoergTiedemann
on 11 Apr 2014
@JoergTiedemann we need to remove jQuery first, then look at any other changes that would need to be made to support SignalR in a webworker. In short, not possible using our library today.
DamianEdwards
on 11 Apr 2014
Yes but at which release it is planned to remove jquery ?
JoergTiedemann
on 11 Apr 2014
@DamianEdwards anything new here?
Misiu
on 10 May 2014
Has this been removed from the next version milestones for some reason? It's such a strange dependency with the current state of JavaScript libraries with so many other options to get the functionality you need. I love SignalR but having to include JQuery well.. sucks :(
shaunol
on 28 May 2014
Yes
the only question is, in what Release will the jquery dependency removed ?
JoergTiedemann
on 29 May 2014
+1 it would be nice to be independent.
joeuy
on 13 Jun 2014
Removing jquery dependency is the only Way to use signalr in a webworker.
JoergTiedemann
on 13 Jun 2014
Any updates? You were saying "It's targeted for 2.1.0 beta" but I can't see anything in the release notes.
w3apps
on 23 Jun 2014
@w3apps If you check out the earlier comments, it states it will not be part of the 2.1.0 beta.
levipage
on 23 Jun 2014
Also would like to have this feature.
Developers of SPA no longer need jQuery, because most MV* client frameworks no depend on it. Now I need to reference jQuery only for SignalR usage...
bukharin
on 23 Jun 2014
It's been 2 years since this issue was posted.
When can we expect this feature? v2.1.0 was released on 21 May.
Will v2.2.0 have this? Or maybe v9.0.not_going_to_happen?
@DamianEdwards wrote on 5 Sep 2013
We are hoping to remove our jQuery dependency in an upcoming release.
Anything happened since then?
Can we have official statement on this one please?
Misiu
on 23 Jun 2014
Yes we need a official statement
Removing jquery dependency is the only way to use signalr in a webworker and this seems to be the only solution to use signalr and together with the web API at safari mobile because of the problem safari only allows one web server connection
So it's time to make a official statement about the date and version the jquery dependency will be removed
JoergTiedemann
on 23 Jun 2014
Also hoped to version 2.1...maybe with 3.0 we will be able to forget about jquery
Dubnovitsky
on 23 Jun 2014
Guys, we're a small team. We're prioritizing work based on perceived customer impact. We want this change as much as anybody but it's not trivial. We have some higher priority client work we need to complete first (e.g. getting WebSockets across all platforms) but removing jQuery is now the _top_ priority for the JS client in terms of feature work. Note it's the same dev working on all the clients, so it takes time. Our current hope is to at least start the process of removing jQuery during this summer (USA) with a view to it being complete by end of year. It might be earlier, it might not, but that's the current lay of the land.
DamianEdwards
on 23 Jun 2014
Awesome thanks for the update @DamianEdwards - I think an earlier comment about it being included in the 2.1 milestone and then subsequently removed without an update in here is causing confusion. No stress.
shaunol
on 23 Jun 2014
Sounds good, but if its one of the issues with top priority it should be included as an issue in one of the milestones
JoergTiedemann
on 24 Jun 2014
We'll move this to the new repo for v3.
DamianEdwards
on 24 Jun 2014
Sorry, can't see any milestones or issues in that repo if I follow the link
JoergTiedemann
on 24 Jun 2014
@JoergTiedemann right, the comment says "we'll", as in "we will", as in, in the future. I'm going through this repo and scrubbing the issues in preparation for our move to the new aspnet org. It's a large process. but rest assure we're working through it.
DamianEdwards
on 24 Jun 2014
+1
Just a little something for folks who are going to attempt it: I once transformed a jQuery code to native JS. Imo, a relatively convenient way is to make helpers for most frequently used jQuery functions (not the whole library). That will keep the vanilla JS size slimmer. Also, keeping the helper function names similar would make refactoring of code comparatively quicker.
am11
on 10 Jul 2014
I'm very interested in that. Could you post some sample code and the transformed lib please.
JoergTiedemann
on 10 Jul 2014
Here is the thing; in order to make it cleaner and keep it readable, it needs to be hand-written code. Few suggestions:
- Just start from one edge, you can think about several refactoring ways as you go about it.
- Try not to use the Yolda logic, but try not to be very verbose either.
- Some magical JS solutions to common problems (for instance validating numericality) bring about significant improvements which library implementations itself uses. (Search on Web. Hint: Stackoverflow is your friend).
- Find the most effective way of doing things, preferably what jQuery is using itself.
- Since it is a vanilla JS and chances are you will end up with a large code base, so maximize code reusability by drawing out commonalities as you go forward.
- Again, make sure you are using the best approach for each common task and not just the working solution.
- Since there are probably eight files to convert here, you can use a _common.js for the reusable code and use some bundling mechanism to join them. OR
- If you like it, comfortable with it and guys here are ok with it, use the superset JS like TypeScript. It will make the code much cleaner and super natural for OOP-savvy folks. You might want to create a nested TS project inside SignalR. which would be most effective approach due to number of reasons (hint: benefits of using superset languages in first place -- TS, CoffeeScript, livescript, SweetJS etc.)
am11
on 10 Jul 2014
@am11 @JoergTiedemann I did the same thing with the Chosen UI library and started working on a "native" version that doesn't depend on any JavaScript libraries (see https://github.com/harvesthq/chosen/pull/1394) although didn't finish it myself due to a lack of time.
Rather than using TypeScript, I'd suggest using ES6 features (like arrow functions and classes) due to the fact that browsers will implement them natively in the future. For now, you need to transpile your JavaScript through something like JSTransform or Esprima.
Daniel15
on 10 Jul 2014
@Daniel15, this is a good idea. But I think the TypeScript code would still be the better choice due to the level of abstraction it has to offer.
From https://typescript.codeplex.com/discussions/446695:
We're still planning to align with the ES6 module system when it lands. The external module system in TypeScript is fairly decoupled from the rest of the language in that it's a pretty clear opt-in. For ES6 modules, we'd likely add it to the language _without replacing the existing system_. They fill different roles. The external modules that TypeScript currently supports target RequireJS and CommonJS, which isn't the focus of ES6 modules.
Also, if it comes to that, you can just use JS code in the .ts file and it will output the code as is.
Benefit: ability to write full object-oriented code. (except for the lack of abstract classes, which is a downer..)
am11
on 10 Jul 2014
@DamianEdwards you mention "getting WebSockets across all platforms" - does this include Win2008 R2? Would really like to have that.
moity
on 28 Jul 2014
@moity that comment was in the context of the .NET client, not the server. SignalR 3 is based on ASP.NET vNext which will support WebSockets in self-host scenarios (i.e. non-IIS) on Win2008R2 by way of a new custom web server. Unfortunately if you're on IIS the requirement for Windows Server 2012 remains.
DamianEdwards
on 28 Jul 2014
That's sad news, Win2008R2 and IIS hosting has to be one of the most common hosting scenarios for an ASP.NET solution today, and for the next few years. To be able to take advantage of WebSockets would be a huge benefit for those struggling with the connection limit issues SSE brings.
I'm working on a large enterprise application that users typically open a lot of tabs for, after the introduction of Signalr users ran into the connection limit very quickly. I've had to write a custom solution for keeping one tab connected at a time and using localStorage as a message bus but it's fair from ideal. The application only supports modern browsers which all support WebSockets (IE10 and above, Chrome and Firefox latest etc.)
Using a third-party WebSocket Server e.g. Fleck works a treat, both client and server are very simple, the issue is deployment. Adding inbound firewall rules for the custom port Fleck runs on is not an option, and I've had no luck with rewrite rules to hide the implementation.
moity
on 28 Jul 2014
@moity You can't use rewrite rules for WebSockets as it's a totally separate protocol to HTTP (and additionally, rewrite rules will still go through IIS' HTTP handling so you'd still reach the connection limit). IIS doesn't understand the protocol so it wouldn't know how to forward it.
You could use a third-party WebSocket server on port 80 on a different IP address, which would not require any custom firewall rules and should work as expected. This requires a separate IP address that you're not using for IIS, though. I don't have much experience with WebSockets + Windows + IIS, but most larger public implementations of Linux-based WebSocket servers are set up this way since the long-running connections (including long polling, server-sent events and WebSockets) are handled by a separate server farm more optimised for long-running connections. Quite often this is done with a separate subdomain (eg. www.example.com for the site and ws.example.com for WebSockets).
Daniel15
on 29 Jul 2014
@Daniel15 you can include the protocol in rewrite rules to avoid the default http(s):// coming through, but I take your point about requests still going through IIS' HTTP handling and I believe Win2008R2 takes issue with ws(s):// at this point.
I'm aware of the other options around sub domains and sites on another IP so they can still run on port 80 but this brings with it further deployment issues. Unfortunately, I need to keep the deployment story as simple as possible (which it is using out-of-the-box signalr - other than the connection limit issue).
moity
on 29 Jul 2014
@moity You can include the protocol in URL rewrite rules, but that won't help if IIS doesn't understand the protocol. Cross-protocol rewriting doesn't really make sense - How would you rewrite from HTTP to FTP or SMTP for example? WebSockets is a separate protocol that is separate to HTTP, just like FTP and SMTP :)
Daniel15
on 29 Jul 2014
@Daniel15 Yep I'm aware they are different protocols.
I was attempting to do the following, expose externally (port 443):
wss://example.com/sockets
rewritten to internally:
wss://interalsocketserver:8182
Effectively hiding the socket server running on the non standard port. As you say IIS doesn't seem to understand the protocol.
moity
on 29 Jul 2014
+1
mchambaud
on 13 Aug 2014
+1
I'm tempted to try @am11's suggestion and submit a PR, but I'm working against a deadline and will probably have to work around this for now (put the SignalR code in the UI thread and forward all received messages to the worker).
LarsKemmann
on 13 Nov 2014
+1
tedvanderveen
on 13 Nov 2014
+1
PeterOrneholm
on 9 Dec 2014
Is there anything news about a date, the javascript signalr client is available without using jquery ?
JoergTiedemann
on 22 Dec 2014
+1 again
tedvanderveen
on 22 Dec 2014
+1 after 3 years we need to have this
meirb
on 28 Dec 2014
According to JS theorists, in coming years jQuery shall be obsoleted. See jQuery R.$.P.
Besides, last time I checked, there were only 8 files to convert and we are 7 billion out there!
Lets fix this. :dart: :zap:
am11
on 28 Dec 2014
Is this done yet? Really need this.
jjfood
on 8 Jan 2015
I'd also like to see SignalR without jQuery dependency.
Side note: if I read this thread right, this issue has been the top SignalR feature priority for over 6 months with no comment during that time, and zero commits on the new repo in that time. Strictly professionally, it makes me unsure about adding SignalR dependencies to my project.
syndicatedshannon
on 21 Jan 2015
@syndicatedshannon True +1
tedvanderveen
on 21 Jan 2015
+1
RyanDansie
on 22 Jan 2015
This was asked on May 2012. As @syndicatedshannon wrote, there is nothing in new repo.
Is it even possible to have this in 2015?
@DamianEdwards any updates on this?
Misiu
on 27 Jan 2015
+1
- jan. 2015 16:21 skrev "Tomek" [email protected] følgende:
This was asked on May 2012. As @syndicatedshannon
https://github.com/syndicatedshannon wrote, there is nothing in new
repo.
Is it even possible to have this in 2015?
@DamianEdwards https://github.com/DamianEdwards any updates on this?—
Reply to this email directly or view it on GitHub
https://github.com/SignalR/SignalR/issues/372#issuecomment-71664891.
larsfjerm
on 27 Jan 2015
+1
mcaroul
on 3 Feb 2015
+1
noobouse
on 4 Feb 2015
@halter73, @DamianEdwards, @NTaylorMullen, @davidfowl, @gustavo-armenta,
If someone submits a PR for this, will you guys even accept it?
Do you even recognize that there exists a demand to make SignalR JS client a top-level library, independent of jQuery? window.signalR instead of $.signalR (or window.jQuery.signalR).
To convince someone that jQuery dependency in 2015 is not a good idea, here is another one: checkout when was the last time the original jquery creator @jeresig wrote the code: https://github.com/jquery/jquery/graphs/contributors. It was 2011! So please Do NOT use jQuery or anything similar (MooTools, underscore, whatnot) AT LEAST in the library development. We spend HOURS to develop jQuery-free native code and then SignalR **s on the effort. If YOU don't care and in love with jQuery so much, then use it in your own projects, not in the library to give choice to people who like to live with latest times (in which SignalR is rendering itself obsolete for this very reason)...
ghost
on 4 Feb 2015
+1
daniellmb
on 11 Feb 2015
+1 this just made me not use SignalR for my new project
goranobradovic
on 12 Feb 2015
+1 @goranobradovic - we would love to use SignalR in our projects as well but since we are a pure JS shop we cannot use it. Depending on any external JS library like jQuery is completely out of the question.
mdlar
on 13 Feb 2015
+1
srivathsah
on 16 Feb 2015
@halter73, @DamianEdwards, @NTaylorMullen, @davidfowl, @gustavo-armenta guys could we at least get any information on this?
SignalR is grate, but when we want to use it current implementation is forcing us to use jQuery.
This must definitively change, especially if You want to make SignalR more popular.
Misiu
on 16 Feb 2015
@jasonwilliams200OK I get the feeling @jeresig has left kind of left jquery. So I wouldn't count that as an argument against it. It still is a team out of 40+ members.
But yeah, I agree no dependency on jquery would be nice, mostly because the you can use it in WebWorkers and similar. On the other hand I can understand why the depend on jquery, the are not only using web sockets, if I understand it right there are many different ways how you can connect to SignalR and I would bet it was easiest to accomplish that with jquery.
DerKnerd
on 23 Feb 2015
@DerKnerd the lesson is: _if you want to use jQuery, use it in your project but do not make it a dependency in a widespread library code_. Try to get used to this idea, it will only give you a positive advantage.
ghost
on 23 Feb 2015
@jasonwilliams200OK I know, I didn't wanted to say it is good to make a jquery dependency ;) It was just the thought, this project is kinda old, so it is understandable that it depends on jquery.
What bugs me a bit, I don't see SingalR as a framework, which does UI manipulation and that is a point where I would say "Why jquery?" I fully see it, even nowadays, in projects like bootstrap.
@DamianEdwards Maybe the approach angular uses is useful for SignalR, just use jqLite and put it directly in your library.
Edit: Don't misunderstand me, I don't want to say jquery is a good dependecy.
DerKnerd
on 23 Feb 2015
I don't see SingalR as a framework, which does UI manipulation
Exactly! Besides Bootstrap is also getting obsolete with the upcoming web components era, where we will be able to consume components from different vendors (as opposed to tied to one forever!).
How about replacing the jquery.signalr it with TypeScript classes and package the compiled JavaScript output in releases? It will take care of old browser and ECMA5 compatibility and soon provide forward compatibility for ECMA6..
SignalR team can always ask the TypeScript team for some help, only if they are interested..
ghost
on 23 Feb 2015
+1 @jasonwilliams200OK for suggesting Typescript :)
tedvanderveen
on 23 Feb 2015
Besides Bootstrap is also getting obsolete with the upcoming web components era
wat? Bootstrap is a CSS framework, I don't see how it relates to web components at all. Sure there's some (objectively low quality) jQuery plugins included but the majority of Bootstrap is its CSS. Web components certainly does not obsolete CSS.
Daniel15
on 23 Feb 2015
Any news? This feature was requested almost 3 years ago :disappointed:
Misiu
on 9 Mar 2015
Folks... There are two scenarios here under which we're going to get any news on this. 1) The ASP.NET team makes enough progress that the SignalR v3 work can be staffed, or at least details promised... i.e. we wait until July/August. 2) One of us has the time to go do the work ourselves and submit a pull request.
I recommend we stop harassing the team - they're busy working on ASP.NET 5. :)
LarsKemmann
on 9 Mar 2015
@LarsKemmann is correct. We're heads down on the SignalR C++ client and ASP.NET 5. We hope to tackle the JS client as soon as we've wound up work on getting SignalR v3 (for ASP.NET 5) done.
DamianEdwards
on 9 Mar 2015
@DamianEdwards Fantastic. :)
LarsKemmann
on 9 Mar 2015
+1
mguadarrama
on 31 Mar 2015
+1 we have client scripts that need to be small an till now avoided including jQuery and just using pure JS to minimize footprint. Ill just have to write some simple polling separately until the client initiates full app that is launched in a frame. We want to minimise load time for clients.
ppumkin
on 4 Apr 2015
Maybe it's an option to use jqLite? A much more compact library that covers a subset of jQuery. If SignalR only depends on the jQuery API subset provided bij jqLite, it should not be too hard to replace.
https://github.com/angular/angular.js/blob/master/src/jqLite.js
Added bonus for AngularJS projects that use SignalR that jqLite comes built in.
tedvanderveen
on 4 Apr 2015
@tedvanderveen , Ahh very good alterantive! But, I just finished implemented minfying and gzip :) I get 32kb of jQuery 1.10 .. the same size of the jqLite file. I rather stick with the full jQuery. I made a script that checks if the client already has jQuery loaded, if not I pull my own jQuery file in, then SignalR and then do what I need to. Combined its about ~45kb with Jquery 1.10 and SignalR 2, minified and gzipped. gzip header maker the whole difference., just minified is ~90kb.
I kind of understand why SignalR team preffers to use jQuery, as the jQuery team can deal with all the broswer quirks, offloading a big amount of work from the team at signalR and allowing them to focus on new features on the core design. Its not that bad if implemented like I did. If somebody has got slow internet, they will know they must wait, otherwise its pretty fast and painless.
ppumkin
on 4 Apr 2015
@ppumkin jqLite would be 5kb minified&gzipped. Plus much less JS code that the browser needs to load/initialize. Most important question would be, does jqLite cover all methods that the SignalR code depends on.
tedvanderveen
on 4 Apr 2015
NPM ref: https://www.npmjs.com/package/jqlite
And like I said, it may make SignalR a better fit for AngularJS projects as that comes with jqLite built in.
tedvanderveen
on 4 Apr 2015
Yup, that is actually really great. Atleast there are some options that a dev team can make now. For myself, I preffer to load the entire gzipped jQuery, because then I can use it on the script that loads on the client to do all the nasty business. I tried not to use it, to keep it small... but if it loads once then its cached, no problem for me. If we change all out sites to load from a specific jquery CDN, then any site the user visits, will cache it and we don't even need to re download it again, as long as we use the same "src" each time. We got many apps integrating all over the place.
But if the absolute requirement is to minimize the download footprint, then, absolutely, your jqLite suggestion is great and I will keep it in mind too.
As I said before though, I preffer the SignalR team get on with new features in SignalR and not waste time with the client script, because the jQuery team know what they doing. Everybody works in tandem and the web is becoming a great place to be in.
End of the day, a good benchamrk is to see how much data your site loads on first load, minus the size of jQuery... and does it weigh up? If my DOM and images are about ~500kb ... then another 45kb isn't that bad. On next load everything is cached in the browser nicely any way.
ppumkin
on 4 Apr 2015
@ppumkin I very much respect your view here, and on fast enough machines and proper CDN usage, it does not really have a big impact to use JQuery. But I still find it kinda abusive to depend on a huge library like JQuery if only 1% of it's functionality is actually used. The browser does have to load and initialized the other 99%.
This is an issue specially when developing for older/less powerful (mobile) devices or low-bandwidth (mobile) connections.
Best solution would be refactor SignalR code to replace JQuery functionality with vanilla JS, or as a (temporary) solution deploy a lighter replacement for the JQuery dependency.
tedvanderveen
on 4 Apr 2015
@tedvanderveen I feel your pain, I suppose if I really needed to deliver compact files I would have a really difficult task ahead of me, re factoring SignalR and jQuery, breaking maintainability.
I suppose the problem, in essence is that it has a hard dependency on jQuery, period. I think if the SignalR team dedicate some time to maybe, remove the hard dependency on jQuery and allow an alternative library to be loaded, which implements the core functionality. Because if I went and found all the methods SignalR needs, and create my own namespaced library, I still have to call it $.jQuery otherwise signalR wont load, even though the implementation is exactly the same, just stripped down. But if I call it $.jQuery, and a remote unknown client loads jQuery on their page, everything breaks.
In C# for example this can be be easily achieved with Interfaces, IoC and DI. But we are talking about scripting languages here.
I suppose an easy fix, would be to accept an extra option during SignalR construction, to change the namespace it is calling the methods from (or by default leave jQuery), so that a lean library can be maintained by open source or created by developers. This would even allow for middle ware "interfaces" to be made, for example create a file that maps calls to another library and back, for the truly advanced.
So this would allow us to deliver minimum scripting with the highest scrutiny for bandwidth, without breaking signalR, allow the developers to extend core methods to do things they wanted instead of standard jQuery implementations or just use jQuery if we wanted to by default.
I think if the SignalR team can do this, they will be paving the road for many other scripts that rely on this library or that library and nothing else, instead of allowing us to choose what will implement the core functionality.
ppumkin
on 4 Apr 2015
(sigh) One more time. @ppumkin and @tedvanderveen -- did you bother to read Damian Edwards's comment? They will get to it. If you need something immediately, do it yourself. Preferably correctly, removing any 3rd-party library dependency at all, and then submit a PR like David Fowler suggested, oh, three years ago next month? :-)
(As a gentle reminder, most of us pay exactly $0 for the benefit of using the SignalR team's hard work.)
To any future +1ers - unless you have something valuable to contribute, please don't spam the developers with unnecessary arguing for the merits of doing something that they have already expressed interest in doing for a long time.
LarsKemmann
on 4 Apr 2015
We Just debating. I saw the comment and many more +1 after it. Like pages.
Just put a final statement and close this thread.
Thanks SingnalR team. This is truly amazing what you all have done. Sorry
for the spam.
On Sat, 4 Apr 2015 at 16:49 Lars Kemmann [email protected] wrote:
(sigh) One more time. @ppumkin https://github.com/ppumkin and
@tedvanderveen https://github.com/tedvanderveen -- did you bother to
read Damian Edwards's comment? _They will get to it. If you need
something immediately, do it yourself._ Preferably correctly, removing
any 3rd-party library dependency at all, and then submit a PR like David
Fowler suggested, oh, three years ago next month? :-)(As a gentle reminder, most of us pay exactly $0 for the benefit of using
the SignalR team's hard work.)To any future +1ers - unless you have something valuable to contribute, _please
don't spam the developers_ with unnecessary arguing for the merits of
doing something that they have already expressed interest in doing for a
long time.—
Reply to this email directly or view it on GitHub
https://github.com/SignalR/SignalR/issues/372#issuecomment-89602870.
ppumkin
on 4 Apr 2015
@LarsKemmann : Speaking only for myself here, my comment was about the lack of information. If someone announced this was postponed indefinitely, then it might make sense for someone else to step in and contribute, as you suggested. Until then, it's hard to know what to do. The last comment I saw here from Damian Edward was that it was a top priority, was being moved to a linked repo, and the provided link was still empty a year later.
Regarding "most of us pay exactly $0", my impression from the "Copyright (c) Microsoft Open Technologies, Inc." was that this is an MS-backed product, and therefore indirectly funded by our investment in our platforms. My apologies if I got that wrong, but you can see where the confusion might arise.
I was simply concerned about the future of the product. My choice to use it was based partly on the very MS backing I thought it had. That means, to me, that I don't have to debate whether or not I have any right to have consumer-type expectations about the stability and predictability of the product. If that backing had dried up, I wanted to make other choices.
I mean no offense by any of this, and would love to know if I'm misunderstanding.
syndicatedshannon
on 4 Apr 2015
Also, thank you very much @DamianEdwards for the update.
syndicatedshannon
on 4 Apr 2015
I knew I would pay for adding that remark... :) @syndicatedshannon, my point was that the team has publicly acknowledged the need and clearly intends it as a priority for post-SignalR V3 work. Of course SignalR is supported as part of the ASP.NET platform (the team already publicly committed to V3 last summer), and if this was a critical issue it would have received more direct attention.
The fact that it's been a known issue for 3+ years - and in all that time no one has posted a fix here - suggests that people have been making do and there are at least some manageable workarounds. Not ideal, maybe not even "good", but by and large acceptable.
@am11, if you want to submit a pull request, be creative and find a way. Fork and post a link, see if they don't reopen the issue and merge your fix. Sure it would be nice if they reopened the issue and tagged it, but they've been clear that it's going to be fixed in a different repo in the future. No one is "playing hide and seek" here.
LarsKemmann
on 4 Apr 2015
+1
tonymayoral
on 12 Apr 2015
+1
oliverjanik
on 14 Apr 2015
No one is "playing hide and seek" here.
Matter of fact, they are doing poor job making us believe otherwise!
be creative and find a way
Your own advice applies to you as much as to anyone else :)
ghost
on 18 Apr 2015
+1 please. This has been ignored for a long time now.
groovy21
on 20 Jul 2015
As a note for others not using jQuery for anything else, if you are using WebPack, you can use this technique to just load in Deferred, Ajax and Events modules. Should cut down on what you are bringing in quite a bit (i.e. not sizzle, dom stuff, etc).
avanderhoorn
on 25 Jul 2015
@avanderhoorn interesting! Would that technique also allow for trimming down on jQuiry bloat even furtherfor functionality that is already available through jQLite (which comes with Angular)?
tedvanderveen
on 26 Jul 2015
Great question. I would have to do a test. I use underscore/lodash for
other things in my app and I've been thinking of having a proxy which goes
through to it instead, but at this point in our dev cycle just getting it
working is enough and knowing that it can be trimmed down.
On Sunday, July 26, 2015, Ted van der Veen [email protected] wrote:
@avanderhoorn https://github.com/avanderhoorn interesting! Would that
technique also allow for trimming down on jQuiry bloat even furtherfor
functionality that is already available through jQLite (which comes with
Angular)?—
Reply to this email directly or view it on GitHub
https://github.com/SignalR/SignalR/issues/372#issuecomment-124966965.
avanderhoorn
on 26 Jul 2015
+1
Cliveburr
on 27 Aug 2015
+1
anuccio1
on 31 Aug 2015
+1
DJHightower
on 1 Sep 2015
So we are switching over to React, and including all of jquery for just signalR is not great. Luckily SignalR relies on a very small subset of jquery, so its pretty easy to shim out for anyone else in the same situation as us
I hand waved past ajax a bit, but you can find a bunch of jquery compatible xhr libs like component-ajax on npm. Sorry its all in ES6 javascript.
import ajax from './ajax';
import Promise from 'bluebird';
function fakeQuery(subject){
let events = {};
if (subject && subject === subject.window)
return {
0: subject,
load: (handler)=> subject.addEventListener('load', handler, false),
bind: (event, handler)=> subject.addEventListener(event, handler, false),
unbind: (event, handler)=> subject.removeEventListener(event, handler, false)
}
return {
0: subject,
unbind(event, handler){
let handlers = events[event] || [];
if (handler){
let idx = handlers.indexOf(handler);
if (idx !== -1) handlers.splice(idx, 1)
}
else handlers = []
events[event] = handlers
},
bind(event, handler){
let current = events[event] || [];
events[event] = current.concat(handler)
},
triggerHandler(event, args){
let handlers = events[event] || [];
handlers.forEach( fn => fn.call({ type: event }, ...args))
}
}
}
window.jQuery = Object.assign(fakeQuery, {
ajax,
noop(){},
isFunction: o => typeof o === 'function',
isArray: arr => Array.isArray(arr),
type: obj => typeof obj,
trim: str => str && str.trim(),
extend: (...args) => Object.assign(...args),
each: (arr, cb) => arr.forEach((v, i)=> cb(i, v)),
isEmptyObject: obj => !obj || Object.keys(obj).length === 0,
makeArray: arr => [].slice.call(arr, 0),
Deferred(){
var resolve, reject;
var promise = new Promise(function() {
resolve = arguments[0];
reject = arguments[1];
});
return { resolve, reject, promise: ()=> promise };
},
support: {
cors: ('withCredentials' in new XMLHttpRequest())
}
})
jquense
on 3 Sep 2015
The idea is to "break" the dependency on jQuery. Shimming the jQuery features with a "slim version of jQuery" will be a bad idea IMO because it will mislead people to think "SignalR already includes jQuery library, so I don't need to include it separately and still use jQuery in other parts of project". Trust me, an average .NET developer is full of misleading concepts about JavaScript.
Starting over with independent "new SignalR()" kind of sleek API without even impregnating window is the best way to go here. Providing node.js style callback for async signatures would be a big plus!
From consumer's perspective:
var SignalR = require('SignalR'); // for commanJS (node.js compatible) / requireJS etc.
// a good library provides both patterns, with and without the above line
var signalR = new SignalR();
var options = signalR.fetchOptions(); // returns some options object {}
/// sync version
var result = signalR.someFuncSync(options);
if (result.error) {
// throw / log and return etc.
}
// now do something with result
/// the async version
signalR.someFunc(options, function(err, result){
if(err) {
// throw / log and return etc.
}
// now do something with result
});
AFAICS, this style is very popular among people familiar with node.js. This approach is also popular with those JS libraries which entertain both with and without module-loader targets. Reinventing new conventions / styles etc. or sticking with old-school jQuery style does not help fixing this situation. (there are how many, like over a billion npm packages out there using this pattern, right? and every morning you get like 1000 new packages.. sounds to me like no rocket science here!!)
This also means (retired) people who want to use jQuery will still be able to jQuerify the plain signalR object ($(signalR)).
So please, at least:
NO JQUERY DEPENDENCY OR JQUERY-LIKE _ANYTHING_ WITHIN YOUR LIBRARY IMPLEMENTATION!
ghost
on 4 Sep 2015
@jasonwilliams200OK
Shimming the jQuery features with a "slim version of jQuery" will be a bad idea IMO because it will mislead people to think "SignalR already includes jQuery library, so I don't need to include it separately and still use jQuery in other parts of project"
I think @jquense is just doing that so he can use the current version of SignalR without bundling jQuery or modifying SignalR's JavaScript library itself. He didn't mean to suggest actually bundling a jQuery shim with SignalR itself :)
Providing node.js style callback for async signatures would be a big plus!
Callbacks aren't really ideal, you can easily get into callback hell with callbacks inside callbacks inside callbacks. We have better patterns now, and SignalR should be treated as a modern library. Async/await or at least promises is where it's at now.
Daniel15
on 4 Sep 2015
@Daniel15, thank you for "quickly" nitpicking on the "hellish" parts of my proposal on 2012 post, which eveidently nobody at @Microsoft care about. And thank you for ignoring the fact I am highlighting that if there are over a million libraries doing one way and SignalR embracing that pattern will not be a fiasco!
Callbacks aren't really ideal
You said it twice. I have no idea where you are coming from, but I wouldn't jump to this conclusion..
Regarding callback vs. promises (proposed for Ecma6 ?) and RxJS (proposed for Ecma7 ?) etc., I have no objection, but if your library is riding the node-style callbacks bandwagon today, there will definitely be an upgrade path to promises pattern and then to reactive extensions, when those will get adapted by wide range of browsers, node.js, atom-shell runtimes. Today using promises means "another" dependency to polyfill IE8,9 etc.
I hope you know as much as I do that this is not the first discussion happened on github about callbacks vs. promises vs. RxJS. But if you insist, we can invite more "credible" people here and further delay the real matter at hand.
So please chill!
ghost
on 4 Sep 2015
I think @jquense is just doing that so he can use the current version of SignalR without bundling jQuery or modifying SignalR's JavaScript library itself. He didn't mean to suggest actually bundling a jQuery shim with SignalR itself
lol yes of course. the code is for anyone who can't wait for SignalR to not include jquery, and want the least intrustive way of getting it to work without jquery. Obviously signalR itself should not ship a shimed jquery lite...
The other point was just to illustrate how little of jquery the js client actually uses, it doesn't do any DOM stuff (except for window.load) so the idea that there is some large cross browser interop issue requiring jquery is not true.
jquense
on 4 Sep 2015
sooooooo over a year since this issue was closed, and the repo that was listed is still empty and hasn't been updated since May... Is anyone still looking at this issue, or is it a sort of zombie?
Ixonal
on 29 Sep 2015
+1
TopoSolutions
on 30 Sep 2015
Its not going to happen.. just let it go... and load jquery, or jquery
lite, or check if the client has jquery already loaded.
On Wed, 30 Sep 2015 at 08:16 benjamineberle [email protected]
wrote:
+1
—
Reply to this email directly or view it on GitHub
https://github.com/SignalR/SignalR/issues/372#issuecomment-144311248.
ppumkin
on 30 Sep 2015
3565
perhaps all ms members unsubscribed from this issue after it was closed, and are simply unaware that a lot of people still desire a formal place to follow status on it.
the problem is the trail of authoritative comments sets expectation for further information that has not materialized
syndicatedshannon
on 30 Sep 2015
+1
sharizard
on 30 Sep 2015
+1
wilgert
on 2 Nov 2015
We are currently working on a rewrite of the SignalR JS library using ES6 and javascript modules. It is still definitely a work in progress, but we hope to have a stable build within the next couple of weeks. We are also working on a new generator that will produce Redux action creators and action types for both server and client side calls (when using Hub
austinsc
on 3 Nov 2015
@austinsc this looks great ! do you have any sample to show before the docs come out ?
BlueInt32
on 13 Nov 2015
@austinsc, great work! Instead of ES6, can we have a old ES code files to keep it compatible with IE7+?
I don't think there is much code which needs ES6 features. You can then do a pull request here with zero breaking changes. :)
ghost
on 13 Nov 2015
http://blog.delib.net/3-reasons-you-need-to-transition-off-ie7-and-ie8-asap/
No, stick with ES6 and stop supporting obsolete stuff, otherwise you just creating another anchor to stay in the past. jquery 2 dropped all the old garbage. If you want to support obsolete software, do it at your own cost.
ppumkin
on 13 Nov 2015
No, stick with ES6 and stop supporting obsolete stuff,
How about IE9 and IE10? They don't support ES6 either. Dropping jQuery is the focal point here, not orphaning majority browsers!
ghost
on 13 Nov 2015
They getting nuked soon too. I stopped supporting IE because it was frying my brain. My job, as a developer is allot easier now. IE cant be the root cause of not going forward. Cut the cord loose and all of a sudden there are beautiful solutions. Somehow any other major browser does not have this issue....
not orphaning majority browsers
Seriously? You must be a government contractor in China.
But I suppose if there were a way to add support for unsupported browsers that would be nice... its a tough one.
ppumkin
on 13 Nov 2015
What issue really?
Have you even seen SignalR javascript files?
They don't need any of the ES6 or ES7 features. But if you want to screw things up as a mission then that is a separate story.
ghost
on 13 Nov 2015
@jasonwilliams200OK You can transpile to ES5 so what's the problem?
wilgert
on 13 Nov 2015
@wilgert
This is totally correct, It's called Babel.
@ppumkin
Also totally correct, from personal experience, please do not be afraid to tell you customers to join the 21st century, we did and now most of our customers are on Chrome, FF, Opera or even IE 10+. If you don't you are just pandering to their laziness and paying for it dearly.
Good work guys, you are making the right decision in implementing ES6, keep it up.
zardoz
on 13 Nov 2015
:+1:
ppumkin
on 13 Nov 2015
@zardoz, IE10 and even Chrome does not implement full set of ES6. If you tell any library developer (try lodash for example) to switch to ES6 just for fun, while the code can still easily be written with ES5 set in favor of Babel, I don't think you would convince anyone in 2015.
Besides, SignalR's JS client provides long polling fallback for communication with old browsers, going by your logic, should we also remove that feature (since the latest greatest browsers implement WebSocket and friends)? _As a library_, dropping the support just to make code look sexy (function () {} vs. ()=>{}) is NOT a very famous trait. For homebrew project, yes I love breaking things and hating IE too.
ghost
on 13 Nov 2015
ES6 cant support long polling?
Change can be difficult for some.
ppumkin
on 13 Nov 2015
@ppumkin, long polling is an "old" technique for fallback purposes. You are missing the whole point.
ghost
on 13 Nov 2015
Can you all have this conversation elsewhere? Every time you each misunderstand browser support, transport methods, ES6 and transpiling you notify like a 100 people. please just talk on IRC and leave this conversation to the dang topic
jquense
on 13 Nov 2015
@austinsc Great news. I can't wait to see it in action. Out of curiosity, any reason for not using TypeScript (as long as you're doing transpilation anyways)?
Edit: what's up with the comments in that repo?... it's like a pirate is speaking 'em.
Ixonal
on 13 Nov 2015
Haha nice image on your repo @austinsc
ghost
on 13 Nov 2015
Thanks guys, things are moving forward. We are using babel to transpile, so
es5 code output is an option. Since we are building this for a specific
project, things like docs are in the works- sorry for the delay. Also, I
recommend checking out https://github.com/rovisys/signal-arr-proxygen . It
is a node.js based replacement for the built in
DefaultJavascriptProxyGenerator class. You can incorporate it into your
build system to scan a .net assembly and pull out the hub client code.
On Fri, Nov 13, 2015 at 12:21 PM, Peter Jas [email protected]
wrote:
Haha nice image on your repo @austinsc https://github.com/austinsc
—
Reply to this email directly or view it on GitHub
https://github.com/SignalR/SignalR/issues/372#issuecomment-156492838.
austinsc
on 7 Dec 2015
@Ixonal heh, the comments probably wont get shipped that way
austinsc
on 7 Dec 2015
Guys please help me... is there any way to write SignalR with Dojo library or Pure JavaScript..? i need to do a POC for SignalR with Dojo library so is there any way to do so i can start something. I am new to SignalR and Dot Net
MaheshKalyankar
on 5 Jan 2016
@austinsc would love to see this project live. Any change to actually add typescript definition?
dlebedynskyi
on 29 Jan 2016
I've finally got some breathing room to keep this moving forward. I'll look into what it would take to get the typescript definitions created. (pull requests are welcome ;). AFAIK everything works, you should be able to download and run the tests which actually contact a demo server on the internet.
austinsc
on 9 Feb 2016
@austinsc do you mind adding read me ?and some examples ) I do assume this is right repo https://github.com/rovisys/signal-arr-proxygen .Great work. we might use it soon )
dlebedynskyi
on 11 Feb 2016
@dlebedynskyi check out https://github.com/rovisys/signal-arr. Documentation is in the works, and so are additional samples. You can always check out the tests for information on how to use it. https://github.com/rovisys/signal-arr-proxygen is for generating the client side proxies from a binary so that they can be used in a front-end build system like webpack or browserify.
austinsc
on 17 Feb 2016
+1 for getting rid of the jQuery dependency
Let's do it already the whole community is moving away from this thing, it has passed its time.
lbacaj
on 19 Feb 2016
+1
brendanalexdr
on 21 Apr 2016
@austinsc tried to use your libs. no luck so far. hope to see good no JQuery implementation someday.
maybe with release of new signalR version. For now we just switched to pure websocket with simple group management. turned to be easier for us.
dlebedynskyi
on 22 Apr 2016
- 1
riza-herzego
on 12 May 2016
+1
amcdnl
on 12 May 2016
I'd just like to mention. I do not hold the development team personally responsible for this, and mean no disrespect to individuals.
And yet, I definitely hold Microsoft, its SignalR product, and its SignalR product management, accountable for this. Communication on this has really been botched, and the resulting inability to plan correctly has diminished the quality of products I've created.
To clarify, it's not about what we can/cannot do. It's about having the information to make the best decisions about how to design our products and use our human resources. 5 years is a long time to keep moving the goalposts.
If we'd received the message "we aren't solving this for 5 years" rather than "we're working on it", you almost certainly WOULD have had someone else address this long ago. It might even have been my team. BUT, I guarantee we would have either worked on your code for you or found a different solution before now.
I get that this product is "free". Except it's not.
syndicatedshannon
on 25 Jun 2016
+1
scottaddie
on 1 Jul 2016
+1
Michsior14
on 15 Jul 2016
+1
I'm going to hack together something, but would prefer not to. I really like the simplicity on the server side, but I'm not ok with including jquery any more, this is ridiculous...
jasoncavaliere
on 17 Jul 2016
We're about to start the investigation into this over on the new repo now that ASP.NET Core 1.0 is released. Thanks.
DamianEdwards
on 17 Jul 2016
@DamianEdwards great news! Can't wait for jquery-free version!
Misiu
on 18 Jul 2016
@DamianEdwards just as idea - it would be great to have signalR compatible with express.js client.
Might be even good if you guys separated client and server into separate repos, to avoid scenario this.
dlebedynskyi
on 18 Jul 2016
@DamianEdwards That will be great and timely now that .Net Core passed an important milestone.
Ponant
on 5 Aug 2016
@DamianEdwards can you link to the new issue you're tracking this on the new repo?
kenotron
on 12 Oct 2016
@DamianEdwards when come out SignalR without jquery?
PterPmnta
on 14 Oct 2016
About every six months I check this repo. And about every six months I see nothing is moving forward.
brendanalexdr
on 10 Nov 2016
.......?
rhummelmose
on 23 Nov 2016
For others that are frustrated:
Appears that new SignalR for .NET Core doesn't rely on jQuery.
aspnet/SignalR
chriscerk
on 8 Dec 2016
For non-Core users.
Here's my version which doesn't pollute window object with jQuery and locally uses bare-minimum jQuery shim which adds only ~5kb instead of typical 90 https://github.com/DVLP/signalr-no-jquery
DVLP
on 14 Dec 2016
@DVLP Is this using the latest release of SignalR? Do you know if it works with all the fallbacks?
raybooysen
on 14 Dec 2016
@raybooysen it's using the latest v2.2.1 , everything is included. There are no changes made to signalR code(except of replacing window.jQuery in wrapping closures) and jQuery shim is taken from react-native-signalr so if everything went right it should all work.
DVLP
on 14 Dec 2016
@nukuuk we're observing this issue (and others like module imports & npm) for years now and nothing is happening. Why we didn't go to SocketIO+uWebSockets in the first place i do not know.
drcmda
on 26 Jan 2017
Its such a nice thing Signalr. But dependecy on Jquery is one thing that is making us reconsider to use signalr in our project.
hakimfg
on 6 Feb 2017
Well, since we are waiting for the signalr independent of jquery, does anyone know how I can take my signalr requests and broadcast off the UI thread? its stalling my pages
jamesomitron
on 23 Feb 2017
Meanwhile, 4 years later, still no SignalR without jQuery dependency. No one likes jQuery. The web was built on vanilla javascript, not jQuery. It would take only a few days to convert this from jQuery to vanilla Javascript.
mentinghfreightcenter
on 20 Mar 2017
@mentinghfreightcenter, this is an open source repo, your more then welcome to take up the task, and send in a pull request, I'm sure the SignalR team would be more then willing to accept any meaningful pull requests. I'm actually surprised that no one has at this point for this flavor of SignalR.
On the flip side, the version of SignalR being developed along side .NET Core, actually has a flavor of the SignalR client that does not have the JQuery dependency, your welcome to go check it out at: https://github.com/aspnet/SignalR
WillFM
on 20 Mar 2017
Awesome, thank you for the info. I also found a github repo that makes signal R believe jquery is installed while using a jquery shim library: https://github.com/DVLP/signalr-no-jquery
mentinghfreightcenter
on 20 Mar 2017
@WillFM @mentinghfreightcenter - the client in the https://github.com/aspnet/SignalR repo won't work with 2.x server.
moozzyk
on 20 Mar 2017
+1
sreekumarp
on 10 Jul 2017
On the flip side, the version of SignalR being developed along side .NET Core, actually has a flavor of the SignalR client that does not have the JQuery dependency, your welcome to go check it out at: https://github.com/aspnet/SignalR
@WillFM I hope that this is not the reason why we won't get an asp.net (not core) version of signalR without the jQuery dependency.
sag1v
on 11 Jul 2017
The question is how to use the .net core signalR with .net full owin and make it work without having to redo our entire api ported to .net core...
JohnGalt1717
on 17 Jul 2017
SignalR Core is not compatible with SignalR 2.x - i.e. you will not be able to use SignalR Core client with SignalR 2.x server and vice versa.
moozzyk
on 18 Jul 2017
So in short this will never get fixed. Someone should just put this ticket out of it's misery and close with won't fix.
JohnGalt1717
on 18 Jul 2017
@JohnGalt1717, this ticket has been closed for 3 years now.
WillFM
on 18 Jul 2017
It was closed because it was supposed to be in version 3. Version 3 isn't happening obviously and it needs to be made clear by MS that this will never be addressed in the .net full fat version because it's abandonware at this point.
JohnGalt1717
on 18 Jul 2017
@JohnGalt1717 that's a bit of a misnomer. Just like ASP.NET 5 was renamed ASP.NET Core. SignalR 3 was renamed SignalR Core.
WillFM
on 18 Jul 2017
That's BS. Signalr 3 was supposed to be full fat .net framework and fix this. Now .net framework 4.x is left with abandonware and SignalR that requires jquery for no right what-so-ever.
So the only way you're going to get the fixed version of the client library is by spending a month porting your project to .NET core.
headbang.
JohnGalt1717
on 18 Jul 2017
@JohnGalt1717 ASP.NET Core 2.0 still runs on .NET 4.x in addition to .NET core in case you aren't aware. You might still need to port your app to the new ASP.NET framework, but at least most of your .NET 4.x dependencies should still work.
halter73
on 18 Jul 2017
Given that the entire pipeline for ASP.NET 5 and sockets is completely different I strongly doubt that it will work. But hey, if someone from MS wants to chime in on their own project and demonstrate that this isn't abandonware and tell us one way or another, that would be great!
JohnGalt1717
on 18 Jul 2017
I also believe that Signal R for ASP.NET 4.x has been abandoned. Such a shame...
mentinghfreightcenter
on 19 Jul 2017
Seriously, this is abandoned? And on the .Net core version they state not to use it in production code.. Also shame that they don't continue working on a more bare client js library (without jquery). In todays web development with Angular, React, Vuejs, ...
bickycheese
on 28 Dec 2017
SingalR Core (without jQuery dep) works great on DotNetCore .. Common guys.. Time to move on now. This is what you wanted all along. I am happy.
ppumkin
on 28 Dec 2017
Not everyone can up and move to .Net Core and SignalR Core. Even the Azure version of SignalR (in preview) is for Core as well.
It is such a shame that the SignalR team within Microsoft decided to not update the SignalR JavaScript client library not to use jQuery (and use TypeScript like how @aspnet/signalr does but that is for SignalR Core and not for SignalR on ASP.NET).
Asking users to write it themselves and send a pull request is not only ridiculous but outright irresponsible.
kotpal
on 7 Jun 2018
Asking users to write it themselves and send a pull request is not only ridiculous but outright irresponsible.
You're right, that was wrong. I should have been more honest about this. We have no plan to do this work.
davidfowl
on 7 Jun 2018
"should have been more honest" is only part of the issue, speaking as one following this topic for 6 years. on the bright side, I can finally stop following this misinformative and toxic thread.
syndicatedshannon
on 8 Jun 2018
@davidfowl, that's fair enough, after all it's better late than never.
However, we are very interested to know: is there a good reason why it was rejected six years ago? Was it lack of manpower or other reason that renders it "not worth the effort"?
ghost
on 9 Jun 2018
how can use signalr on react-native?
I can't move signalr to signlr ccore
dungmv
on 22 Dec 2018
Related issues
tuyen-vuduc
·
26Comments
KyleScharnhorst
·
27Comments
corneliutusnea
·
33Comments
simoneb
·
47Comments
clodprogea
·
15Comments
Most helpful comment
We're about to start the investigation into this over on the new repo now that ASP.NET Core 1.0 is released. Thanks.