7 ms·
Life was hard before these sugars. Just a couple of years ago I spent a few months with people stuck in the late 2000s, technologically speaking. Their JS was
by oblak 4y ago
Life was hard before these sugars.
Just a couple of years ago I spent a few months with people stuck in the late 2000s, technologically speaking. Their JS was your typical jQuery spaghetti from that time period. Did not have any fun explaining the new stuff, not to mention Promises, to people who were somehow convinced they knew better than me.
- wppick 4y ago> stuck in the late 2000s jQuery is still the dominant paradigm. It's used on like 80% of websites. Wordpress is also still very widely used
- WXLCKNO 4y agoRight, but not for new projects.
- have_faith 4y agoIsn’t jQuery mostly dominant in stats because it’s included in WordPress by default (definitely in 90% of Wordpress themes). It’s been a while since I checked so this could be out of date.
- MBCook 4y agoUntil very recently it was also a dependency of Bootstrap. That’s why it’s in my project (can’t upgrade yet).
- mst 4y agoWhen using classic Angular (some time ago) with Bootstrap I ended up rewriting the JS parts of any bit of Bootstrap we used as Angular components for ease of debugging (I know lots of people hated Angular but it was still easier to only debug one framework-ish thing at once). The existence today of e.g. react-bootstrap suggests that I'm not the only one to have had this idea.
- wikidani 4y ago>I know lots of people hated Angular Why would they hate on angular? Isn't just another framework
- tweetle_beetle 4y agoYes, it's in core. And was only upgraded from a very outdated version fairly recently ( in terms of its lifetime) - https://make.wordpress.org/core/2020/06/29/updating-jquery-version-shipped-with-wordpress/ https://make.wordpress.org/core/2020/06/29/updating-jquery-v...
- duxup 4y agoI bet bootstrap has something to do with it too.
- dgb23 4y agoMany of the bigger libraries like bootstrap but also individual, rich plugins and widgets have moved to a JS native implementation, which is slightly more verbose but clearer, well supported and has no bundle size / dependency overhead. If I want/need "something more than native" today then I first ask myself again whether I _really_ need it and then maybe I will look for focused/small libraries and polyfills.
- dimgl 4y agoYeah I had an argument on here about callbacks vs. Promises. I’m pretty convinced the ones making the pro callbacks arguments have never actually used JavaScript in a professional capacity, especially in large codebases. I thought the callbacks vs Promises using `async/await` debate was settled.
- ericlewis 4y agoI’ve never heard anyone argue for callbacks. But the async/await problem isn’t entirely dead since folks still argue generators should be doing they job. They’re similar flavors of cooperative multitasking I guess. But callbacks.. they’re really hard to test without abusing entirely different parts of js. Not that promises are much better.
- klabb3 4y agoYes, but async await isn't really complete without good support for streaming ops and APIs that support them first class. That includes merging streams, canceling them, etc (kinda like Rx). It probably needs both push and pull streams as well. We're not there yet, so in the meantime we have to use events and event listeners, in addition to async/await. I think that's perfectly fine.
- michaelsbradley 4y agoHave you tried Ix as a complement to Rx? https://github.com/ReactiveX/IxJS https://github.com/ReactiveX/IxJS
- klabb3 4y agoNo I have not, I prefer to go lightweight so good old event listeners are perfectly fine for my purposes. But once you have ubiquitous first class support for async iterables and so on I'm all aboard. I see Rx very much like an experiment that should influence language features and std libs, rather than a standalone framework.
- 4y ago