71–80 of 246 posts
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?
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. /preaching
Is this a problem that's worse with jQuery than with other libraries such as vue.js, angular, react? (genuine question, not a comeback)
Earlier quoted context omitted.
SPA is by million times better than "classic template-driven" trash. I don't just "think" so, I have 7 years of experience with "classic templates" and 8 years with SPA.
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.
Earlier quoted context omitted.
Has it occured to you you might simply not understand the advantages of this approach? There's a lot of crazy things in the world. Talk to a child about the economy or country borders and you'll realize how some things are just not straightforward to explain the advantages of. Serverside rendering in JS is no different to SSR in classic frameworks. You generate HTML serverside. Except in this case, you do it using Ja…
> 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.
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.
> 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 thoug…
Has it occured to you you might simply not understand the advantages of this approach? There's a lot of crazy things in the world. Talk to a child about the economy or country borders and you'll realize how some things are just not straightforward to explain the advantages of. Serverside rendering in JS is no different to SSR in classic frameworks. You generate HTML serverside. Except in this case, you do it using Ja…
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 didn't know about http://youmightnotneedjquery.com/ , but to me it seems very convincing that I need jQuery :)
Small detail, what's with the plus in this code from that site: last = +new Date();
* in ms
Earlier quoted context omitted.
Struggle with vanilla JS is my inspiration for writing this, which was up voted 20 times: https://news.ycombinator.com/item?id=19946032
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 learni…
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 didn't know about http://youmightnotneedjquery.com/ , but to me it seems very convincing that I need jQuery :)
Small detail, what's with the plus in this code from that site: last = +new Date();
>> new Date()
Date 2019-05-27T12:52:41.932Z
>> +new Date()
1558961556913
>> +"4" // works on anything else :)
4Earlier quoted context omitted.
What? I think it's really good!! because it has a lot of good methods and such.
So now you're editing your comments so they say something completely different, eh? how nice...