391–400 of 404 posts
Earlier quoted context omitted.
So you couldn't get away with lazy and ignorant two word answer and it forced you to write quality one :) One would argue whether we'd have querySelector if jQuery wasn't as popular. We may have an inspiration chain here... but thanks for pointing out to prior art.
[flagged]
Earlier quoted context omitted.
One website that almost always gets mentioned when people talk about jQuery today is "You might not need jQuery" ( https://youmightnotneedjquery.com/ ). That site is the best ad for jQuery I've ever seen. For almost every task it describes, the jQuery code is shorter, cleaner, and more intuitive than the vanilla "modern" JS one. And that's after almost 20 years, and I don't know how many billions of dollars invested…
This is incredible and such a great ad for jQuery. It's almost as if the creator(s) built that site ironically. So many examples are way clearer and easier in jQuery, like this one: JQUERY: $(el).toggle(); IE8+: function toggle(el) { if (el.style.display == 'none') { el.style.display = ''; } else { el.style.display = 'none'; } } Gotta love that "modern" triple attribute repetition. From: https://youmightnotneedjquery…
No, the site's advice is simply more narrow and fine-grained than a blunt 'never use jquery'. From the front page:
> 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 forgo the requirement.
This seems eminently reasonable to me. For a website, adding a jquery dependency costs little and you get much nicer, more maintainable code.
But for a library, every transitive dependency introduces the possibility of future version conflicts for applications that depend on it. And at the same time, library code shouldn't need to change and grow nearly as much as application code.
So library authors should strongly consider forsaking mere convenience for the sake of reducing dependency baggage. This isn't even JS-specific advice, it applies to most ecosystems.
Earlier quoted context omitted.
Why do you have to wait? It's fairly normal to run some version of `npm run serve` with a filesystem watcher that will hot-reload changes as they occur so that you can see changes every time you hit :w (or CMD+S or whatever saves a file on your filesystem)
The context is about the initial setup and the parent comment recommended vercel git flow. Yes, you can run it locally, but that's back to the "getting started" issues: https://news.ycombinator.com/item?id=39286669
Earlier quoted context omitted.
A few years ago I dropped jQuery for plain vanilla js and I've never looked back. Native js has everything jQuery has, except for the pile of often poorly maintained half baked "plugins", that usually only do what they want to do and not much else. Yes, the vanilla selectors are more verbose, but any half decent code editor will make them just as fast to type. I don't mean to be penantic, but I don't really understan…
Look at your own link - the "modern" way of doing it is always about 2-3x as verbose as jQuery. Editors let you type that mess faster, but you'll still have to read through it, maintain it, scroll it into view in your editor, see less of it onscreen at a time, etc. I'll take a clean, succinct API over a noisy verbose cumbersome one any day. And what are we saving by eschewing it and going vanilla? One little 30kb-gzi…
Earlier quoted context omitted.
Why do you have to wait? It's fairly normal to run some version of `npm run serve` with a filesystem watcher that will hot-reload changes as they occur so that you can see changes every time you hit :w (or CMD+S or whatever saves a file on your filesystem)
The context is about the initial setup and the parent comment recommended vercel git flow. Yes, you can run it locally, but that's back to the "getting started" issues: https://news.ycombinator.com/item?id=39286669
That's equally true of PHP.
Moreover, it's equally true that distros aren't always shipping the latest PHP versions, and that there are similar flamewars surrounding phpenv/pvm as there are nvm/asdf. There are options, and people have opinions. The more ensconced one gets in an ecosystem, the more easy it is to know which tools offer which benefits relative to your needs. None of those decisions are easily made when new to an ecosystem -- Elixir is newish and has enough coalescence around most of the mainstream things, but as someone new to it, if I needed to choose between Cowboy and Bandit, I would have quite a bit of learning required upfront.
Earlier quoted context omitted.
Why worry when you can easily load both versions with jQuery.noConflict() !!! Or you can just load one on top of the other. It will be ok
Loading jQuery twice is a band aid solution. However the jQuery 4 announcement page linked to this jQuery migration plugin that I was unaware of. Perhaps it can help in some old projects. https://github.com/jquery/jquery-migrate
Earlier quoted context omitted.
Creating a brand new Vue app using Vite as your build system (official) takes less than 2 minutes and you can immediately start using Vue by following its documentation and creating a well-organized web application with its friendly patterns and solutions to the most common pro-UX problems you could encounter in a web app. Give it a shot, it's stupid-easy, and that's not downplaying anything either.
This is pretty funny because the front end team at my company decided last year to migrate from Vue to React because Vue is too complicated and it's hard to find people who know it vs React. Impossible for me to get a read on this stuff. Such a clusterfuck of an ecosystem.
Thankfully it's pretty easy to align a team with a little time and learning what everyone wants.
"No jQuery" is one of its main features
Earlier quoted context omitted.
Then it sounds like we disagree on what the thread is about. When I hear "I updated PHP and everything broke" I think "because libraries break between version upgrades." You seem to be arguing against a position that people aren't taking, which is that there's something inherently wrong with PHP as a language that makes it break when upgraded (which nobody has said). The same goes for Node, which doesn't break server…
How is this not a complain about the language? > Again, JS is bad too, but we have to completely rewrite sites due to some PHP framework upgrades because PHP let's people do really dumb ORM templating. I even quoted this part specifically in my reply: > because PHP let's people do really dumb ORM templating.
Earlier quoted context omitted.
that's simply not true. nodejs v12 is years old, its like using php5 and lots of platforms don't support 5 anymore.
Security support for node 12 ended in 2022. For php5, in 2018. Those are very different. Rhel 7 is still alive, supports node 8, maybe 12, but nothing higher officially.