> In my experience server-side generated templates lightly sprinkled with “progressive enhancement”-style JavaScript are still the best way to do that. Those apps are easier to develop, tend to be faster, tend to have fewer bugs, and your laptop’s fan won’t wake the neighbours.
Thanks for that part. Really. A heartfelt thank you. Every time I see another "hey, I only want to show you text, but for some reason I thought using one of the modern js frameworks for it is a good idea" pages I feel years older. Instead of showing me text using html they pack that text in js on the server (it usually exists in an html compatible form already), then they shove that JS down the connection, then my browser has to interpret the JS, so it can get the html, which it then has to interpret too. And then, finally, I see my text.
And because all of this is so slow we get techniques like "server-side rendering". The first time I read about server-side rendering I didn't understand what it was: so, you produce the html on the server. And send it to the client. Yes ..? What is the new part? Why is this something that people present as the next savior of the web?
This is some special kind of madness and I wonder when it will stop.
This is the part that often gets forgotten in these discussions: it shouldn't be "SPA for everything" vs. "vanilla HTML / CSS / JS for everything"; rather, we should be using the most appropriate set of tools for the job.
I've worked on simple static sites, for which I typically lean more on vanilla HTML / CSS with a sprinkling of JS as recommended here. I've also worked on heavy-lifting applications, for which the limitations of this approach quickly become evident; in those cases, I use reactive component frameworks like Vue and React.
But there's also approaches in between! For mid-complexity sites / apps, I've used vanilla HTML / CSS / JS, with some additional Python / Makefile plumbing to generate more repetitive parts. I've also used hybrid approaches, where vanilla HTML / CSS / JS is used for more static parts of the site and Vue is used for more dynamic parts. You can use Vue in full-on SPA mode with "server-side rendering"...but you can also just generate HTML server-side as you would have before, then progressively enhance parts of it with Vue / jQuery / whatever.
I've also used "unfashionable" frameworks like Spring before, simply because it met the client's available in-house expertise. As developers, it's incumbent upon us to step back, assess the task / team / environment at hand, and pick tools accordingly.
On a side project I recently tried the middle ground approach and absolutely loved it. There was really only one part of the application that had complex user interactions, so that was the only place that I shipped a React bundle. The rest was just plain ol' templates and HTML.
On the whole, I'd say that I loved it. It is _staggering_ how quickly you can knock pages out when you're not coordinating data representations across different pieces of your app. The static-ness also lets you embrace a kind of UI feature simplicity. Does that form _really_ need live validation, or can we just pop the errors after submit? The latter is the only option unless you wanna (a) either vanilla Javascript or JQuery the interactions or (b) start shipping a React bundle down to this page. And thus, form validation was part of the request/response cycle, which further speeds up development.
It does get a little awkward when a static page starts having dynamic features begin to creep in. You have to decide when to awkwardly cut over to having that page powered by React.
That said, without a framework supporting this kind of development directly, I'm skeptical of how well it would work on a team. I did this style on a solo project, so there was no one complaining about 'mixing technologies' or bemoaning 'why don't we just use React everywhere.' I imagine that the first time we rewrote a page in SPA tech because it picked up enough UX to warrant it, people would be up in arms about how much time we've 'wasted' by not doing it in the first place.
AT&T’s website account pages only serve static html. But they are rendered by js and I have to wait looking at a loader after every click.
Why is that?
Why do so many static websites and blogs use SPA technology for all their pages?
It can’t be that it’s just to make me mad (although it works). Are people insane? How does spending 10x the $ and effort for a worse result make sense?
Yep. This is one of the reasons that so many people are excited about Phoenix Live View being released. It bridges that gap much farther and let’s you avoid the SPA until you hit the “is absolutely necessary” point.
I've made quite complex web apps with pure CDN-imported (i.e. no Webpack/NPM) Vue as a starting point. They work well, are easier to debug, and get the job done faster. Of course, it's a good idea to take that monolithic JS file and split it up into components for easier future work, but I've found that working like this leads to fewer "tooling hell" headaches.
My rule of thumb is if you arent building some social / multimedia type of experience a SPA wont do much for you that you cant get done with HTML and CSS.
Currently dealing with a situation where a SPA app doesn't work with FB Sharing, because it exepects a set of META/Open Graph tags. So now we are going back to rendering a portion of the HTML on the server to support this.
In JIRA, if I hit enter in the wrong field, it does a post out to somewhere and returns me a weird xml page and I lose my work.
SPA apps are like building a browser, in a browser, and on the server. You lose some built in functionality and have to ship the framework down to the client.
JIRA is a case study in bad UI/UX and web anti-patterns, IMHO. I think my team at work is finally ready to ditch it in favor of basically anything else.
One of the managers at work swears that JIRA is the next great thing to happen to us. From all the negatives I have heard I get the feeling that the request to adopt it getting stuck somewhere in our parent company is a good thing.
The worst I've seen is where the main content is served (if you curl the website, you can see the text content is there), but it's hidden by a full-page loading animation which is removed by JS.
The saving grace in these cases is that often the reader mode would work with the HTML just fine and you don’t need to wait for the useless 3MB JS bundle which you may have blocked. The same reader mode trick sometimes works against subscribe-to-read-the-rest-of-the-article paywalls and no-scroll anti-adblock modals, too.
Of course I agree that if you’re only showing text with a few interactive enhancements, you can probably get away with jquery. The trouble is that too often a few enhancements turns into a few more enhancements, then a lot of enhancements, and then you end up with a huge mess of jquery spaghetti. It quickly becomes comical to claim that jquery would result in fewer bugs than pretty much any post-backbone UI library or framework you can think of.
I don't use jQuery much these days, but you can absolutely write quality jQuery code that is well structured and architected. It doesn't need to devolve into spaghetti code. It doesn't have guard rails like some frameworks might, and it's base examples don't really promote non-spaghetti code, but it's not that difficult for experienced JS devs to write good, high-quality jQuery code.
Which explains the idea much better than I ever could.
Two things had me sold on this:
1. They managed to make the thing so easy to use, that even people who's line of work involves mostly Excel sheets were able to create something useful after a short introduction.
2. The output is relatively readable JS. There are some surprises like a few one-letter method names, but overall you could open up the source of a running Svelte app(provided it weren't minified) and figure out what it's doing just by reading the code.
I've seen the flip side of the coin in an app I inherited at work - it turns out server-side rendering can be significantly slower than client side rendering if you're rendering a lot of content, to the point where we hit an automatic timeout. If this app was a fat JS app, we probably wouldn't be trying to decommission it & it probably would load in seconds at worst, but the investment to modernize it/improve performance & scalability so it would meet our users' needs is too much.
That’s true in a lot of cases mainly because of the approach to rendering. So many languages focus on rendering the entire HTML structure before sending the first byte back, specifically so that the page can be wrapped in a cache. This forces a lot of memory allocation to build up strings and parts of strings that takes time on its own, is often repetitive over the same HTML tags and then all of that has to be garbage collected at the end of the request.
The approach taken by Elixir’s Phoenix framework is so fast because it avoids all of those pitfalls. Most people have to do a double take when they see the speed comparisons.
Your older app may be serializing a lot of work. For instance, it could be issuing 10 SQL queries, one after another, which take 200ms each to answer - that's 2s total just waiting for the database. Compare to a JS client which issues 10 backend API calls, each being a 200ms request from the server's perspective (and the JS may parallelize many of those requests)
If this is a factor, rearchitecting the backend wouldn't necessarily be easier than an SPA rewrite. But it's not a fundamental limitation of server-side rendering.
Why stop now when we got so much out of it? Maybe we will have even better solutions coming now that we have learnt so much.
It's like "Please stop enhancing stuff it's good enough" - I like to enhance stuff, yeah it has costs but you can master them. That's definitely not the end of it. I hope we will do better. Maybe your "problems" will be resolved as well!
> Has it occured to you you might simply not understand the advantages of this approach?
I find it pretty rude to use the "you don't like it because you don't understand it" argument. I build SPAs at work, I know their benefits, and I still believe that they're more difficult to develop than adding JS on top of classic HTML (not saying they're worse, but certainly I don't find them easier).
> So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. If it were, developers would not be flocking en masse towards SPAs and the like. Those are gaining traction because they are easier to develop and easier to maintain.
I'd say that we, developers, often move to overcomplicated and difficult tools/approaches. Or we move to tools that are simple only to see them grow in size and complexity. The fact that something becomes popular doesn't mean that it's necessarily better or easier to maintain.
Even the auto-frameworking approaches are starting to surpass old school web development for "classical" web purposes. I can tell when I'm on a static documentation site and things work almost instantly. JavaScript is both the reason why some websites feel faster and other websites feel slower.
I also think that being nice to mobile (data efficiency) and being fast (UX latency) are starting to show as moderately contradictory values.
Do you believe that SPAs are more difficult to build than building the same functionality with server-rendered HTML and jquery on top?
In my experience, that would only be true in the most trivial of SPAs. I’m thinking like a blog with AJAX “like” buttons. A good rule of thumb for me is that as soon as you have some interactive widget that involves adding and removing items from a list where the individual items also change interactively, you’re probably better off ditching jquery because things are about to get messy.
> I still believe that they're more difficult to develop than adding JS on top of classic HTML (not saying they're worse, but certainly I don't find them easier).
You're right, I should have been clearer. Emphasis on develop and maintain.
If you're just building a near-static site with, say, some slideshow that needs basic JS then I'd use jQuery too. I'm sure there's a bazillion plugins that already do what I want and it'll be done in 5 minutes.
But if you're building something that will scale beyond the current page, that will need more features in the future, etc then it's not a viable approach. And I'm not saying SPAs are necessarily the best choice/tool available, but they're definitely going to be easier to work with than HTML+jQuery, unless the requirements are ridiculously basic.
> I'd say that we, developers, often move to overcomplicated and difficult tools/approaches. Or we move to tools that are simple only to see them grow in size and complexity. The fact that something becomes popular doesn't mean that it's necessarily better or easier to maintain.
Lots of devs adopt technologies for fun; because the approach is interesting; because they want to learn; because they're bored with their current stack.
But this is different. This is a huge movement within the ecosystem moving towards a very specific model. The model is not necessarily the best in every situation, but the pros that come with it are significant.
And honestly, nowadays in modern browser JS, if an app is simple enough to build with jQuery, it's simple enough to build without any third party lib.
> You're right, I should have been clearer. Emphasis on develop and maintain.
Did you ever think that you might want to put the user experience first?
Look at YouTube with their great SPA. If I'm on mobile and not using a flagship phone with 3gb of ram, it's just great: I scroll through my search results which are these idiotic incrementally loading page, then I select a video, watch it and want to go back. Surprise! I see the loading spinner again an my scroll position is lost. State seems so broken with SPAs that it only ever works in some demo apps that were solely built to prove that you can have SPAs with a working back button. Great, I already had that on YouTube in 2006 with a fancy and handy feature called pagination for the search results.
But I guess once we kill Firefox this will become much better since Google will just do whatever the duck they want with the web.
This kind of terrible state management is super widespread and really annoying. I agree that lots of folks seem to have have spent the last few years thinking more about their build chain and tooling than about basic UX.
And this is why I like Parcel. It's by no means perfect but having pretty much zero config and still being able to jump into using pretty much whether system you want with a simple command is nice.
Frankly I thought jQuery was a horrific way of building stuff, and moving to a declarative approach like React is a huge step forward. Most complaints I've seen about it are due to incompetence or misunderstanding.
This specific example really just applies to all naive implementations of AJAX infinite scroll, which far predates the rise in popularity of SPAs.
Discourse, a forum written as a SPA in Ember, changes your URL as you scroll to each post. Even if you scroll down and let javascript load in more pages of content, the URL will reflect the post you’ve scrolled to, and will jump right to it if you go somewhere else then click Back, or just load the link:
> Did you ever think that you might want to put the user experience first?
I like react for SPA because it means It makes it easy to build a pretty solid user experience. The best example I had was when I was building the login + info portal for inflight wifi. We used server-side rendered React to give them an operational page without JS, and then enhanced it when the JS loaded in, and then precached additional content to make the pages load instantly.
The react + webpack ecosystem made this _really_ easy. Inlining the critical css for the base type + login form was stupid simple.
At the end of the day, there are lots of tools and its up to developers to find the best tools for the job. Sometimes, developers make the right choice. Other times, developers make the wrong choice. If you have a dysfunctional team/org, you're probably not going to build much great regardless of the tools you choose.
Whether pagination is saved (like ?p=6 in url) doesn't have anything to do with SPA vs SSR. Just like an SSR /search endpoint that uses POST over GET so you can't just save/share the query.
You're blaming SPA but as usual it's just people not caring about polishing application UX.
But in the YouTube case I don't even have pages! But anyways, When not going the SPA route I get all this for free. Navigating the search result pages automatically ends up in the history. 0 lines of Js required. Also since the whole page is generated server side even the scroll position within the result page is restored properly. Again 0 lines of Js. This already worked in the 90s. Today it doesn't, and we call it progress.
We had plenty of sites in the 90s breaking due to using POST on almost every navigation, or embedding a sessionid in the URL that would break the site when being bookmarked/shared
You could build even worse horrors using <form target="..."> to update frames/iframes... partial page updates without javascript. This still lives on in some oracle web applications...
> Did you ever think that you might want to put the user experience first?
As I've repeatedly explained in the comments, I'm not arguing that you should use an SPA, and I'm not arguing that SPAs have necessarily better UX. You still have to be a good dev.
SPAs are not footgun-protections and the issues you're listing are fairly easily solved. Maybe they're not natively solved by SPAs, but other approaches also have their natively-unsolved problems, so this is moot.
> But I guess once we kill Firefox this will become much better since Google will just do whatever the duck they want with the web.
I don't even know what you're on about or how it relates to this discussion. Did you mean to post this on a different article?
> I don't even know what you're on about or how it relates to this discussion. Did you mean to post this on a different article?
Nope, that was just a small addendum in relation to my example since experience has shown that often times the back button is broken in different ways depending on browser. Having just one engine left would at least mean some more consistency here, but that's about the only advantage I can see in that.
> So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. If it were, developers would not be flocking en masse towards SPAs and the like. Those are gaining traction because they are easier to develop and easier to maintain. Monumentally so.
Let me put it this way, both as a developer and user of SPAs, I have long since observed that SPAs, on average, tend to be much more resource intensive (it's not infrequent that my laptop fans start spinning), buggier, and harder to use. I don't think this is surprising, because "maintaining state" is great and all, but it also means that once that state goes sideways your app goes sideways, too.
Does this describe every SPA? No. Does that mean that every template app is better? No. But is the average SPA app worse than the average template app? In my experience it is (although I will admit I lack empirical data).
I don't think that popularity is a good yardstick. jQuery is clearly not the optimal way to develop web-apps – this post was never intended to argue as such, merely to argue that it's better than vanilla JS that I've seen advocated quite a lot recently – so people go to "alternative" solutions which lacks the problems jQuery has, but that doesn't mean these solutions don't create different problems on their own.
I don't know what the optimal way to develop webapps is, but I do know that the current generation of SPA frameworks isn't it. Probably some sort of hybrid approach, or a completely different one that hasn't been invented yet, is. In the meanwhile, a template-based approach is much easier to understand (less can go wrong), and is probably the best approach for many (though not all) websites.
I have no claims that SPAs are better end-user experiences out of the box. Your quote is about how easy it is to develop and maintain an SPA, not how good users have it after the fact (which entirely depends on how good your team is at building the app).
I'm starting to think I need to clarify that paragraph :/
I inserted the word "often" now: "Those apps are often easier to develop, tend to be faster".
The entire topic is complex, and like I said the main point wasn't about template vs. SPA, although I felt like something had to be said about it, as it's obviously related and something of an elephant in the room.
I don't think there is One True Way™, but I also feel that many apps are actually a lot less complex than people seem to think. For example the main competitor for the app I'm working on now (unpublished MVP that's still WIP) is a SPA, and I feel like my simple template-driven app has a much better UX. You just don't need all the complexity, there is so little benefit you might as well not bother. I think this describes many apps.
Would HN be better as an SPA? I don't think so, and I suspect that a "SPA HN" would be harder to develop and get right.
Probably - "Has it occurred* to you you might simply not understand the advantages of this approach?" makes you sound pretty dismissive of the parent comment's points.
Also - as someone who disagrees with you I don't see any compelling points in things like:
> "So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. If it were, developers would not be flocking en masse towards SPAs and the like. Those are gaining traction because they are easier to develop and easier to maintain. Monumentally so."
You're on HN - there's a huge chunk of us who are attempting to KISS web development. You're not wrong that React and Typescript are wonderful tools - but they're absolutely not the only way to develop things.
Also you may want to address people's worries about SPA development if you want to convince people it's not as bad as they're saying. (like performance - which is a huge reason I keep my light-weight vanilla-style apps the way they are)
I think there's a canyon between outright calling an approach "madness" and simply… understanding its advantages, yes.
Performance is a concern, and that's one of the main reasons why serverside rendering is being adopted as a technique. So when OP berates the existance of SSR, I have to wonder if they understand the larger picture. If it's rude for me to point this out, I apologize for being rude; my point still stands, though.
I don't think the SPA approach is the end-all-be-all but I'm definitely happy to have adopted it for my current project (a mid-size web app mixing classic list views and a few more complex bits and pieces here and there). Had I done it with jQuery, I'd still be building it; and had I done it in my classic hybrid approach, I would not have as many options as I currently do when building new pages/views.
I think you need to clarify as well, because if someone tells me it is easier to maintain solution X than solution Y I naively expect it must be because solution X's users will have it better than solution Y and complain less, requiring less fixing of user experienced problems.
Do you have an example of a “template app” that has anything even close to the actual feature complexity of an average SPA? Unless you control for that, I’d be willing to guess that the difference in bugginess is simply due to SPAs having a more complex set of features.
> Do you have an example of a “template app” that has anything even close to the actual feature complexity of an average SPA?
How about rewritten apps like reddit, that's as like for like as you can get? There are a bunch of apps/categories (things like JIRA) that were once template style and are now SPA style, the SPA version are nearly always worse.
I'm an old php dev, still doing server side development exclusively, and these are genuine questions:
1. What tooling is there available? Do you mean something along the lines of vim or IntelliJ?
2. How do these techniques make the user experience better, compared to e.g. ajax?
So here's the thing about the JS world: You have access to essentially all the tooling ever developed for frontend dev. Linters, code formatters, IDEs, etc. Tons of crazy techniques invented to speed up development (hot-reloading in various frameworks; remote debugging with the various browser inspectors…).
All this becomes available to your server development experience the moment you choose to share the language. And having developed with Python for over a decade, I can safely say I no longer enjoy doing that after seriously using typescript for just under a year. This also does have to do with the IDE; VSCode with TypeScript is a better dev experience than Python with any of the popular Python IDEs, even with added typings (python types are awful).
> 2. How do these techniques make the user experience better, compared to e.g. ajax?
They don't. They do enable you to take advantage of them in order to make a better user experience, but you still have to actively pursue that. Someone gave the example of Reddit lower down which is possibly the worst SPA I've ever seen on a popular site. OTOH, if you look at well-built NextJS websites, they're often ridiculously fast both to load and to use.
> If it were, developers would not be flocking en masse towards SPAs and the like.
Argumentum ad populum. That's not an indicator of something being better. I do like using the modern SPA frameworks for well, (web)apps but I strongly disagree with using them in every case.
This has nothing to do with an "Argumentum ad populum". I'm saying devs are flocking towards it because it's a lot easier to work with and maintain.
There's a lot of reasons why this is true. One is using a single programming language. Another is having the server app be aware of the entire app rendering rather than just templating-in bits and pieces. I could go on but that's not the point I'm trying to make.
> I'm saying devs are flocking towards it because it's a lot easier to work with and maintain.
Two things: first, my experience (and perhaps definition) of "easy" is different. I wrote an entire different post about that[1], but the tl;dr is that SPA may be easy to make things with, but it's hard to debug things, which is a more important measure of "easy" IMHO.
Another example would be accessibility (screen readers, etc.) Last time I tried, it was much harder to get that right with SPAs (not impossible, just hard).
Second point is that there are many other factors than "easy to work with and maintain". I already mentioned some of that in my other reply.
I agree with the definition of "easy" in your post, and Docker is an excellent example of hell on earth. But I've not had that poorer debugging experience with SPAs, so I don't see what makes them harder to debug. I can't possibly have gotten that lucky?
The hardest problems I've had to debug on my SPAs usually had nothing to do with the SPA stuff and more things such as obscure yarn or typescript bugs/behaviour. These classes of bugs exist in all languages and frameworks.
> Another example would be accessibility (screen readers, etc.) Last time I tried, it was much harder to get that right with SPAs (not impossible, just hard).
I'm very confused about this. What about SPAs makes this any different than regular boring HTML? If anything, having easier access to a component model should make it easier.
> If it were, developers would not be flocking en masse towards SPAs and the like. Those are gaining traction because they are easier to develop and easier to maintain. Monumentally so.
Bandwagon fallacy. In all fairness popularity is never a qualified descriptor of competence or performance.
> Has it occured to you you might simply not understand the advantages of this approach?
> Putting aside how useful it is to only have one language to learn in a stack...
Glad we are not talking about this - I'd have to point out that "I do not have to learn/understand" is a bad continuation when one starts with the claim the other was ignorant.
Decreasing stack complexity is a noble goal, regardless of how familiar you are with the stack as a whole. If a project used both cmake and autoreconf, you'd probably be the first one to call for a rewrite of one to the other (or both to your favourite third).
It decreases onboarding time, simplifies hiring, and reduces cognitive load when you yourself have to work with it.
If you want to decrease complexity the first thing to go would be the modern front end stack with it's own build tools, package managers, run times, servers and languages.
Server-side rendering is the best front-end architecture at the moment. Superior first content paint and is better at SEO than SPA, and have a better architect than MVC.
So in what way does if differ from traditional MVC? In MVC, the final output is HTML strings. Easy example: supposed you have an array of Posts in your controller, and a HTML template. The final result will be the combination of both of them. But when the HTML strings get sent to browser, you lose the array !!! It's gone. The client never receives an actual array, just DOM nodes.
In Front-end framework SSR (NextJS or NuxtJS), what you work with is a component. A component can have data (an array), and the data is pushed (serialize) as-is to browsers. On the browser, you won't ever have to work with low level DOM nodes. You continue to see the component and data in its original form. This is the biggest win of SSR that is easily overlooked.
I'm heavily inclined to agree with this. In fact, only this weekend I was working on a very simple one page tool and from the get-go I decided to adopt this "vanilla" only approach, i.e no JS libraries really at all.
Pretty quickly I found myself wishing I had just used jQuery or at least some other library to make stuff easier and get things done faster. When I finally got it completed in the end I wasn't sure why I bothered to struggle and waste so much time instead of just including jQuery and making things a bunch easier and less verbose. Sure, there may be other libraries worth using instead but the point against the "vanilla JS is all you need" argument.
I actually found the cited website in this post http://youmightnotneedjquery.com to be so strange as examples of why you may not need jQuery that it may be satire. I was surprised to find out that it was not satire. So I actually forked it and created https://youmightneedjquery.com, on which I may change some text in the future. It may not load for you yet as the DNS propagates.
The text of You Might Not Need jQuery says the following:
> If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency.
Maybe I am mistaken but it seems to me that this site targets library developers who use jQuery without realizing that they're forcing it on users as a transitive dependency. It does not seem to apply to end-users writing simple tools.
I don't disagree that you should know core concepts of what you're writing. I write a lot of Go without any heavy abstraction libraries (i.e ORMs) and have done with others like PHP in the past too.
With abstraction there has to be a balance though. Sure, I concede that knowing how it works is actually important, hence why I've spent a lot of time doing things without libraries in the past, especially as I was learning. It actually enrages me when people who've only ever used ORMs make super basic mistakes when writing and executing SQL themselves for the first time, i.e selecting a bunch of relationships in a loop one by one, instead of getting them all in one query. Stuff like that is a good example of how only ever working with abstracted versions of your tech stack results in mistakes down the line that have costs, since the abstracted version doesn't explain these concepts to you.
However, when it comes to actually trying to get things done efficiently, abstraction can help a bunch. Writing a bunch of stuff from scratch every time is not particularly productive either.
> Writing a bunch of stuff from scratch every time is not particularly productive either.
If you were to describe that in offline terms applications would be like books and abstractions would be like parts of the books. In order to make effective use of the book you still have to read, from scratch (whatever that means). When you become well versed in reading and writing it doesn't feel like a chore and you become far more efficient at it than simply guessing at the material from selected paraphrases. Programming is no different.
I'm not really sure what you're saying at all? It seems like we have agreed but I simply cannot comprehend your example.
The point I was making is that we could all spend our time going as deep as possible with as little abstraction as possible and end up writing stuff in assembly because "it's important to know how something works".
There is always a cost/benefit with abstraction when it comes to getting things done.
The fetch API is nowhere as convenient as the jQuery one.
It requires craft to get addEventListener() on par with on().
jQuery comes with many implicits loops that save you time.
fadeIn() is easier to handle than the equivalent css. jQuery supports edge if you target it (things like prepend(), parent() work on it).
Error handling is just better. E.G: jQuery().val() will not raise an error if there is no match while document.getElementById().value will.
And probably a hundred of other little details that won't come out of my head but that will grind my gear if I start working on code.
Chaining is awesome to manipulate DOM. The imperative API is very verbose.
So. Many. Plugins.
I'm more of a VueJS guy now, but if I have only a quick page to setup, the 30ko of jquery are better than anything I can produce to wrap my repetitive code.
Yeah, that always passed me off. I had little trouble writing cross browser code, but to be helpful jQuery would add code especially for IE that always got in the way when debugging cross browser compatibility problems.
I realize you're just being argumentative, but whatever. As a programmer you should definitely be avoiding micro improvements until you absolutely need them. Premature optimization is the root of all evil. No sense in wasting development time with something that is currently not a problem.
I was not being just argumentative and I absolutely disagree about product improvement. Product improvement is refinement which is absolutely not premature optimization. I honestly believe you are fishing for excuses to qualify mediocrity whether for laziness or fear of the code.
This is exactly it summarised. It's more frustration at the extra verbosity I had to put in to do something I'd become so accustomed to doing in a line or two.
That was simplified code to create just one element and add it to the DOM.
Once you write it not once, but twice, or five times, you will either switch to a lib/framework, or to jQuery, or will write your own wrapper not that different from jQuery.
Not for something so simple. It's trivial to abstract small, oft-repeated actions like that to their own function. As I do, regularly. And then I can give it a readable name, like `createElement` or `insertElement` with an interface like:
Browsers are an interesting place since the language we compile to there is generally human readable when compared to assembly lang/machine code but that "more explicit" is something that we've come to reject in general development so I'm curious why it's persisted in the browser world. People[1] don't reject C/C++ because they're putting two much distance between you and the bare metal assembly statements, instead the tradeoff of readability and expressiveness is accepted as correct code is always better than fast code - so why in the browser do we still demand the bare metal option?
[1] Okay, there are some people, they're rare and generally regarded as weird.
Is more human readable to me than the jQuery abstraction (that pulls in piles of other potentially unused tooling) than:
$(document).append("div").text("Hello, world");
It's more verbose, sure. But like I said in another comment, if I have to repeat the methods more than twice I'd probably just wrap the couple of lines into a function, like:
function createTextElement(type: string, text: string): void {
const element = document.createElement(type);
element.textContent = text;
document.appendChild(element);
}
And anywhere that's called it's quite clear what is being done
createTextElement("div", "Hello world");
This seems to be preferred when writing C as well, no? Rather than abstracting common methods to more opaque symbols?
Maybe it's just me, but I prefer the English, descriptive version and I prefer working with code formatted the same way. The language (JS) has plenty of quirks as it is.
Comparing C/Assembly I don't think is a 1:1 fair comparison, though. Unless you're including TypeScript—which is how I tend to write JS anyway (whenever possible).
> if I have to repeat the methods more than twice I'd probably just wrap the couple of lines into a function, like:
I wrote in a sibling comment:
Once you write it not once, but twice, or five times, you will either switch to a lib/framework, or to jQuery, or will write your own wrapper not that different from jQuery.
That's a significantly newer syntax, so I wouldn't say it's "more idiomatic" than explicitly referencing the original function on the prototype (which is idiomatic to JS) and was the way to do it until the spread proposal, Array.from, and similar additions, what, ~5 years ago?
If anything isn't that code _less_ idiomatic in that it's less specific to JS and more of a generic operation?
In this instance I understood it to be idiomatic as it calls a JS Array constructor and iterates on the passed parameter to create it. It's been more common than the call/apply methods for years—at least as far as I've seen. The use of the array literal is always preferred, AFAIU.
I agree it'll probably become the new idiom in JS, but it probably needs another few years to begin taking over from the idiom that existed for decades before (and still works).
If you've seen that more common than call/apply for years then you probably work almost exclusively on new projects, with people that convert things to bleeding-edge, or with heavy transpilation: The spread operator as used there has only existed in regular released browsers/node for 3-4 years. I don't think it's a stretch to say the vast majority of code out there at this time won't be doing it that way.
Yeah could be. And my client base, as it were, are solely internal to the company I work for at this time and we have some knowledge and some cooperation over what versions of browsers people are using when it comes to web-based software. So support for older systems is largely unnecessary. That and building node backends the ES version doesn’t affect them anyway.
To give you an idea where I come from... I started doing front end in the late 90s, and for the past 5 or so years I've been mostly doing SPAs with Vue, React, Inferno, and Angular.
I'm done with SPAs and the whole modern front end workflow. If there was a solid benefit to a SPA it would make sense to endure all the complex development, ever changing ecosystem, etc, but in the vast majority of cases there is no benefit. Users don't care about SPAs, some of the most successful biggest websites are not SPAs (Amazon, Ebay, Wikipedia, etc).
A static site generator like Jekyll with some sprinkled JS offers a much better experience. When that is not enough a good old server side rendered app with sprinkled JS is the next step I will consider.
There are some perfectly valid use cases for SPAs but those are rare.
And don't get me started on libraries/frameworks figuring it out as they go along. jQuery has had a stable API and methodology like forever. React has made major changes in only 5 years. From createElement, to JSX, to classes, to stateless components, to hooks, and only god knows what they will come up with next year.
I'd like to introduce a new measure: Expected Complexity (EC)
Possible values:
--> Static webpage
--> There's a Form!
--> I can click things and the URL doesn't change!
--> I spend a few minutes on this site and click a few things
--> I spent a couple hours on this site and click lots of things
--> My office hours are spent clicking on things on this site!
How to determine at the start of development what EC value will be reached:
Using a crystal ball (as usual)
Pick your technology according to the value of EC.
There's a good chance that
(= :jQuery (choose-tech ["There's a Form!", "I can click things and the URL doesn't change!", "I spend a few minutes on this site and click a few things"])
The given example of element.nextSibling is a great example of what jQuery gets wrong. In jQuery, that's going to be $(el).next();
On first encountering $(el).next(), you need to answer a bunch of questions. Next what? Why is this a function and not a property of the object? Why not call it getNextSibling? What the hell is $() doing?
element.nextSibling is very clear. It's the next sibling of the element. It's idiomatic javascript, and it follows a good naming convention, which is a skill that is language agnostic.
The author is also conflating their time learning as a pro for jQuery. Had they learned vanilla javascript first, their point about not knowing which nextSibling to use would be moot. What they are referring to here is an idiosyncrasy, and jQuery is jam packed with them. The difference is they have learned them already.
If you learn jQuery today, you're not learning core JavaScript, and considering the trajectory of web technologies you'll be doing yourself a disservice not to use that learning time on actual JavaScript that you could use in future tools. jQuery isn't a bad choice if you know it already, but if you are a new developer do yourself a favor and learn the foundation it's built on first.
> element.nextSibling is very clear. It's the next sibling of the element. It's idiomatic javascript, and it follows a good naming convention, which is a skill that is language agnostic.
The only catch here is that it will give you the wrong answer, and that you should (almost) never use it since it includes whitespace nodes, which you practically never want. This is why nextElementSibling exists (get the next sibling that is an element).
As for the naming: this is an old old discussion we will never agree on, but I think that in the context of a DOM traversal library "next" is pretty clear.
> The author is also conflating their time learning as a pro for jQuery. Had they learned vanilla javascript first, their point about not knowing which nextSibling to use would be moot.
Your assumptions about my knowledge couldn't be more wrong. I spent years writing plain JavaScript. I even wrote a jQuery alternative back in the day as I didn't like various aspects of it (I think I was the only user), before giving in and "just using jQuery". I still don't like those same aspects, but it's not bad enough to use something else.
I have also, recently, tried very hard to use plain JS, and this post is the result.
> if you are a new developer do yourself a favor and learn the foundation it's built on first.
This is just a variant of the old "kids these days, they just learn Python instead of REAL development with C, they don't even know the difference between the stack and heap!!" Okay, shrug. In the meanwhile, those "kids" are solving real problems, so well... Programming isn't some kind of intellectual exercise, it's a tool to solve problems.
> The only catch here is that it will give you the wrong answer, and that you should (almost) never use it since it includes whitespace nodes
But that's perfect, because it does what it says. If I wanted to get the next element only I would used the correctly named nextElementSibling. How do you get the next text node sibling in jQuery?
> Your assumptions about my knowledge couldn't be more wrong.
My apologies. I was reading between the lines and I guess I got it wrong.
> This is just a variant of the old "kids these days...
Not at all, it's advice for the future of the web which will be more plain javascript based but within frameworks like React and Vue. They're grabbing more and more of the job market share. I am being pragmatic here, knowing jQuery won't help you navigate the world the "kids" are busy building right now with frontend SPA frameworks.
jQuery obviously has it's place, and if you prefer using it then no one can stop you. I just don't agree that it's better, and I don't believe it's as useful to know for new developers with the way the industry is changing.
element.querySelector('span') is the equivalent. Just as elegant, one fewer function call.
1) People like me care obviously. It's all bike-shedding anyway, so it's just a point of discussion.
2) nextSibling and nextElementSibling are two different properties, and you can't do the former in jQuery at all. In a typical usage you would need to do $('.my-class')[0].nextSibling, or in other words, dig down to the native DOM API anyway.
element.querySelector('span') would work from parent but not sibling as $(element).next('span') does.
You could certainly use that if you selected the parent, then did querySelector from parent (which for all I know is how $(el).next('span') works). So not equivalent, it's an extra step.
And that's kind of the point I think. Instead of writing this stuff (with much longer syntax) over and over again, jQuery might be better for casual web dev. Still. In 2019.
But whatever works for you. If you don't like it cool.
Yeah in JS that would be element.parentNode.querySelector('span').
I guess to me, that's not a bad thing. Verbosity is good, it's clear what's happening which leads to fewer unexpected outcomes.
What I have learned from this thread is that people don't really like the native versions of these kinds of things, whereas I think the above is much cleaner. It's not my place to say one is correct and one is false, and the popularity of jQuery speaks for itself. I am just one point of view.
It is not a equivalent to $(el).next('span') .
Your code means selecting the first span in the parent of current element, while the jQuery one means the first span after current element. It will produce different result when there are a span before current element.
Perhaps that's where the impasse is, because I see the platform APIs to have a reasonable experience now. I much prefer the browser implementations most of the time. Except drag and drop and Ajax. Those are terrible.
I also preferred PrototypeJS over jQuery, it's approach of extending objects made way more sense than a god object that wrapped itself around my existing objects. I have simply never liked jQuery's approach or API.
> Except drag and drop and Ajax. Those are terrible.
And except actual DOM manipulation which is tedious, error-prone, and requires tons of boilerplate.
> I also preferred PrototypeJS over jQuery, its approach of extending objects made way more sense than a god object that wrapped itself around my existing objects.
Prototype extended global objects which made them even more magic and would break vanilla JS. jQuery creates a wrapper object with well-defined methods and lets you access the actual unaltered underlying DOM object.
Vanilla Javascript has nothing to do with DOM APIs. DOM APIs is just another interface/library/abstraction that you need to learn after you've learned JS.
> If you learn jQuery today, you're not learning core JavaScript
You are right, but it's kind of beside the point given the context is web libraries. jQuery is built on top of the DOM API, so it's a library on top of an abstraction. It is just as simple to learn, so why not learn the core abstraction, with which all other DOM based abstractions are built from?
jQuery will eventually go away while the DOM API is part of the web's core stack. Maybe it changes over time, but there will likely be a DOM API as long as there are HTML based browsers.
I agree that learning the DOM API is an important core skill for web developers. But not that you should avoid using jQuery.
jQuery, or something like, it will be around "forever" because a core problem it solves is inherent to the DOM API.
("forever" actually means for the foreseeable future, projecting out where trends will take us in the future.)
The core problem is, there is no DOM API... there's a collection of DOM APIs which overlap (a lot) but that have various differences from browser to browser and from release to release. Just as importantly to software development, the wholly stable parts aren't really a single API either, but a group of APIs with a lot of duplication and variation in the patterns and idioms used.
For good software of any complexity, you're going to want to build as much of your code as possible in terms of a simple, concise, consistent, stable foundation and the DOM API is not those things. It doesn't have to be jQuery.
(BTW, I'm mainly talking about application-level code here. For utilities, plugins or other lighter-weight libraries, NOT requiring a separate library is a significant advantage. And your DOM access may be limited and well-defined so that a vanilla approach isn't burdensome.)
> You are right, but it's kind of beside the point given the context is web libraries.
I don't think it is.
> so it's a library on top of an abstraction. It is just as simple to learn, so why not learn the core abstraction, with which all other DOM based abstractions are built from?
DOM APIs are not as easy to learn. They are verbose, cumbersome, inconsistent in behaviour and capabilities. Even the staunchest evangelists of the "use the platform" movement run head over heels to anything that frees them from DOM APIs [1].
There's nothing wrong with learning jQuery (or any of the other libraries or frameworks) first, and then learn the core APIs to see how stuff works (and run away in horror). However, they are not a prerequisite for "vanilla js" or "core JavaScript".
> jQuery will eventually go away while the DOM API is part of the web's core stack.
That's the end goal of jQuery: to become the disappearing library. That is, to become irrelevant when the capabilities it offers appear in the browsers themselves. However, this will never happen as long as w3c goes out of its way not to offer any APIs with a sensible developer experience.
----
[1] You can see it in Web Components where "use the platform" is immediately abandoned the moment lit-html hits the scene or Template Instantiation is proposed.
> That's the end goal of jQuery: to become the disappearing library.
I guess my argument is simply that for the most part it's already happened, there is nothing particular scary about "jQuery style" general usage of the platform APIs.
Anything more complicated and I would prefer to enlist libraries other than jQuery. Drag and Drop, animation, AJAX, UI, all have libraries I would prefer. For anything less complicated I can just use what's currently in the platforms. For animation, CSS and class toggles are usually enough. Anything more complicated and there are better libraries for that.
> Even the staunchest evangelists of the "use the platform" movement run head over heels to anything that frees them from DOM API
Tongue in cheek but, that might make me the staunchest then, because I developed a workflow for using Web Components that uses only the spec, includes templating, data binding and is very simple. Shame it only works in firefox!
> There's nothing wrong with learning jQuery first
Practically speaking probably not, and you could make it through your entire career jumping from jQuery to React or Vue or whatever is next and never learn the platform APIs. I don't think there's anything wrong with that either. But if it's a hobby or your passion for web technology exists outside of work, I really do think you would be doing yourself a disservice not to thoroughly learn the platform.
> Drag and Drop, animation, AJAX, UI, all have libraries I would prefer. For anything less complicated I can just use what's currently in the platforms. For animation, CSS and class toggles are usually enough. Anything more complicated and there are better libraries for that.
And that's the thing: there are always libraries. There are very few use cases where you want to use DOM APIs directly. They all but sream "use a lib/wrapper/framework".
Exactly. I know I don't need jQuery, but sometimes it's nice to be able to do stuff like make an ajax request as a one liner vs 10+ lines.
Peoples gripes with jQuery come from people importing the entire library to do one thing, like add a class to an element. Sure, in that case it's dumb to load the entire library for that single purpose. But if you're using it for 5 things? 10 things? It quickly becomes worthwhile.
converts the date object to a unix timestamp* (int). a + works for coercing stuff to numbers. e.g. +"0.5" is quicker than paraseFloat("0.5") and also saves you from having to know if you need to use parseFloat or parseInt. coersion to strings can also be done by appending to an empty string: "" + 0.5.
Sure. But as always. It depends. If you're writing a highly interactive app and your jQuery script starts containing a lot of view state, eventually you'll go mad and probably duplicate a lot of logic on server and client too.
Seeing your app as a function of a data structure/state is then much simpler. Although it will require a bit more thought initially. App = f(s).
Again, it depends. If you're writing static sites and sprinkles will stay sprinkles, jQuery will probably be a solid choice.
As always, it comes down to: use an appropriate tool for the job.
Sadly, that‘s not a nice title for your blog post to go viral, so people make posts like "x is dead, long live y", and "why are you still using x?", or "the era of x is over", in which they present very narrow viewpoints, and try to solve every single problem in the world with the hot new fotm framework.
> If you need state management, build a very complex app, etc. ... don't.
I'm not so sure you do for many sites. Take something like Reddit for example; I don't think the new SPA redesign is any better than the old template-driven app. In fact, IMHO it's worse in every way. Part of that is just a matter of design and not technical, but part of it is just "SPA hell": CPU goes to 100% on load, takes ages to load stuff, etc.
On the other hand, I find something like FastMail's web UI to be quite pleasant. So it certainly is possible, but I do think it's a lot harder to get an SPA right than it is to get a classic template-driven app right. It's also a lot more complex, which results in all sorts of problems.
I don't think jQuery is the "perfect" way to develop stuff; the lack of structure means things can get messy (we've all seen that), but I'm not convinced that React is the best answer to that (just because A is imperfect doesn't mean B is the answer, a common fallacy in these types of discussions).
I'm not quite sure what the best way is, and perhaps it already exists and I'm unaware of it, but in the meanwhile I prefer to stick with the "KISS" solution. If I look at the websites I really like using then they're all classic "progressive enhancement" ones, and not SPAs (in fact, FastMail is the only exception that I can think of).
Either way, the post was mainly intended as "vanilla JS vs. jQuery", rather than "classic JS vs. modern SPA" (although they're obviously related discussions).
With the way Reddit tries to shove it's app down your throat while using their SPA the cynic in me wonders if it's not designed to be as painful as possible if you persist. The last time I tried, I got THREE separate UI components prompting me to use the app.
I am not a proponent of SPAs, in fact quite the opposite, but I think Reddit has done a disservice to the pro-SPA community because their engineering team is completely useless and their redesign is a train-wreck. Thus I think using Reddit as an example of what SPAs can or can't be is dishonest.
Anyone can throw out a better-because-of-experience answer, and in fact I’ll do so now: I also have 15 years of experience in front-end dev and I disagree with your premise. It completely depends on what you’re trying to build, and SPAs are too heavily used at the light-interactivity end of the scale. We’re failing our users with brittle solutions that make us feel cleverer as developers.
Well, literally not anyone can "throw" such argument, only those who actually has an experience :) How many years of these 15 you are building SPApps?
It's ok to disagree. I'm in a camp "API + SPA" after my experience. I know as fact that you can greatly increase UI performance this way and build multiple apps (desktop, mobile, web) using single API.
So argument "I just think so" is totally not an argument for me.
I guess the other thing that you’re leaving out is the number of users your site will receive. For smaller numbers in a simpler market you can get away with more technically complex solutions. My last four years have been spent working on data driven platforms with a minimum of a billion individual visits a year, and for those typically prerendering the common parts and pushing them to a caching layer is much more computationally efficient and leads to a faster client.
If you’re dealing with a lot of custom data for each user they that plays less well into the prerender solutions. But again, it comes down to how best to serve your users’ needs.
As with many things, the answer is it depends on what you do. I inherited an app that serves about 1m requests a day, and server-side rendering of the HTML is one of the reasons why we're going to decommission this app, as the performance of the server-side rendering here is atrociously bad/unacceptable. We reimplemented many of the same features in a SPA that does a lot more overall and the performance difference is night and day between the two.
Been here for just about all of this "web" thing. When I'm pleasantly surprised by how fast & light something is it's almost always server-side rendered or static. Only benefit of SPAs is that at least they're more likely to employ responsive layouts, but then they so often also manage to have bugs that break the page in certain layouts on certain browsers (overlays/modals are a biggie) that it's kinda a wash. And that's not an inherent benefit to SPAs, just one thing they usually get sort-of right that's less likely to be correct in oldster template/static sites.
I'm old enough to remember when AJAX was supposed to make the web feel faster. It has failed spectacularly at that goal, in fact, whatever potential it may have had. It gave us much better spying on users though, so... thanks?
This is pretty much it in a nutshell. About the only use case where I will look at a framework outside of jQuery is if I want complex state management, or be able to handle LOTS of updating hotspots on the screen.
I'm a proud user of jQuery from way back in the early days, and still haven't found anything to beat it for writing a quick AJAX call to a back end from a web page.
It depends what you do with jQuery. Maybe you use a nice , well tested and full featured plugin (calendar, grid view) then jQuery works. Or if you want to manipulate html (you grab an html from a page and you want to export it as epub but you want to remove some stuff before, cleanup some styles, jQuery is much better at DOM manipulation then pure JS)
IMO what you should never do is put your application state inside the DOM if you have a complex page/app.
Shopify is a great example. They have both, but in the right places. The websites themselves are not SPAs, because they don't need to be. A minicart is barely reason to pull in an SPA framework and architecture, so they didn't. But their live theme editor tooling makes full use of the power of an SPA.
As someone who does application security assessments for a living, the biggest problem with jQuery is the lingering, outdated, vulnerable versions that are pervasive (1.x and 2.x in particular) in so many applications. I don't care if you decide to use jQuery or not, just have a plan to maintain it and be able to update it without breaking everything, should the need arise.
If you allow unchecked data to be stored & retrieved there are some XSS vulns in older versions. Ideally this would be prevented in a sane environment.
> Pages like You might not need jQuery try to sell the idea that it’s easy to ditch jQuery[...]
I wasn't aware of http://youmightnotneedjquery.com/, but that's an inaccurate summary of what the website tries to do and really does it a disservice.
It very specifically says, in the first sentence on the site, that you should use jQuery for regular development - it's specifically talking about people developing libraries, and encouraging them to not force other people to load jQuery as an extra dependency, which is a very reasonable position. And I don't think it's trying to sell how easy plain JS is, as much as just giving translation code from common jQuery code to plain code, so that if you want to go that route, it'll be easier to do so!
Here, I'll just quote the first text on the page (emphasis mine):
"jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application.
If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency. Maybe you can include a few lines of utility code, and forgot the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with."
Fist let me say this thread has turned out to be possible the most important thread in regards to modern web development.
Single page Applications (SPA) and frame works that are used to develop such applications are over used which have led to a whole host of problems in the software engineering industry, I truly believe that if you are building software solutions 90% percent of the time you will be building them to solve business problems, so that should be of paramount importance not necessarily the latest shines concept and tools, especially unproven tools.
A very high percentage of the developers you will interview will be using front end frame work such as Reactjs, Anuglar, VueJs ... etc as a substitute for truly understanding the the native technologies and standards support by various user agents.
The consequences of this is usually very expensive for business while resulting in software products that are convoluted, complex and unstable; I have seen this too many times.
The JavaScript eco system at the moment is littered with these kind problems, pseudo stars developers who want to re invent the wheel (without first understanding the existing mechanics), not only is reinventing the wheel already an idea that has been frowned upon for thousands of years, in the context of software development most of the times it turns out to be a much buggier and less efficient solution.
I have encountered SPAs that have been built out to be so complicated and convoluted to say the least; in order to support server side rendering, hot module reloading, dynamic DOM refresh, Virtual DOM… etc. speaking as if these concepts are some holy gifts from the gods, and when you ask the most fundamental question what are the business values behind all of these concepts, there are no good answers.
I'm a bit sceptical about this article... I understand the point... jQuery is a nice place to get started for beginners and see how things have been done in the past and I also HATE the boilerplate with most modern JavaScript-Frameworks, but
> I want to build webpages that are fast
I don't think that jQuery is fast... Especially the fact, that jQuery hooks in every event handler to control the possibility to remove all Event handlers is something that is slowing down every app... event if jQuery is hardly used.
> use the simplest feasible code
I don't think that code is simple, when it is ONE single function that takes nearly every type as argument with different outcome...
And I don't like that developers could use this article as a justification... especially while modern frameworks like vue.js can also be used without setting up a webpack project...
But: If you read between the lines, there is something to learn ;)
If that is slowing down your app, something was done wrong.
This comment reads (and feel free to correct me for a wrong assumption) as written by someone that really hasn't used jQuery in a serious production capacity.
The thing that really got me to start thinking twice about jQuery, much more than the youmightnotneed... website, was this performance test for selectors —
You can build jQuery without the SizzleJS engine and then it'll just use document.querySelectorAll. You can, of course, also still use document.getElementById('foo'), so if you have a specific performance issue you can opt-out for that one function.
I've been doing front-end for years and still use jQuery for almost 90% of my projects. It's not because I'm resistant to change, I've done my share of SPA style projects.
Simply said, jQuery is still the best plug-n-play solution for most small projects.
The numbers are not against jQuery. There's no real gains to skipping it. At 27.77 KB (Minified and Zopflinated file size) it's not as if it's weighting down your pages. On the rare occasions I actually come across something done faster in raw JavaScript (often because jQuery has some heavier polyfills), I simply use the raw JavaScript in my jQuery project.
Javascript libraries ecosystem in post jquery era is also inefficient.
More duplicated efforts on making reusable uis because they (React/Vue/Svelte/Elm/Ember etc) don't mean to integrate well with each other. Mostly they live their own world. Nothing integrates well with server rendering approach because most of them are based on virtual dom or compiler, vm that takes over the whole ui containers.
When you change a frontend language/lib/framework, your design system also need to change. All of your branded ui components need to be reinvented although some people just wrap libs such as Sortablejs, Select2 with their favorite js thing.
I've experiment Phoenix LiveView with a bunch of mentioned js lib/framework/language (above), nothing really integrates well for production uses. Vanilla js is still best bet for working with server-side rendered html (Unpolyjs or Stimulusjs is nice, but it only serves small purposes)
I hope there would be more js that works with good old html that you are already rendering.
> Pages like "You might not need jQuery" try to sell the idea that it’s easy to ditch jQuery. ... good reasons to not use jQuery: if you’re writing code that you want to be re-used by others...
Literally the first thing youmightnotneedjquery.com says is:
> jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application.
> If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency.
When you are done designing your Webpage, disable JavaScript, disable CSS (if your browser supports that) and check that you are still able to grasp what you want to present your visitors.
If you then don't find the relevant information in the first second, congratulations, you just made a page which is useless to people with old Screen-readers.
I may be old fashioned in this regard, but i only see JS as a Add-on to the text you want to get out and only use it to add functionality which would be impossible with html and css alone. e.G. to give a hint when there are new articles to read, or when a article has changed.
Comment sections for example don't require JS at all, but you can use JS to make it needless to reload the page after you send that HTML Form.
What do you mean by 'webpage'? Because SPAs are really applications that are served over http(s) and executed by the browser.
>I may be old fashioned in this regard, but i only see JS as a Add-on
You are. People want to build applications served over the web instead of installed locally. In those cases JS is not an add-on. In fact, the DOM is an add-on as it is nothing more than a layout manager and UI component set.
Sounds like you just want webpages to be nothing more than a medium for publishing text content in which case CSS and HTML is all you need ... but that ship has sailed in early 2000s.
I'm one of the original creators of You Might Not Need jQuery. Most of the examples still date back to 2014, with modern JS they get much simpler and shorter (the fetch API and async/await help tremendously in the first example cited).
I’m pretty much in agreement with this, to a point. jQuery is a reliable and fast way to make a age do just about anything, except maintaining state.
The KISS principle is practically unheard of in web development lately - I see teams using more “hip” technologies like React or Angular for simple sites, but then the complexity of the app increases considerably for not that much in the way of gains. Sometimes simpler really is better
I think, as with anything else, it's important we understand the tools we are using. I started with jQuery and the problem was (like many others) I learned it before I actually learned javascript. I've since backtracked and dug into vanilla JS so I can have a better understanding of what my code does.
Since then, I haven't found a situation where I miss jQuery. However, I don't damn anyone who uses it (beyond jokey arguments with the wordpress dev on my team).
It seems like this opinion won't fit in well here, but at this point I find vanilla more than enough for anything where Vue or React will be overkill. However, I'm obviously biased as a front-end app dev and am open to seeing what other people have to say.
I'm not sure what to think about the server side vs. client side comments in the article since that fall outside my area of knowledge.
Doubtful - 30 kB minified & gzipped is a lot of code, and the fact that jQuery doesn't help with your code organization/keeping code DRY much is a huge negative.
Is there a plan (or is it possible) for jQuery to look at going with some kind of modular approach where you can just import the stuff that you / your plugins want?
I know there are libraries that claim to have 100% parity with jQuery's selector library. Are there any ones that are making this claim reliably?
I still use jquery too and it doesn't have to be a tangled mess of insanity nowadays.
Webpack + ES6 modules + jquery is a reasonable option IMO if you like the idea of server rendered templates with sprinkles of Javascript.
Plus, with the way things are heading with certain web frameworks (like Phoenix), you can do really interesting things like push the diffs of your server rendered templates over a websocket channel without having to write any user land Javascript yourself, and on the initial page load it just gets served without Javascript using the same templates. It's like the best of both worlds (super fast feeling apps, SEO just works and you don't have to duplicate templates and logic on both the client and server).
convenience is the primary reason I still sometimes use jQuery. Sure dropping one more dependency always seems rewarding, but jQuery is just a tool which when used properly saves a lot of time.
Something seldom considered while discussing the use of libraries and frameworks: green computing.
Mind that you're multiplying any overhead thousandfold or even millionfold when transferring the overhead to each client connecting to the service (including several instances of network infrastructure). So,"how much effort it can be to use vanilla JS", – it may be well worth the extra effort, once, on a single side of the communication chain.
It's certainly a matter of balance: if you need just a simple functionality or a single effect, loading (and compiling) the entirety of jQuery may not be the wisest. Similarly, I've seen d3.js loaded just to get a canvas element by 4 lines of code, where a single vanilla line would have done.
(Edit: Notably, my argument was about the effort involved.)
I would argue that the comfort of using jQuery comes at the cost of speed and obfuscation. I stopped using jQuery about 2 years ago and for the most part had no problems whatsoever even when I was forced to support IE9.
Also I found that searching http://youmightnotneedjquery.com/ helps a lot when deciding how to implement certain features.
Hardest part to get rid of jQuery was the $.ajax function. Happily now, we can all use the fetch API with some extra polyfills, but pretty much that's it.
`el.insertAdjacentElement`, really? Yeah if you carry jQuery thinking with you, you will probably want to translate the code literally and find substitute for everything. No... You can just use to recreate the part of the DOM that needs to be updated and replace it. It's faster to write and easier to read.
Anyway most of the arguments are not considering, vanilla JS + webpack / babel es6 + npm packages. In a world where side-effects are not well accepted anymore using jQuery is nightmare to maintain.
What's this fuzz about btw, I thought this argument was over?
I've seen a few apps that began as vanilla JS or jQuery updated to use react as the requirements grew and the "simple" JS started crumbling under its own weight. So I'm sympathetic to the idea of just starting with a framework from the get-go.
That's why I'm excited to see how Phoenix's LiveView turns out. It gives the "server side rendered, sprinkling of JS" approach more room to go in. It won't replace something like Google Maps, but there's a whole class of applications that would previously be on the border of the decision between react and server side that can be pushed into server side.
If it works for you and is easily maintained by whoever is looking after it, great.
In my experience, sooner or later you're gonna want modern functionality / user experience and you're in for a world of pain trying to hack it together with jQuery.
These days I'd only use jQuery for sites where I'm the sole developer and the project won't change much over time. Or for legacy projects where the cost of moving everything to an SPA wouldn't be worth it.
If you're not the only developer on a project and the project is liable to morph over time, jQuery will be a costly mistake.
Idk in regards of how better the code can be structured with React or Vue, but opening apps based in these frameworks makes similar effect to starting Monero miner locally.
It's a mature library that takes the pain out of cross browser compatibility (yes... you read that right, cross browser compatibility is still a thing in 2019) and the verboseness of using native JS (yes... you read THAT right, using native JS is verbose), so why wouldn't you want to use it?
Oh and on more thing... If you're not using jQuery but instead using native JS with polyfills... YOU ARE A MORON AND DOING IT WRONG and should just you jQuery.
I have had my share of grief with jquery, but I'm not quite sure it was jquerys fault or the tools built around it. Many a time I had to reimplement stuff like radio button exclusion when a pop-up would render an HTML string as is.
Did anyone have problems like that? What are the jquery limitations I should be aware of?
I am asking because I am mainly backend and infrastructure developer and feel like I have little experience with frontend tools
This is all fine and dandy; use what works for you. However, as many of us have learned when trying to aggressively optimize performance, execution time is generally much longer for jQuery than with vanilla JS. So if you're after high PageSpeed scores, for example, jQuery is the damn devil (or at least one of them).
I like the progressive enhancement approach using a small amount of JS, and I'm fine with jQuery. The thing is that I don't _use_ very much of jQuery. Rather than pull in all of jQuery you could just define your own `get` and `post` to abstract the XHR verbosity. No need to pull in a giant library to do that
jQuery is an idiomatic DSL but far from intuitive (does “after” imply a DOM modifying action or just a selector?). So I find it okay that browsers have a verbose API as it makes it clearer. Bare DOM API is nowhere close to jQuery in terms of practicality though.
This is pretty much the reason I still use jQuery too. Although JavaScript now offers much of the jQuery functionality as built-ins, the very concise syntax that jQuery offers is more convenient to use.
el.insertAdjacentElement('afterend', other) seems a way more intuitive than $(el).after(other). I don't code JavaScript yet the meaning of the first is intuitively obvious to me while I can only know what the second form does because you've told me.
You must be new here on HN, we usually like to discuss things instead of calling them names. Mind sharing your opinions instead of just saying it's shitty?
The article is filled with "unnecessary methods and such" , because you reffed to the article.
If you mean jQuery , then maybe the functions you don't use others use, give some examples , the most I use daily are attr,css, find, parent, wrap,unwrap,parents,each, filter,toArray, remove, append, after etc (my project gets a ton of possible broken html or html with garbage and I clean it up)
As of writing this comment the account in question is only 1 hour old. Maybe there should be some kind of time limit before account can comment. Anyway the account is obviously a throwaway created to troll this thread. Just ignore it.
Well you should elaborate more, you might get downvoted to oblivion yourself.
You should at the very least comment on what exactly you found "shitty" about the article, giving the benefit of the doubt and a means for the author to be better.
I find HN downvote system many times misused, but your comment is the perfect example of a one deserving of negative feedback
> Pages like You might not need jQuery try to sell the idea that it’s easy to ditch jQuery, but the very first example is a good reason to use jQuery: one line of trivial jQuery code gets replaced with 10 lines of vanilla JS code!
There's no such thing as one line of jQuery, it's 10K lines before you add your one line to do that one thing that 10 lines of vanilla JS code can do.
True. But it's 9 more lines that you have to write yourself. And some people prefer being productive rather than figuring out how to do it in plain JS for the sake of it.
Thanks for that part. Really. A heartfelt thank you. Every time I see another "hey, I only want to show you text, but for some reason I thought using one of the modern js frameworks for it is a good idea" pages I feel years older. Instead of showing me text using html they pack that text in js on the server (it usually exists in an html compatible form already), then they shove that JS down the connection, then my browser has to interpret the JS, so it can get the html, which it then has to interpret too. And then, finally, I see my text.
And because all of this is so slow we get techniques like "server-side rendering". The first time I read about server-side rendering I didn't understand what it was: so, you produce the html on the server. And send it to the client. Yes ..? What is the new part? Why is this something that people present as the next savior of the web?
This is some special kind of madness and I wonder when it will stop.