> 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.
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.
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.
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'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.
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!
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.
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.
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
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.
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 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.
> 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 —
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).
[+] [-] sgift|6 years ago|reply
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.
[+] [-] candu|6 years ago|reply
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.
[+] [-] jabart|6 years ago|reply
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.
[+] [-] saltminer|6 years ago|reply
[+] [-] baddox|6 years ago|reply
[+] [-] Tade0|6 years ago|reply
There's light at the end of this tunnel in the form of compilers like Svelte or Stencil.js replacing frameworks.
The improvement here is that since there's no special runtime the bundles are very small, so there isn't a lot of JS to parse.
Also the code you have to write is much shorter comparing to frameworks.
[+] [-] Bahamut|6 years ago|reply
[+] [-] JustSomeNobody|6 years ago|reply
There’s no other explanation.
[+] [-] udfalkso|6 years ago|reply
[+] [-] azdacha|6 years ago|reply
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!
[+] [-] scrollaway|6 years ago|reply
[deleted]
[+] [-] kangoo1707|6 years ago|reply
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.
[+] [-] JaTochNietDan|6 years ago|reply
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.
[+] [-] bollockitis|6 years ago|reply
> 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.
[+] [-] austincheney|6 years ago|reply
[+] [-] lampe3|6 years ago|reply
I'm just curious :)
One of the first things I learned in web development was jquery but right now I never use it. Even if I create a vanilla html/css/js website.
[+] [-] saltminer|6 years ago|reply
[+] [-] paradoja|6 years ago|reply
> Error code: SSL_ERROR_BAD_CERT_DOMAIN
trying to access https://youmightneedjquery.com .
[+] [-] indocomsoft|6 years ago|reply
Array.prototype.filter.call(document.querySelectorAll(selector), filterFn);
What's more idiomatic is document.querySelectorAll(selector).filter(filterFn)
The same holds for forEach.
I suggest you look into how javascript prototype based OOP works
[+] [-] mgkimsal|6 years ago|reply
[+] [-] pier25|6 years ago|reply
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.
[+] [-] noir_lord|6 years ago|reply
Nothing like jQuery's track record but they don't have the history yet to call on.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] beders|6 years ago|reply
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.
[+] [-] ehnto|6 years ago|reply
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.
[+] [-] arp242|6 years ago|reply
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.
[+] [-] mythrwy|6 years ago|reply
`Why is this a function and not a property of the object?`
1)Who cares? 2)Possibly because it's more than just getNextSibling as example above shows.
So shorter syntax, more functionality, what's the fuss? 30kb?
[+] [-] dmitriid|6 years ago|reply
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
DOM APIs are not core Javascript.
[+] [-] zaro|6 years ago|reply
[+] [-] invalidusernam3|6 years ago|reply
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.
[+] [-] drikerf|6 years ago|reply
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.
[+] [-] JanSt|6 years ago|reply
If you need state management, build a very complex app, etc. ... don't.
[+] [-] geekamongus|6 years ago|reply
/preaching
[+] [-] madeofpalk|6 years ago|reply
[+] [-] Carpetsmoker|6 years ago|reply
[+] [-] folkhack|6 years ago|reply
[+] [-] edanm|6 years ago|reply
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."
[+] [-] Aaron-goshine|6 years ago|reply
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.
[+] [-] sandreas|6 years ago|reply
> 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 ;)
[+] [-] LocalPCGuy|6 years ago|reply
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.
[+] [-] cdubzzz|6 years ago|reply
https://jsperf.com/getelementbyid-vs-queryselector/25
[+] [-] Raphmedia|6 years ago|reply
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.
[+] [-] thrower123|6 years ago|reply
I think the biggest win would be avoiding all the insane complexity of a modern npm/webpack JS development experience.
[+] [-] Existenceblinks|6 years ago|reply
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.
[+] [-] degobah|6 years ago|reply
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.
[+] [-] Asmod4n|6 years ago|reply
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.
[+] [-] macspoofing|6 years ago|reply
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.
[+] [-] settsu|6 years ago|reply
(That got me thinking of another potentially interesting analysis/discussion about the distribution of jQuery versions being used…)
[+] [-] zackbloom|6 years ago|reply
[+] [-] degobah|6 years ago|reply
> 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.