You put it very diplomatically. In my world I’m a lot more no-nonsense about the anti-react movement: they can go spend their careers making dull static websites with progressive enhancement and I’ll work on the interesting stuff without them.
This is interesting. React / Vue 3 has totally destroyed the creativity involved in webdev for me after working on multiple larger projects.
Having just finished a pure JS + Petit Vue project the creativity and fun came back for me, while highlighting some important parts of the larger ecosystems.
I'm still anti the newer frameworks though - and i think most are like me because of the ridiculous complexity these days, the sweetspot for me was around Vue 2, Angular 1.
The newer frameworks just have too much "magic" going on, way too many files, dependencies, ever changing tooling, and no one seems to understand even small parts of it fully. It becomes about reading manuals and following conventions, instead of being creative and getting things done.
Sharing simple data from one div/component to another is a good example of too much complexity; from 1 minute sharing across your app/teams through window.sharedObj, to 40 intermediate steps, 100 files, 100 imports, stores, 10 dependencies, .value.value.data.data, and extremely long nonsensical errors when your data has stranded somewhere.
> The newer frameworks just have too much "magic" going on
Either that or they don't have nearly enough magic to separate the developer from all of the paradigms of the web, so they can apply their own idea with any clarity.
But yeah, they sit there, at just about the worst possible spot. One can improve them by going either way.
> I'm still anti the newer frameworks though - and i think most are like me because of the ridiculous complexity these days, the sweetspot for me was around Vue 2, Angular 1.
But it's the exact opposite? At least if we're talking Vue 3, literally everything about it is less complex than Vue 2 was, especially with Vite. You're telling me that Webpack is less complex than Vite? At my work our 1 Million+ LOC Vue app the Vite config is like 40 lines for Prod, Staging & local dev each, and every single line of the config is dead obvious without even needing to check the docs, especially when you compare it to the monstrosity that Webpack setups usually end up looking like. Plus there's the insane speed at which even gigantic projects get built, whereas Webpack can easily take 100x the time. Hell, even HMR would take around 15 seconds on an uber powerful machine before we made the switch to Vite, where it now takes ~500ms.
Sure, there's a small bit of adaptation to be made with refs and calling `.value` outside of templates, but once you grok it it's actually a lot more logical than the magical `this.` you'd see everywhere in Vue 2, since `this` can refer to a LOT of things at any given moment, and it's never 100% clear what it is.
> Sharing simple data from one div/component to another is a good example of too much complexity; from 1 minute sharing across your app/teams through window.sharedObj, to 40 intermediate steps, 100 files, 100 imports, stores, 10 dependencies, .value.value.data.data, and extremely long nonsensical errors when your data has stranded somewhere.
Again, this is the complete opposite to my experience with Vue 3. In Vue 2 you had to deal with Vuex and the weird getter/mutation/state stuff, whereas with Pinia you just set some state as an object, and you can directly manipulate that state wherever you want, even with excellent devtool support.
And I definitely wouldn't call sticking all your state into a random `window.` object less complex than using something like Pinia, if that's your idea of less complex then I'm happy to not be working on the same codebase as you. I'd rather you not be creative with state management like that, cause every time I've ever had to deal with some monstrosity of an untyped `window.GodObject` I've wanted to throw my laptop against the wall.
Not to mention that if you opt for TS (which is like a single line in the Vite config), it's WAY more productive than Vue 2 since you now have properly typed emits and props and can actually have an overview of what data is flowing where. Plus CompAPI in general is just objectively less boilerplate and less code than the old Options API. An identical component will have much less code in 3 vs 2, especially complex ones, and ESPECIALLY once you start talking about mixins.
Also, passing props hasn't changed between Vue 2 & 3. You still just pass it in the template via `:myProp="myProp"`, all the same caveats as before still apply, except now it has proper type hinting that your IDE can help out with without having to scan the file itself. If you wanna avoid prop drilling (passing data from a parent to a deeply nested grandchild component), then provide/inject (also typed) or just Pinia (which again, is dead simple in comparison to Vuex or heaven forbid some monstrosity of a `window` object) is there to help.
The Vue 3 docs are also the best I've ever had to work with, and if you read through it just a single time you'll have an extremely clear understanding of how the framework actually works. No guesswork needed, and they always outline drawbacks as well as how to work around those drawbacks.
Disperesed between TS, JS and test suite and Vue files yeah, around a million LOC. Comically massive legacy app with lots of things that need removal, I'd say 30% of the code isn't even used, but who has time for tech debt when there's shitty half-baked AI features to work on eh
You don’t have to support, use or even like React in order to like responsive clients that don’t roundtrip to a server for every little thing. Heck, it doesn’t have to be reactive programming at all for all I care, as long as the result is good. It just happens to be that currently reactive programming is generally the least bad system to program in. But even CSS transitions can do a lot of heavy lifting and degrades well.
I promise you that the majority of React apps are effectively “dull static websites” that happen to be rendered on the client and that you can do a ton of interesting stuff without it. Here’s a full-on Photoshop clone in the browser built without any libraries: https://www.photopea.com/
shrug And I won't be visiting. The only thing I care about is useful content well presented. I always disable JS for security reasons (that, and because pages load a hell of a lot faster and with far less memory). Yes, things break but it's a price I'm more than happy to pay.
The interesting stuff tends to be webapps, that people pay for and are often internal to a company.
If you just care about sites that are document based, of course you’d prefer the static content stuff! But he wouldn’t be working on a project you’d be visiting anyway, so who cares if you stop visiting?
Well the absolute insane amount of component/ux libs say something else. I also can't really differentiate between companies anymore everything is just shadcn with low effort chatgpt copy.
