6 ms·

Pour one out for jQuery! jQuery was a major productivity boost when first released but it didn't scale well and encouraged creation of tightly coupled glue cod

by mythz 10y ago

Pour one out for jQuery! jQuery was a major productivity boost when first released but it didn't scale well and encouraged creation of tightly coupled glue code. It's decline being the result of evergreen browsers maintaining good parity where "vanilla JS" is now a feasible option and from it no longer being needed in the premier JS SPA frameworks which scales better and allows for the creation of better componentized and modular code-bases. In someways we've digressed significantly and made it ridiculously more complicated to build a modern web app in contrast to what jQuery gives you out-of-the-box with a simple script include. Now to create a basic Angular2 App you need to download 32k+ files from npm and become an Angular2 build master just to setup your development environment and configure your package/deploy scripts. You can still go a long way with just Bootstrap + jQuery - which would still be my goto if I just need to spruce up a web page with some behavior. Although that's happening less and less and find myself reaching for VS.NET/TypeScript/JSPM/React as my choice SPA stack which scales well with a great ecosystem, minimal complexity and maximum utility.

deleted 10y ago
[deleted]
MrBra 10y ago
> minimal complexity compared to?
- mythz 10y ago
  The premier SPA frameworks: Angular/2, Ember, Polymer, Aurelia, Knockout,... Fundamentally React has a one major concept "Components" which is very easy to create and JSX gives you the full power of JS without needing to learn the nuances of a crippled templating language. I use Redux to manage state which like React is simple and extremely powerful and centralizes all your App's state in clean data structures. E.g. with very little effort you can create a "Networked Time Traveller App" [1]. I also believe React's "Learn Once, Write Anywhere" approach lets you get maximum utility for your existing knowledge and decent code-reuse where you can use it to build cross-platform native iOS/Android Apps with arguably a more productive development workflow than the native iOS/Android toolkits on offer, although it's still a bit immature atm but has great momentum with a bright future. [1] https://github.com/ServiceStackApps/typescript-redux https://github.com/ServiceStackApps/typescript-redux
pavlov 10y ago
It's not just Angular. I really do like React, but the ecosystem complexity is staggering there as well. Facebook's "create-react-app" tool does a great job of packaging all the pieces... But the cost is apparent when looking at the size of an empty create-react-app boilerplate app: > 85,174,715 bytes (148.8 MB on disk) for 23,387 items This is on Mac, so the wasteful HFS+ file system means that an empty web frontend project takes up 150 MB of disk space. Each project I make with create-react-app will have this same overhead. That's fairly incredible. People think C++ is complex, but a full C++14 compiler and dozens of libraries will fit in less space than a web boilerplate.
- mythz 10y ago
  Yep React's also culpable to npm's "micro module" madness, where often the scope of a npm package is wrapping a single function! Which explains why blank SPA templates requires 1000's of files. But I've got my choice SPA stack down to a solution I'm happy with, where a blank App is down to: - TypeScript (using Type Definitions in npm package or @types) - JSPM (package/dep management, module loader + bundler) - Gulp (automate all tasks in reusable scripts) - React JSPM `bundle` feature also lets you combine all React's deps into a single .js file which speeds up iterative dev workflow by combining the 100's of runtime dep requests down to 1 .js file. Also using jspm@beta means I don't have to configure a separate tool like Webpack as JSPM reuses your dependencies where its 'build' feature rolls up your app into a single stand-alone, minified .js file to give you an optimal packaged app for deployment. Using the TypeScript integration in VS.NET means I don't have to run any external processes or watchers as TypeScript automatically re-compiles every modified .ts file on save where it's ready by the time I reload the page. Unfortunately it looks like npm has passed the point of no return and every developer is stuck building on this complexity. Honestly if it wasn't for the potential of React Native I'd strongly consider moving to Vue.js (https://vuejs.org/v2/guide/ https://vuejs.org/v2/guide/) since it's still a modern well supported SPA fx, but lets you reference a single script include. Ideally React would offer a simplified solution where it also maintains a parallel "react-dev" npm package with no deps, but it's unlikely since it goes against npm's micro module madness trend - but it's something I'm keen on exploring if I ever get the free time.
k__ 10y ago
I only used jQuery through Ember, never directly. It seemed to me, that the problem of jQuery wasn't how it was designed, but how it was used. I mean, if you simply use it to "directly" do your thing, without any framework/modularity pattern, you gonna have a bad time. But you could simply assume jQuery was the "browser API" and build your application framework on top of it, like Ember and others did. I mean, even the Sencha devs did their own abstraction layer and built their frameworks on top of it.
- mythz 10y ago
  jQuery still boils down to mutating DOM state, forcing you to become a bookkeeper where you have to carefully ensure your App's state and rendered DOM are in constant sync and you also have to deal with interim state transitions where it's easy to run into bugs for state transitions you've never tested or thought about, which gets complicated quickly. React's Virtual DOM means you only have to care about the representation of a given state and React takes care of transparently and optimally handling all the DOM mutations required to sync the DOM with your App's state. React also has great componentization making it natural and easy to encapsulate reusable logic. The benefits really stand out in medium to large code-bases where it scales much better than jQuery. It's still ok for Apps maintaining little state, but there's a large class of Apps I'd never consider creating in jQuery which I've found trivial to develop with in React.
- mattmanser 10y ago
  There was never a 'problem' with jQuery apart from that it's quite a heavy file, especially for mobile, and some people want to stop having to download it. It's never been faced by the problems that backbone, angular, react, etc. where they rapidly die as soon as something else comes along, because it's a well built utility library, not a framework that had to include nasty hacks to work. But, technically, there are no problems with it. If it were included by default in browsers, everyone would still be using it over vanilla javascript as even the new vanilla javascript has really poorly designed and wordy APIs.
mercer 10y ago
> In someways we've digressed significantly and made it ridiculously more complicated to build a modern web app in contrast to what jQuery gives you out-of-the-box with a simple script include. That's true, but I find that things are complicated because either 1) the complexity is higher because we're dealing with a proper app, in which case jQuery wouldn't be much simpler (you'd probably use Backbone.js at the very least, and that gets messy quick), or 2) people use a lot of 'state of the art' stuff that they don't really need. In regards to 2: if what you need to do can be done with a script tag and jQuery, you probably wouldn't need anything beyond 'plain' React and it would still be a benefit. And if you go for something like Preact, the download size is smaller than jQuery, so you could even consider using both at the same time; preact for dom updates, and jQuery for everything else. More and more I find myself opting for (p)react even for simple things like a slideshow widget or a tabbed element. I find it nicer than jQuery and if you avoid using all the 'cool stuff' (redux, etc.) it's simpler too.
michaelbuckbee 10y ago
I think what drives me nuts is that so often jQuery+Bootstrap would deliver a faster quicker product. While the big frameworks are incredible, they really are designed [1] for really large applications, ala Angular and Gmail. But, I see them being pushed onto what would otherwise be very simple projects: static websites, sites with a single contact form, etc. 1 - http://www.planningforaliens.com/blog/2016/04/11/why-js-development-is-crazy/ http://www.planningforaliens.com/blog/2016/04/11/why-js-deve...
arenaninja 10y ago
Yeah I get flak when I still use jQuery in new projects. Why do I use it? It fucking works, with no need to depend on npm, the application is a lot snappier than using Angular. If I move on from jQuery, it won't be to Angular. I tried React, but I also found it too much boilerplate. I'm trying VueJS next.
- spiderfarmer 10y ago
  I've noticed that the people that ridicule you for using stuff that works (like jQuery) are the same people that have trouble maintaining their own older code, because they'd much rather just start over.
  - xeromal 10y ago
    With JQeury, you can reference one file and get going. With Angular, my frustration has been: * SystemJS - I don't understand what's the problem a lot of the time * TypeScript tsc deciding that Promise is not a known entity. * People telling me not to use SystemJS because it's causing me all my problems. * People telling me not to use Typescript because it's causing all my problems. * Taking 3 days to switch to something not causing my problems. * Technology x causing me another set of problems.
- paulddraper 10y ago
  > Why do I use it? It fucking works Nowdays that true of vanilla JS. (Didn't use to be.) addEventListener, documentQuerySelector, XMLHttpRequest...yes not everything is a one character function name ($), but it's all quite usuable if you value barebones-no-dependency simplicity.
  - arenaninja 10y ago
    I beg to differ... There's still weird Safari/Android bugs from old devices that are out in the wild. Even Windows 8 + IE11 has warts and might be used by application users. I guess it depends on what you're working on, but for us it's expressly not an option to say "we only support the latest version of [insert browser]". Some users aren't even technical enough to differentiate between a browser and the internet
ukyrgf 10y ago
The other day I downloaded project files from somebody and extracted it to my Dropbox folder before realizing it had a node_modules folder... crashed Dropbox on every single computer I had attached to it. I have to do the full Git remote repository push/pull dance, with each PC 'npm install'ing, just to work on any small project that might be related to Node.

by mythz 10y ago

deleted 10y ago

[deleted]

MrBra 10y ago

> minimal complexity compared to?

mythz 10y ago
The premier SPA frameworks: Angular/2, Ember, Polymer, Aurelia, Knockout,... Fundamentally React has a one major concept "Components" which is very easy to create and JSX gives you the full power of JS without needing to learn the nuances of a crippled templating language. I use Redux to manage state which like React is simple and extremely powerful and centralizes all your App's state in clean data structures. E.g. with very little effort you can create a "Networked Time Traveller App" [1]. I also believe React's "Learn Once, Write Anywhere" approach lets you get maximum utility for your existing knowledge and decent code-reuse where you can use it to build cross-platform native iOS/Android Apps with arguably a more productive development workflow than the native iOS/Android toolkits on offer, although it's still a bit immature atm but has great momentum with a bright future. [1] https://github.com/ServiceStackApps/typescript-redux https://github.com/ServiceStackApps/typescript-redux

pavlov 10y ago

It's not just Angular. I really do like React, but the ecosystem complexity is staggering there as well. Facebook's "create-react-app" tool does a great job of packaging all the pieces... But the cost is apparent when looking at the size of an empty create-react-app boilerplate app: > 85,174,715 bytes (148.8 MB on disk) for 23,387 items This is on Mac, so the wasteful HFS+ file system means that an empty web frontend project takes up 150 MB of disk space. Each project I make with create-react-app will have this same overhead. That's fairly incredible. People think C++ is complex, but a full C++14 compiler and dozens of libraries will fit in less space than a web boilerplate.

mythz 10y ago
Yep React's also culpable to npm's "micro module" madness, where often the scope of a npm package is wrapping a single function! Which explains why blank SPA templates requires 1000's of files. But I've got my choice SPA stack down to a solution I'm happy with, where a blank App is down to: - TypeScript (using Type Definitions in npm package or @types) - JSPM (package/dep management, module loader + bundler) - Gulp (automate all tasks in reusable scripts) - React JSPM `bundle` feature also lets you combine all React's deps into a single .js file which speeds up iterative dev workflow by combining the 100's of runtime dep requests down to 1 .js file. Also using jspm@beta means I don't have to configure a separate tool like Webpack as JSPM reuses your dependencies where its 'build' feature rolls up your app into a single stand-alone, minified .js file to give you an optimal packaged app for deployment. Using the TypeScript integration in VS.NET means I don't have to run any external processes or watchers as TypeScript automatically re-compiles every modified .ts file on save where it's ready by the time I reload the page. Unfortunately it looks like npm has passed the point of no return and every developer is stuck building on this complexity. Honestly if it wasn't for the potential of React Native I'd strongly consider moving to Vue.js (https://vuejs.org/v2/guide/ https://vuejs.org/v2/guide/) since it's still a modern well supported SPA fx, but lets you reference a single script include. Ideally React would offer a simplified solution where it also maintains a parallel "react-dev" npm package with no deps, but it's unlikely since it goes against npm's micro module madness trend - but it's something I'm keen on exploring if I ever get the free time.

k__ 10y ago

I only used jQuery through Ember, never directly. It seemed to me, that the problem of jQuery wasn't how it was designed, but how it was used. I mean, if you simply use it to "directly" do your thing, without any framework/modularity pattern, you gonna have a bad time. But you could simply assume jQuery was the "browser API" and build your application framework on top of it, like Ember and others did. I mean, even the Sencha devs did their own abstraction layer and built their frameworks on top of it.

mythz 10y ago
jQuery still boils down to mutating DOM state, forcing you to become a bookkeeper where you have to carefully ensure your App's state and rendered DOM are in constant sync and you also have to deal with interim state transitions where it's easy to run into bugs for state transitions you've never tested or thought about, which gets complicated quickly. React's Virtual DOM means you only have to care about the representation of a given state and React takes care of transparently and optimally handling all the DOM mutations required to sync the DOM with your App's state. React also has great componentization making it natural and easy to encapsulate reusable logic. The benefits really stand out in medium to large code-bases where it scales much better than jQuery. It's still ok for Apps maintaining little state, but there's a large class of Apps I'd never consider creating in jQuery which I've found trivial to develop with in React.
mattmanser 10y ago
There was never a 'problem' with jQuery apart from that it's quite a heavy file, especially for mobile, and some people want to stop having to download it. It's never been faced by the problems that backbone, angular, react, etc. where they rapidly die as soon as something else comes along, because it's a well built utility library, not a framework that had to include nasty hacks to work. But, technically, there are no problems with it. If it were included by default in browsers, everyone would still be using it over vanilla javascript as even the new vanilla javascript has really poorly designed and wordy APIs.

mercer 10y ago

> In someways we've digressed significantly and made it ridiculously more complicated to build a modern web app in contrast to what jQuery gives you out-of-the-box with a simple script include. That's true, but I find that things are complicated because either 1) the complexity is higher because we're dealing with a proper app, in which case jQuery wouldn't be much simpler (you'd probably use Backbone.js at the very least, and that gets messy quick), or 2) people use a lot of 'state of the art' stuff that they don't really need. In regards to 2: if what you need to do can be done with a script tag and jQuery, you probably wouldn't need anything beyond 'plain' React and it would still be a benefit. And if you go for something like Preact, the download size is smaller than jQuery, so you could even consider using both at the same time; preact for dom updates, and jQuery for everything else. More and more I find myself opting for (p)react even for simple things like a slideshow widget or a tabbed element. I find it nicer than jQuery and if you avoid using all the 'cool stuff' (redux, etc.) it's simpler too.

michaelbuckbee 10y ago

I think what drives me nuts is that so often jQuery+Bootstrap would deliver a faster quicker product. While the big frameworks are incredible, they really are designed [1] for really large applications, ala Angular and Gmail. But, I see them being pushed onto what would otherwise be very simple projects: static websites, sites with a single contact form, etc. 1 - http://www.planningforaliens.com/blog/2016/04/11/why-js-development-is-crazy/ http://www.planningforaliens.com/blog/2016/04/11/why-js-deve...

arenaninja 10y ago

Yeah I get flak when I still use jQuery in new projects. Why do I use it? It fucking works, with no need to depend on npm, the application is a lot snappier than using Angular. If I move on from jQuery, it won't be to Angular. I tried React, but I also found it too much boilerplate. I'm trying VueJS next.

spiderfarmer 10y ago
I've noticed that the people that ridicule you for using stuff that works (like jQuery) are the same people that have trouble maintaining their own older code, because they'd much rather just start over.
- xeromal 10y ago
  With JQeury, you can reference one file and get going. With Angular, my frustration has been: * SystemJS - I don't understand what's the problem a lot of the time * TypeScript tsc deciding that Promise is not a known entity. * People telling me not to use SystemJS because it's causing me all my problems. * People telling me not to use Typescript because it's causing all my problems. * Taking 3 days to switch to something not causing my problems. * Technology x causing me another set of problems.
paulddraper 10y ago
> Why do I use it? It fucking works Nowdays that true of vanilla JS. (Didn't use to be.) addEventListener, documentQuerySelector, XMLHttpRequest...yes not everything is a one character function name ($), but it's all quite usuable if you value barebones-no-dependency simplicity.
- arenaninja 10y ago
  I beg to differ... There's still weird Safari/Android bugs from old devices that are out in the wild. Even Windows 8 + IE11 has warts and might be used by application users. I guess it depends on what you're working on, but for us it's expressly not an option to say "we only support the latest version of [insert browser]". Some users aren't even technical enough to differentiate between a browser and the internet

ukyrgf 10y ago

The other day I downloaded project files from somebody and extracted it to my Dropbox folder before realizing it had a node_modules folder... crashed Dropbox on every single computer I had attached to it. I have to do the full Git remote repository push/pull dance, with each PC 'npm install'ing, just to work on any small project that might be related to Node.