Rewrite JavaScript bindings to no longer depend on jQuery #372

Closed
cburgdorf opened this Issue May 8, 2012 · 157 comments

Projects

None yet
@cburgdorf

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

@davidfowl
SignalR member

Feel free to send a PR for this change.

@SlyNet

Its bad that there is no upvotes on github. +1 here

@davidfowl
SignalR member

@SlyNet I agree they should have votes.

@Daniel15

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.

@gerardtoconnor

+1, really frustrating to have to include bulky jquery file just for a few bindings when using different framework

@jeppebemad

A very big +1 from me to. We are succesfully using SignalR for mobile applications, but the footprint of jQuery is a problem.

@DamianEdwards
SignalR member

We are hoping to remove our jQuery dependency in an upcoming release.

@iateyourtoothpaste

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.

@davidfowl
SignalR member

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

@shiftkey

Sorry, couldn't help myself 😁

@Misiu

@Daniel15 +1 for adapters idea.

@iateyourtoothpaste
@levipage

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.

@Misiu

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!!!

@dhont

Looking forward this, as well!

@DamianEdwards DamianEdwards modified the milestone: Backlog, 2.1.0 Beta Apr 7, 2014
@JoergTiedemann

Will the issue solved in the milestone for 2.1.0 beta ?

@davidfowl
SignalR member
@Daniel15
@davidfowl
SignalR member

@Daniel15 we're doing a client rewrite along with this work. Today, signalr uses deferred, ajax and events.

@JoergTiedemann

So is it possible to use signalr in webworker thread without using jquery Framework?
Or how can i use signalr in a webworker ?

@DamianEdwards
SignalR member

@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.

@JoergTiedemann

Yes but at which release it is planned to remove jquery ?

@Misiu

@DamianEdwards anything new here?

@shaunol

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 :(

@JoergTiedemann

Yes
the only question is, in what Release will the jquery dependency removed ?

@joeuy

+1 it would be nice to be independent.

@JoergTiedemann

Removing jquery dependency is the only Way to use signalr in a webworker.

@w3apps

Any updates? You were saying "It's targeted for 2.1.0 beta" but I can't see anything in the release notes.

@levipage

@w3apps If you check out the earlier comments, it states it will not be part of the 2.1.0 beta.

@bukharin

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...

@Misiu

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?

@JoergTiedemann

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

@Dubnovitsky

Also hoped to version 2.1...maybe with 3.0 we will be able to forget about jquery

@DamianEdwards
SignalR member

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 DamianEdwards added the v3 label Jun 23, 2014
@shaunol

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.

@JoergTiedemann

Sounds good, but if its one of the issues with top priority it should be included as an issue in one of the milestones

@DamianEdwards
SignalR member

We'll move this to the new repo for v3.

@JoergTiedemann

Sorry, can't see any milestones or issues in that repo if I follow the link

@DamianEdwards
SignalR member

@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.

@am11

+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 am11 referenced this issue in madskristensen/WebEssentials2013 Jul 10, 2014
Closed

Use persistent Node processes for compilation #381

@JoergTiedemann

I'm very interested in that. Could you post some sample code and the transformed lib please.

@am11

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.)
@Daniel15

@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 harvesthq/chosen#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.

@am11

@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..)

@moity

@DamianEdwards you mention "getting WebSockets across all platforms" - does this include Win2008 R2? Would really like to have that.

@DamianEdwards
SignalR member

@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.

@moity

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.

@Daniel15

@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).

@moity

@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).

@Daniel15

@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 :)

@moity

@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.

@LarsKemmann

+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).

@JoergTiedemann

Is there anything news about a date, the javascript signalr client is available without using jquery ?

@tedvanderveen

+1 again

@meirb

+1 after 3 years we need to have this

@am11

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. 🎯

@jjfood

Is this done yet? Really need this.

@syndicatedshannon

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.

@Misiu

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?

@larsfjerm
@mcaroul

+1

@noobouse

+1

@ghost

@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)...

@goranobradovic

+1 this just made me not use SignalR for my new project

@mdlar

+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.

@Misiu

@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.

@DerKnerd

@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.

@ghost

@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.

@DerKnerd

@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.

@ghost

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..

@tedvanderveen

+1 @jasonwilliams200OK for suggesting Typescript :)

@Daniel15

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.

@Misiu

Any news? This feature was requested almost 3 years ago 😞

@LarsKemmann

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. :)

@DamianEdwards
SignalR member

@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.

@LarsKemmann

@DamianEdwards Fantastic. :)

@ppumkin

+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.

@tedvanderveen

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.

@ppumkin

@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.

@tedvanderveen

@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

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.

@ppumkin

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.

@tedvanderveen

@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.

@ppumkin

@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.

@LarsKemmann

(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.

@ppumkin
@syndicatedshannon

@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

Also, thank you very much @DamianEdwards for the update.

@LarsKemmann

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.

@ghost

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 :)

@groovy21

+1 please. This has been ignored for a long time now.

@Misiu Misiu referenced this issue in aspnet/SignalR-Client-JS Jul 21, 2015
Open

Roadmap? #1

@avanderhoorn

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).

@tedvanderveen

@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)?

@avanderhoorn
@jquense

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())
  }
})
@ghost

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!

@Daniel15

@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.

@ghost

@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!

@jquense

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.

@Ixonal

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?

@ppumkin
@syndicatedshannon

#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

@wilgert

+1

@austinsc

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 base class).

https://github.com/RoviSys/signal-arr

@BlueInt32

@austinsc this looks great ! do you have any sample to show before the docs come out ?

@ghost

@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. :)

@ppumkin

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.

@ghost

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!

@ppumkin

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.

@ghost

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.

@wilgert

@jasonwilliams200OK You can transpile to ES5 so what's the problem?

@zardoz

@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.

@ppumkin

👍

@ghost

@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.

@ppumkin

ES6 cant support long polling?

Change can be difficult for some.

@ghost

@ppumkin, long polling is an "old" technique for fallback purposes. You are missing the whole point.

@jquense

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

@Ixonal

@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.

@ghost

Haha nice image on your repo @austinsc

signal-arr

@austinsc
@austinsc

@Ixonal heh, the comments probably wont get shipped that way

@MaheshKalyankar

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

@dlebedynskyi

@austinsc would love to see this project live. Any change to actually add typescript definition?

@austinsc

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.

@dlebedynskyi

@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 )

@austinsc

@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.

@lbacaj

+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.

@nukuuk

+1

@dlebedynskyi

@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.

@amcdnl

+1

@syndicatedshannon
syndicatedshannon commented Jun 25, 2016 edited

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.

@jasoncavaliere

+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...

@DamianEdwards
SignalR member

We're about to start the investigation into this over on the new repo now that ASP.NET Core 1.0 is released. Thanks.

@Misiu

@DamianEdwards great news! Can't wait for jquery-free version!

@dlebedynskyi

@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.

@Ponant

@DamianEdwards That will be great and timely now that .Net Core passed an important milestone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment