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.
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.
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.
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.
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
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.
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/) 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.
Can we please stick to the facts? Where exactly does it promote micro-modules? For example, React was repeatedly criticized for not splitting virtual dom implementation into a separate npm package. That's completely opposite side of the spectrum.
> Here I am thinking that 20k+ files
This are separate files and not necessary as many separate modules. Different things, really. That's ought to be solved with some kind of jar-like packaging format. I'm surprised node.js/npm doesn't have something like that implemented yet.
I've already made this clear, a blank Hello World App requires 20k+ files and 100's runtime dependencies. It literally takes minutes to download everything which I've had often fail. npm installs of SPA templates are one of the few things that can cause my MBP CPU to burn and HDD to thrash for long periods of time where I'd expect it to consume a non-trivial amount of energy.
The fact there's so many deps mandates additional tooling to manage and bundle them down to a manageable number of deps during development.
Facebook's recommendation for a hello world app [1] wants you to use their package manager, Webpack, Babel, Flow, a Linter, CSS preprocessor, their test runner, an embedded HTTP server just for starting off, building any meaningful App requires more dependencies where eventually you'll also consider a module loader. Then you're going to need to package/deploy your App and if you go off-script you'll need to manage and understand how all the different moving parts work together which you'll also need to know when wasting time chasing down dependency conflicts and tooling integration issues after package updates.
Your point about their being only 2 dependencies is completely inconsequential for development and shows inexperience in the recommended state of the art React SPA development.
> I've already made this clear, a blank Hello World App requires 20k+ files and 100's runtime dependencies.
That's a legitimate complaint but I don't think it has anything to do with micro-modules. You can easily have thousands of files per one npm package just as well. Now, if you actually mean commonjs-modules as opposed to npm packages, then you have a point. We really need to avoid unpacking all this files on disk separately.
> Your point about their being only 2 dependencies
Not my point. In fact, React has exactly zero runtime dependencies and as many development dependencies as you like.
> recommended state of the art React SPA development.
I only have the issue with the recommended part. All that React does is just trying to cooperate cleanly with the most popular js development stack out there. That unfortunately means npm mess (for now).
Start from any recommended starting React dev template and count the no of files, seperate tools, config files and runtime dependencies required to maintain an iterative dev workflow. The dependencies have gotten so out of hand Facebook's even developed their own package manager to manage it since npm has issues managing it properly.
> For example, React was repeatedly criticized for not splitting virtual-dom...
That's for production deployments, it doesn't represent the complexity and cognitive overhead required during development.
> I'm surprised node.js/npm doesn't have something like that implemented yet.
There's a number of bundlers available, it just requires integrating more tools and maintaining more config files.
> 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.
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.
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.
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.
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.
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.
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.