His example is terrible but his conclusion is sound (imo):
> Yeah, jQuery is dead not because frameworks make you write better code - we know they don’t - but because your framework does DOM manipulation better than you ever could.
If what I need to accomplish can be done in 4 lines of jQuery, I use jQuery. When I know there's going to be a ton of DOM manipulation, I reach for a suitable framework/library because I know the mess I'll end up in if I try scaling up the 4 lines of jQuery to handle a complex web application.
I'm pretty sure you can use Angular without jQuery and even without using the jQuery-lite thing they have in it. I've moved on from Angular now but I definitely didn't rely on jQuery at all during my end of my Angular days.
I don't think raw jQuery is often used to build full dynamic frontends and SPAs. It's typically used to bolt on effects, transitions and asynchronous data fetching into otherwise statically generated server-side web pages.
Although SPAs, frontend frameworks and the model of communicating microservices is gaining lots of traction and visibility for web applications (particularly paid services that replace former desktop apps), plain old server-side CRUD that renders template variables from a data model is still going to be the dominant paradigm on the web at large, not to mention more of a conceptual neat fit to begin with.
In some ways I predict there will be a sort of resurgence in server-side CRUD frameworks again as being the hot trend you read about on HN, once people found out that you can easily build real-time, reactive UIs without having to context switch and directly deal with the often subpar client-side interfaces. Furthermore, the act of generating HTML and JavaScript from native language constructs will be lauded as a great time-saver, not to mention giving the same benefits of the so-called "isomorphism" that platforms like Node are hailed for. For examples of these concepts, see the Nitrogen and N2O frameworks (both Erlang).
I'm not at all a fan of stuffing application logic into the HTML; it means that I need to look both in the JavaScript and in the HTML. I'm also not a fan of generating the structure of a page in JavaScript, but I find this slightly more forgiveable since I know the JS can always manipulate the page.
Then again, I also refuse to view Angular as JavaScript - I find skimming over Angular code incomprehensible.
Before you indignantly grep the web for jQuery, the post did say dead is hyperbolic. (Yeah, link bait...)
For web apps, jQuery is "dead" in the same sense that string-concatenated HTTP responses are dead.
They certainly exist and are used, but there is a level of abstraction (templates) that supercede -- or should supercede -- that functionality for most developers most of the time.
If I'm writing a "hello world" web server, I probably won't be using templates. But if I'm writing a web server serving HTML that I want to be maintainable at any non-trivial complexity, I'll be using a framework/library.
Sure, you can use jQuery, and yes Angular uses it (or jqlite) for cross-browser DOM interaction, but that will not be the predominant or most visible tool in any moderately complex web app.
Front end development is coming around to the advantages of MVC, and the current generation of tools reflect that.
jQuery is not dead; it is simply no longer the highest level of abstraction for creating web apps.
11 comments
[ 3.1 ms ] story [ 39.1 ms ] thread> Yeah, jQuery is dead not because frameworks make you write better code - we know they don’t - but because your framework does DOM manipulation better than you ever could.
If what I need to accomplish can be done in 4 lines of jQuery, I use jQuery. When I know there's going to be a ton of DOM manipulation, I reach for a suitable framework/library because I know the mess I'll end up in if I try scaling up the 4 lines of jQuery to handle a complex web application.
jQuery is not dead, and until DOM apis converge across browser vendors and become 100x easier to use it will remain active.
For all intents and purposes, jqLite should be considered equivalent to jQuery for my argument.
Although SPAs, frontend frameworks and the model of communicating microservices is gaining lots of traction and visibility for web applications (particularly paid services that replace former desktop apps), plain old server-side CRUD that renders template variables from a data model is still going to be the dominant paradigm on the web at large, not to mention more of a conceptual neat fit to begin with.
In some ways I predict there will be a sort of resurgence in server-side CRUD frameworks again as being the hot trend you read about on HN, once people found out that you can easily build real-time, reactive UIs without having to context switch and directly deal with the often subpar client-side interfaces. Furthermore, the act of generating HTML and JavaScript from native language constructs will be lauded as a great time-saver, not to mention giving the same benefits of the so-called "isomorphism" that platforms like Node are hailed for. For examples of these concepts, see the Nitrogen and N2O frameworks (both Erlang).
No I don't.
I'm not at all a fan of stuffing application logic into the HTML; it means that I need to look both in the JavaScript and in the HTML. I'm also not a fan of generating the structure of a page in JavaScript, but I find this slightly more forgiveable since I know the JS can always manipulate the page.
Then again, I also refuse to view Angular as JavaScript - I find skimming over Angular code incomprehensible.
For web apps, jQuery is "dead" in the same sense that string-concatenated HTTP responses are dead.
They certainly exist and are used, but there is a level of abstraction (templates) that supercede -- or should supercede -- that functionality for most developers most of the time.
If I'm writing a "hello world" web server, I probably won't be using templates. But if I'm writing a web server serving HTML that I want to be maintainable at any non-trivial complexity, I'll be using a framework/library.
Sure, you can use jQuery, and yes Angular uses it (or jqlite) for cross-browser DOM interaction, but that will not be the predominant or most visible tool in any moderately complex web app.
Front end development is coming around to the advantages of MVC, and the current generation of tools reflect that.
jQuery is not dead; it is simply no longer the highest level of abstraction for creating web apps.