by UkiahSmith on 5/27/19, 11:38 AM with 231 comments
by sgift on 5/27/19, 12:19 PM
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.
by JaTochNietDan on 5/27/19, 11:59 AM
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.
You can find the fork on my Github account here: https://github.com/JaTochNietDan/youmightnotneedjquery
I'll make some changes later to show the satirical nature of it.
by pier25 on 5/27/19, 2:35 PM
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.
by beders on 5/27/19, 12:01 PM
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"])
is `true` and that's ok.
by ehnto on 5/27/19, 12:25 PM
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.
by zaro on 5/27/19, 12:02 PM
by drikerf on 5/27/19, 12:16 PM
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.
by JanSt on 5/27/19, 11:55 AM
If you need state management, build a very complex app, etc. ... don't.
by geekamongus on 5/27/19, 12:21 PM
/preaching
by edanm on 5/27/19, 12:43 PM
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."
by Aaron-goshine on 6/2/19, 6:55 AM
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.
by sandreas on 5/27/19, 12:02 PM
> 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 ;)
by cdubzzz on 5/27/19, 12:12 PM
by Raphmedia on 5/27/19, 2:45 PM
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.
by thrower123 on 5/27/19, 12:03 PM
I think the biggest win would be avoiding all the insane complexity of a modern npm/webpack JS development experience.
by Existenceblinks on 5/27/19, 5:54 PM
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.
by degobah on 5/27/19, 6:30 PM
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.
by Asmod4n on 5/27/19, 2:36 PM
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.
by settsu on 5/27/19, 12:25 PM
(That got me thinking of another potentially interesting analysis/discussion about the distribution of jQuery versions being used…)
by zackbloom on 5/27/19, 2:53 PM
by Chazprime on 5/27/19, 12:47 PM
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
by cptrp2101 on 5/27/19, 12:32 PM
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.
by fareesh on 5/27/19, 12:27 PM
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?
by nickjj on 5/27/19, 1:54 PM
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).
by dsenkus on 5/27/19, 11:58 AM
by masswerk on 5/27/19, 12:49 PM
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.
by DoctorPenguin on 5/27/19, 11:54 AM
by drinchev on 5/27/19, 7:54 PM
`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?
by losvedir on 5/27/19, 3:00 PM
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.
by jesusthatsgreat on 5/27/19, 6:30 PM
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.
by viach on 5/27/19, 1:24 PM
by thrownaway954 on 5/27/19, 3:09 PM
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.
by gchamonlive on 5/27/19, 12:02 PM
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
by pizza_r0b on 5/31/19, 5:06 PM
Actually those 10 lines are replaced by the entire JQuery library.
by droptablemain on 5/27/19, 12:19 PM
by jb3689 on 5/29/19, 1:20 PM
by RyanShook on 5/27/19, 2:56 PM
by javinpaul on 5/27/19, 1:34 PM
by sedatk on 5/27/19, 12:52 PM
by umanage on 5/27/19, 5:41 PM
by nkozyra on 5/27/19, 11:57 AM
I see no reason to yank it out unless you're already doing some front end refactoring
by forgot-my-pw on 5/27/19, 4:18 PM
by robm99x on 5/27/19, 12:06 PM
by qwerty456127 on 5/27/19, 4:32 PM
by tempodox on 6/3/19, 12:39 PM
by unfunco on 5/27/19, 2:18 PM
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.