4 ms·

"Do we have a problem? No." So now comes jQuery 2 and now what? Maybe you don't use it, but just replace it with any library you use in your environment. This

by roel_v 14y ago

"Do we have a problem? No." So now comes jQuery 2 and now what? Maybe you don't use it, but just replace it with any library you use in your environment. This comes from somebody doing C++ on VS 2008 on Windows XP, so I feel your pain. I just think it's not a very feasible stance to take. I've held out on XP for as long as I could, but I'm not sure how long I'll be able to last. (although, to be honest, I haven't found any real compatibility issues yet; of course I'm not using IE any more so that probably shields me from most issues. I did have one problem a few weeks ago with a Windows 2000 server not being able to run recent Firefox versions, but I guess Win2k is really deprecated by now ;) )

meaty 14y ago
jQuery 2 can fuck off. In fact jQuery as a whole can fuck off. It's been a disasterous slog using it for us. No end of problems with it and associated half-arsed shitty plugins to the point we've developed our own internal JS API and toolkit which we can control. Even minor version upgrades of jQuery have been dependency hell (we have 110kloc of JS excluding jQuery plugins - a lot!). We deploy desktop apps (via ClickOnce / direct) as well as web applications, so we're supposedly in the same mire, however they still "just work". They don't suddenly stop working one day. Youre entire toolchain is fine. Just keep it in a VM. We only just killed a desktop app deployed on Windows NT4 which was thrown together with VC++ 6. I have the VM running now as I'm porting it to .Net 4 (C# this time).
- andybak 14y ago
  > to the point we've developed our own internal JS API and toolkit which we can control I would have thought submitting a bug fix to jQuery might have been less work.
  - meaty 14y ago
    Harder than it looks. Submitted 20+ bug reports, got 1 solved. jQuery's issue tracking and source management was a baron land of incompetence. By that time we had our own wrapper API that fixed all the jQuery bugs so we just took the guts out and replaced then with our own.
elliotanderson 14y ago
jQuery 1.9 and 2.0 will be API compatible - just use an IE conditional include to source the right version. Only downside is if you have a tight asset pipeline that minifies _everything_ and it causes 1 extra request.

by roel_v 14y ago

meaty 14y ago

jQuery 2 can fuck off. In fact jQuery as a whole can fuck off. It's been a disasterous slog using it for us. No end of problems with it and associated half-arsed shitty plugins to the point we've developed our own internal JS API and toolkit which we can control. Even minor version upgrades of jQuery have been dependency hell (we have 110kloc of JS excluding jQuery plugins - a lot!). We deploy desktop apps (via ClickOnce / direct) as well as web applications, so we're supposedly in the same mire, however they still "just work". They don't suddenly stop working one day. Youre entire toolchain is fine. Just keep it in a VM. We only just killed a desktop app deployed on Windows NT4 which was thrown together with VC++ 6. I have the VM running now as I'm porting it to .Net 4 (C# this time).

andybak 14y ago
> to the point we've developed our own internal JS API and toolkit which we can control I would have thought submitting a bug fix to jQuery might have been less work.
- meaty 14y ago
  Harder than it looks. Submitted 20+ bug reports, got 1 solved. jQuery's issue tracking and source management was a baron land of incompetence. By that time we had our own wrapper API that fixed all the jQuery bugs so we just took the guts out and replaced then with our own.

elliotanderson 14y ago

jQuery 1.9 and 2.0 will be API compatible - just use an IE conditional include to source the right version. Only downside is if you have a tight asset pipeline that minifies _everything_ and it causes 1 extra request.