Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.



You have a million lines of in-house Vue code or is that inclusive of dependencies?


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: