Alternately limit yourself to some small number of lines of JavaScript per page, and just generate all of your pages server side. Most tools don’t need anything more than that.
Yeah, that’s pretty much exactly what I’m doing (see the last section, after the fleurons). But even for sites with limited JS (like, say, Lobsters) I find that jQuery is a big advantage with a comparatively small cost.
The main problem with that is that frontend and backend become too interlinked, which is often annoying. That’s one of the main arguments for separating frontend and reducing the connection to a small and stable API (stable in terms of interface).
Just because a website is JS heavy it doesn’t mean you have to introduce Angular/React/Vue/…etc and fuck it all up with pointless complexity.
Proper “one page” websites can work just fine, especially for websites that aren’t hugely complex where you can get away with a few tricks that ease state management.
Well, yes, in certain cases that’s totally reasonable. But it depends on the product itself.
I’ve worked on projects where we essentially had a front+backend that we called “frontend” and treated as a frontend (it’s purpose was just to generate views and send https requests, this was done on either the browser on the server depending on the case) and the various “backend” services were essentially separate components handling parts of the business logic (e.g. auth, query APIs over various data stores)
But in the case of small projects, or projects which are very frontend-centric that kind of separation might be overkill…
For example, for something like lobste.rs that kind of separation would be overkill. For something like reddit.com (with the added layers of advertising, advanced moderation and Chinese censorship and spyware) it might well make sense.
As with “goto’s are evil”, jQuery isn’t bad per se and I feel that people some people are taking these sites as “why you might need jQuery” as an absolute truth.
The way I always understood it was not to include all of jQuery if you just need to do one specific thing, such a send a AJAX request, hide an element of traverse the children of a DOM node. “You might not need jQuery” should signal that the default position isn’t “add jQuery and then let’s see where we’re going to go”, but “add jQuery, if we can see that it’s really going to help”.
My problem with jquery is that it always starts innocently. Just a sprinkle here and there. Where do you keep those files? Just put them in /scripts, it’s just a few files.
But wait, now we want to add some more functionality to this particular piece. Actually, you know, this would be better if we wrote it as a module. Let’s make it a jquery plugin.
Hmm, I like how that piece works, what if we had this other part of the page work as a module too? We can just make another plugin.
Hey, it’d be great if these two worked together. We should add something that will help them communicate.
All the while, these files live in a big mess inside /scripts with all the other “one-off” files for functionality.
If you’re truly only using jquery in a few places and it’s more for things like toggling, creating tabs, things like that, sure, fine, go ahead. But once you start adding in functionality that requires more complex logic and state, you really should go with a library that is made for that specific purpose. It’s easy to let it slip into that over time with “small additions” and I’ve seen it so many times. Then you end up asking the question “is it worth rewriting this in the appropriate manner, or do we continue doing patches and bug fixes on our rat’s nest of jquery?”
If you work in UI extensively, you see this happen repeatedly, and there’s always someone who is not familiar with UI (and generally totally ignorant of JS) who is vehemently opposed to client-side code altogether who is pushing for the jquery rat’s nest without even knowing it.
I know it’s hugely popular here to hate on JavaScript and client-side code, but it’s not 1995, the web is not a series of documents. It’s a bunch of stuff. Applications, videos, documents, text files, all sorts of stuff. Anyone who argues against the power of what you can do with client-side JS is fooling themselves. There are all sorts of amazing applications written in the browser and the architecture and planning in them is similar, if not the same, as most other web software projects.
So, I have been building rich clients in JS for ~10 years now (2+ years each in jquery, backbone, angular, and react), so I feel pretty qualified to comment.
If you take a team who would produce a jquery rats-nest, and give them react, they will produce a react rats-nest.
jQuery isn’t the problem. The problem is a cultural disregard for structure, composition, and safety in frontend projects.
jquery doesn’t have any sort of guidelines for how to build an app. There is nothing like create-react-app for jquery and never has been. They’re solving fundamentally different problems, and that’s why the jquery rat’s nest exists. Sure, you can put all of your code in one folder for React if you really want, but the community around it is not at all going to have people do that. Most tutorials are structured similarly and there are a ton of “best practices” guides out there.
Jquery isn’t made for full applications. It’s apples and oranges.
React is (imo) the nicest of the options I’ve used. If I’m building something with state on the client, it’s the first thing I reach for (after making an offering to the old gods, to atone for putting state on the client).
Most of the best practice guides I’ve read, however, are by people with 1-2 years react experience. They largely promote harmful structures that keep your code maintainable for a year or so. I should write a whole blog post on this, but essentially the react community has largely not noticed how much nicer things work when you use props for composition (instead of higher-order components / redux).
My personal favorite web development pattern (when I can get away with minimal client state), however, is:
Bind all application event handlers to the document (‘live mode’ event handlers) with a data attribute to target elements (eg [data-hook="autocomplete-user-login"].
All AJAX requests return HTML snippets, which replace an existing node. No other behavior in response to ajax success. All loading and error states are server-rendered (hidden by default), with conditional classes to show/hide.
All AJAX requests update window.location. Reloading the page will give you the same content (pre-rendered) that you got via AJAX.
When I follow this pattern, I end up with pages weighing < 50kb on first load and ~5kb on subsequent loads. They appear and render ~instantly even on ancient devices, and all the usual affordances (ex: middle-click for new tab, copy link and send to another device) work correctly.
I think this is not an unreasonable reply; as I mentioned in the article I don’t think jQuery is a solution for everything. Yet I do feel that it works well for quite a lot of very useful websites including, say, Lobste.rs. Would this site be better with a state-keeping framework like React? Probably not; some “progressive enhancement jQuery” works quite well, even for non-trivial apps.
I agree jQuery can become messy if you’re not careful; but I also think there is a way to write applications in such a way that it scales reasonably well (up to a certain level, but certainly beyond “just toggling”). It doesn’t need to becomes a mess (that is the topic of another post, I suppose).
I know it’s hugely popular here to hate on JavaScript and client-side code, but it’s not 1995, the web is not a series of documents. It’s a bunch of stuff. Applications, videos, documents, text files, all sorts of stuff.
As an counter-argument, a lot of website really are just a series of documents. The New York Times really doesn’t need to load 1MB of JavaScript (986.54K at the time of writing, minified and compressed!) I know part of that is the whole advertising stuff, but the two top files are 500k and all NYT’s. The vendor.js file is 300K of React and plugins. I’m not privy to their design decisions, but I don’t think the NYT needs to be a React app, and feel the UX would be better if it wasn’t.
There are many more examples to be found, but that in general you can detect React apps is indicative that things are not all that great in React-land, either. It takes close to 10 seconds for a NYT article to properly load on my machine – with a warm cache! It takes a while for text to load and I can’t scroll at all (pressing Down does noting; tested with this page, which happened to be on top in my history). If I disable JS it’s near-instant, as you would expect.
I agree that “you don’t need JS” like it’s 1995 is foolish, but “you need React” (replace “React” with $your_favourite, if you want) is even more so, and is being blind to the problems that come with the React approach.
This is one aspect that actually really bothers me about the JavaScript community: if you state that you’re not sure that the React approach is a good one and feel a simpler one might be better for many sites you get dismissed as a greybeard stuck in 1995. Someone on Reddit called me “the anti-vaxer of development” as I refused to “accept the expert opinion, just like the anti-vaxers” 🤷 Things are not that black and white. The React approach is not perfect. It can be very slow, hard to get correct (especially if you care about things like middle-click or back button working), buggy (state is nice, but broken state is broken app), etc.
That doesn’t mean that React doesn’t work – obviously it does – but I’m not at all convinced that it’s a good way to develop complex apps. jQuery clearly also isn’t, so I’m not sure what is. I should perhaps re-survey the current ecosystem as my information is about two years old (a geological timescale, in JS-land). Either way, my point of this post wasn’t to compare jQuery with React, but jQuery with vanilla JavaScript, which is not exactly the same.
Someone on Reddit called me “the anti-vaxer of development” as I refused to “accept the expert opinion, just like the anti-vaxers”
That’s a really weird thing to say. Maybe they’re the homeopathic pusher of development? Always chasing the newest fad, diluting functionality down with unlimited filler?
I think we actually agree on these points. I don’t think every web site should be an entire application, nor do I think JavaScript has no usage. That said, even sites like the New York Times, although not an application, benefit from JS modules and visualizations that bring their stories to life. I used to work at USA Today and we did a lot of stupid things (the entire site is a backbone app with overlays all over the place) but it was in the name of revenue and more clicks, not because it was “cool.” I still talk with some former coworkers there and, after I left, they tried a different design that got rid of some of the JS-y interactions. Clicks dropped, time spent on site dropped, etc.
What I’m trying to say is, despite what technical people like us think about much of this stuff, the common user really doesn’t care that much if it is 500k of JS or if it’s 500b. They want a site to do certain things that static sites just can’t do. If our users are happy with a sprinkling of JS here and there, great, use jquery if you really want and slap some things together. If they want a full “application” experience, you really need to think beyond jquery and look at a lib or framework made for that task
No way to verify – while I’m on mobile – whether the website uses jQuery for its stylesheets, but it is impossible to click on hyperlinks on Firefox, iOS – text changes size on every touch down/up, hyperlinks don’t stay at their place. I’m willing to bet the offender must be jQuery overriding some default behavior.
I haven’t had time to look at it in depth, and that I can’t seem to use Firefox’s inspector tools with Linux isn’t helping (Firefox on iOS is really just Safari, since Apple doesn’t allow anything else). I thought it was “fixed” by tweaking the values anyway; sigh.
So the options for now are either to make links hard to use on iOS, or use suboptimal text sizes for everyone else.
I thought people saying “don’t use jQuery” instead say “Use React/Vue/some other full framework,” which is really overkill for some simpler things (especially non-web apps / enhanced content). For those you should certainly use jQuery as it does have a lot of tests cases to make sure its functions work correctly across a lot of browsers.
I’m still using jQuery in 2019 because it’s a dependency of intercooler.js, which is the most reasonable way I’ve found of progressively enhancing server-rendered HTML and CSS.
Alternately limit yourself to some small number of lines of JavaScript per page, and just generate all of your pages server side. Most tools don’t need anything more than that.
Yeah, that’s pretty much exactly what I’m doing (see the last section, after the fleurons). But even for sites with limited JS (like, say, Lobsters) I find that jQuery is a big advantage with a comparatively small cost.
The main problem with that is that frontend and backend become too interlinked, which is often annoying. That’s one of the main arguments for separating frontend and reducing the connection to a small and stable API (stable in terms of interface).
Just because a website is JS heavy it doesn’t mean you have to introduce Angular/React/Vue/…etc and fuck it all up with pointless complexity.
Proper “one page” websites can work just fine, especially for websites that aren’t hugely complex where you can get away with a few tricks that ease state management.
This is because people insist on treating the code that runs in the browser as their ‘frontend’, and the code that generates HTML as their ‘backend’.
Your ‘business logic’ need not live in the same app as your HTML generation, and neither should happen in-browser.
Well, yes, in certain cases that’s totally reasonable. But it depends on the product itself.
I’ve worked on projects where we essentially had a front+backend that we called “frontend” and treated as a frontend (it’s purpose was just to generate views and send https requests, this was done on either the browser on the server depending on the case) and the various “backend” services were essentially separate components handling parts of the business logic (e.g. auth, query APIs over various data stores)
But in the case of small projects, or projects which are very frontend-centric that kind of separation might be overkill…
For example, for something like lobste.rs that kind of separation would be overkill. For something like reddit.com (with the added layers of advertising, advanced moderation and Chinese censorship and spyware) it might well make sense.
Sure. For small projects like this, it’s not a problem that the frontend and backend are interlinked, though.
What’s troublesome is when they grow :/
Not especially… the whole point of KISS is that you can very quickly refactor the code if you notice the project is out-growing it’s original specs
Unfortunately, opinions about what constitutes Simple appear to vary wildly.
For DOM, I haven’t used either of the following myself, but I’m interested in this:
https://redom.js.org/
For something more about manipulation of existing elements (like jQuery), I like the idea of this:
https://blissfuljs.com/
For animations, I’d just use CSS and toggle classes with JS if necessary.
For requests, I use this:
https://github.com/github/fetch
If you’re comfortable with jQuery, I don’t see any problem with it, it’s still a perfectly valid choice in some situations.
This resonates with my opinion. Generally I agree with the article.
As with “goto’s are evil”, jQuery isn’t bad per se and I feel that people some people are taking these sites as “why you might need jQuery” as an absolute truth.
The way I always understood it was not to include all of jQuery if you just need to do one specific thing, such a send a AJAX request, hide an element of traverse the children of a DOM node. “You might not need jQuery” should signal that the default position isn’t “add jQuery and then let’s see where we’re going to go”, but “add jQuery, if we can see that it’s really going to help”.
My problem with jquery is that it always starts innocently. Just a sprinkle here and there. Where do you keep those files? Just put them in
/scripts, it’s just a few files.But wait, now we want to add some more functionality to this particular piece. Actually, you know, this would be better if we wrote it as a module. Let’s make it a jquery plugin.
Hmm, I like how that piece works, what if we had this other part of the page work as a module too? We can just make another plugin.
Hey, it’d be great if these two worked together. We should add something that will help them communicate.
All the while, these files live in a big mess inside
/scriptswith all the other “one-off” files for functionality.If you’re truly only using jquery in a few places and it’s more for things like toggling, creating tabs, things like that, sure, fine, go ahead. But once you start adding in functionality that requires more complex logic and state, you really should go with a library that is made for that specific purpose. It’s easy to let it slip into that over time with “small additions” and I’ve seen it so many times. Then you end up asking the question “is it worth rewriting this in the appropriate manner, or do we continue doing patches and bug fixes on our rat’s nest of jquery?”
If you work in UI extensively, you see this happen repeatedly, and there’s always someone who is not familiar with UI (and generally totally ignorant of JS) who is vehemently opposed to client-side code altogether who is pushing for the jquery rat’s nest without even knowing it.
I know it’s hugely popular here to hate on JavaScript and client-side code, but it’s not 1995, the web is not a series of documents. It’s a bunch of stuff. Applications, videos, documents, text files, all sorts of stuff. Anyone who argues against the power of what you can do with client-side JS is fooling themselves. There are all sorts of amazing applications written in the browser and the architecture and planning in them is similar, if not the same, as most other web software projects.
So, I have been building rich clients in JS for ~10 years now (2+ years each in jquery, backbone, angular, and react), so I feel pretty qualified to comment.
If you take a team who would produce a jquery rats-nest, and give them react, they will produce a react rats-nest.
jQuery isn’t the problem. The problem is a cultural disregard for structure, composition, and safety in frontend projects.
jquery doesn’t have any sort of guidelines for how to build an app. There is nothing like
create-react-appfor jquery and never has been. They’re solving fundamentally different problems, and that’s why the jquery rat’s nest exists. Sure, you can put all of your code in one folder for React if you really want, but the community around it is not at all going to have people do that. Most tutorials are structured similarly and there are a ton of “best practices” guides out there.Jquery isn’t made for full applications. It’s apples and oranges.
React is (imo) the nicest of the options I’ve used. If I’m building something with state on the client, it’s the first thing I reach for (after making an offering to the old gods, to atone for putting state on the client).
Most of the best practice guides I’ve read, however, are by people with 1-2 years react experience. They largely promote harmful structures that keep your code maintainable for a year or so. I should write a whole blog post on this, but essentially the react community has largely not noticed how much nicer things work when you use props for composition (instead of higher-order components / redux).
My personal favorite web development pattern (when I can get away with minimal client state), however, is:
[data-hook="autocomplete-user-login"].window.location. Reloading the page will give you the same content (pre-rendered) that you got via AJAX.When I follow this pattern, I end up with pages weighing < 50kb on first load and ~5kb on subsequent loads. They appear and render ~instantly even on ancient devices, and all the usual affordances (ex: middle-click for new tab, copy link and send to another device) work correctly.
I think this is not an unreasonable reply; as I mentioned in the article I don’t think jQuery is a solution for everything. Yet I do feel that it works well for quite a lot of very useful websites including, say, Lobste.rs. Would this site be better with a state-keeping framework like React? Probably not; some “progressive enhancement jQuery” works quite well, even for non-trivial apps.
I agree jQuery can become messy if you’re not careful; but I also think there is a way to write applications in such a way that it scales reasonably well (up to a certain level, but certainly beyond “just toggling”). It doesn’t need to becomes a mess (that is the topic of another post, I suppose).
As an counter-argument, a lot of website really are just a series of documents. The New York Times really doesn’t need to load 1MB of JavaScript (986.54K at the time of writing, minified and compressed!) I know part of that is the whole advertising stuff, but the two top files are 500k and all NYT’s. The vendor.js file is 300K of React and plugins. I’m not privy to their design decisions, but I don’t think the NYT needs to be a React app, and feel the UX would be better if it wasn’t.
There are many more examples to be found, but that in general you can detect React apps is indicative that things are not all that great in React-land, either. It takes close to 10 seconds for a NYT article to properly load on my machine – with a warm cache! It takes a while for text to load and I can’t scroll at all (pressing Down does noting; tested with this page, which happened to be on top in my history). If I disable JS it’s near-instant, as you would expect.
I agree that “you don’t need JS” like it’s 1995 is foolish, but “you need React” (replace “React” with $your_favourite, if you want) is even more so, and is being blind to the problems that come with the React approach.
This is one aspect that actually really bothers me about the JavaScript community: if you state that you’re not sure that the React approach is a good one and feel a simpler one might be better for many sites you get dismissed as a greybeard stuck in 1995. Someone on Reddit called me “the anti-vaxer of development” as I refused to “accept the expert opinion, just like the anti-vaxers” 🤷 Things are not that black and white. The React approach is not perfect. It can be very slow, hard to get correct (especially if you care about things like middle-click or back button working), buggy (state is nice, but broken state is broken app), etc.
That doesn’t mean that React doesn’t work – obviously it does – but I’m not at all convinced that it’s a good way to develop complex apps. jQuery clearly also isn’t, so I’m not sure what is. I should perhaps re-survey the current ecosystem as my information is about two years old (a geological timescale, in JS-land). Either way, my point of this post wasn’t to compare jQuery with React, but jQuery with vanilla JavaScript, which is not exactly the same.
That’s a really weird thing to say. Maybe they’re the homeopathic pusher of development? Always chasing the newest fad, diluting functionality down with unlimited filler?
I think we actually agree on these points. I don’t think every web site should be an entire application, nor do I think JavaScript has no usage. That said, even sites like the New York Times, although not an application, benefit from JS modules and visualizations that bring their stories to life. I used to work at USA Today and we did a lot of stupid things (the entire site is a backbone app with overlays all over the place) but it was in the name of revenue and more clicks, not because it was “cool.” I still talk with some former coworkers there and, after I left, they tried a different design that got rid of some of the JS-y interactions. Clicks dropped, time spent on site dropped, etc.
What I’m trying to say is, despite what technical people like us think about much of this stuff, the common user really doesn’t care that much if it is 500k of JS or if it’s 500b. They want a site to do certain things that static sites just can’t do. If our users are happy with a sprinkling of JS here and there, great, use jquery if you really want and slap some things together. If they want a full “application” experience, you really need to think beyond jquery and look at a lib or framework made for that task
No way to verify – while I’m on mobile – whether the website uses jQuery for its stylesheets, but it is impossible to click on hyperlinks on Firefox, iOS – text changes size on every touch down/up, hyperlinks don’t stay at their place.
I’m willing to bet the offender must be jQuery overriding some default behavior.This is an iOS/Safari specific issue with media queries. See: https://lobste.rs/s/tz3pht/viewport_iphone_reflow#c_pdzfv7
I haven’t had time to look at it in depth, and that I can’t seem to use Firefox’s inspector tools with Linux isn’t helping (Firefox on iOS is really just Safari, since Apple doesn’t allow anything else). I thought it was “fixed” by tweaking the values anyway; sigh.
So the options for now are either to make links hard to use on iOS, or use suboptimal text sizes for everyone else.
[Comment removed by author]
In any case, it works in iOS Safari’s reader mode.
I thought people saying “don’t use jQuery” instead say “Use React/Vue/some other full framework,” which is really overkill for some simpler things (especially non-web apps / enhanced content). For those you should certainly use jQuery as it does have a lot of tests cases to make sure its functions work correctly across a lot of browsers.
I’m still using jQuery in 2019 because it’s a dependency of intercooler.js, which is the most reasonable way I’ve found of progressively enhancing server-rendered HTML and CSS.