I joined a company with a Vue app just before the Vue 3 release. I don’t think anyone believes it was a soft launch. Then the tooling like nuxt did the same with a v3 release countdown timer which only then released it was in beta with no support in their ecosystem. You could pay 10k for a consultancy though. I only wanted webpack v5 to be able to use federated modules to give us more migration options. The whole experience reminds me of Angular.js to Angular so I was quick to jump ship and spend the migration effort for v3 in moving to react. We spoke to a contributor too that basically told us we should wait for v3 because currently it’s not really built for SPA. Vue 2 was a web application framework and I could see the benefits for php/python/ruby frameworks with losing JSX and being more understandable for fullstack engineers in smaller teams who might not know React. They have now made a direct competition with React though and badly implemented a lot of apis (simple things like grepability and codemods are lacking). They struggled with this release for a year and now they are still behind where React is focusing on server components, concurrent rendering and the tools we need for WASM to be implemented in the most performant ways now ie11 is officially leaving support this year. Some have said it here too that the whole ecosystem felt beta and now the largely community based ecosystem is either leading to vue3-* packages which just make an upgrade to Vue 3 a full on migration.
You are doing a full migration to React because of the update from Vue2 to Vue3? I read the Vue3 docs for the key differences and it looks a lot easier to migrate to Vue3 than React....
The question is what next? Our team had already started migration from vuex to solely using Apollo. Apollo then changed their own standards like depreciating local resolvers. Vue 3 release seemed to change regularly from will it or won't it support ie11 and various other additional packages. It is fairly easy to build React-in-Vue code to do a similar migration but the "experts" in Vue often just live in the short term without really committing too a level of support that an enterprise team needs with 20-30 developers. With React I'm sure any major changes will be a phased thing so I can continue to upgrade through the major releases for new features while updating code to new patterns. There is usually codemods to automate any changes because the coding patterns are highly developed to be testable and consistent to change. Similar support exists around the community of packages like Redux. Vue is stretched across multiple projects like state management, build tooling and DX while genuinely being behind the curve in best practices like testing and static code analysis. A Vue 2 to 3 migration is really a complete overhaul of every component to allow you to upgrade to v3. That is a huge liability of an inexperienced team who I expect to make similar mistakes with their community.
Dunno dude...your team changed from Vuex to Apollo and then from Vue to React...if I were to guess, next year you will be making other changes....is the constant variable here the framework/tech or your team!?
It is the way of these type of early projects and generally you have some organisational and technical debt either direction but receiving downstream features while supporting legacy code is the general way in React. It was going to be a Vue 2 to Vue 3 migration but moving to React should take us out of these higher frequency changes from Vue ecosystem. I don't see you rebutting or adding anything technically here. I wasn't responsible for the original stack and no we have a roadmap for the next year or two which is the same tooling give or take. Avoiding the high breaking change libs like apollo for URQL and using their cache for simple queries and Redux when we need more.
Yeh it is why I put Vue as a great web application framework for developers not specialised in frontend solutions. They've been fragmenting their community there by becoming an SPA framework to compete with React. Vite is a good tool but we have many others that are simple to use. This one is just has 1st class support for Vue because it comes from the core contributors. The general ecosystem for vue though is a third party package which integrates something like vue and apollo together. Which is not supported by the vendor and falls behind major releases or makes drastic changes to fit new major releases of the Vue framework. You will find a lot of vendors not supporting Vue directly and those unmaintained projects are leaving you behind in feature set or using new anti-patterns and creating tech debt.
vue3 is still much easier for newcomers to grasp comparing to react, biggest difference though is still js-in-html vs html-in-js.
vite is from vue3 originally, I consider it's one of the best 'by-product' from vue3, it's 10x simpler than webpack and 10x faster too, I use it for all javascript/typescript projects nowadays.
That isn't a thing from Vue3 though. It has come from esbuild and swc projects. Both are now looking to fully support typechecking in a lower level language rather than having JS tooling written solely in JS. You can use vite for React too but it does lack certain features for us. I could get reasonably the same gains using webpack with swc loader or esbuild loader too. It is really just a preference on type of projects. For small starter applications a tool like vite is cool. If you're looking for ways to distribute many common applications with shared vendor libraries and seamless transition between microfrontends then federated modules is a big feature of webpack.
Halving spent a fair bit of time with Vue2/3 and coming from a Python background. I think to some extent the Vue2 to 3 transition is quite a bit like the Python 2 to 3 transition. It’s a big change, some controversial decisions, and the ecosystem is taking quite a while to catch up. However just like Python 3, Vue 3 is a massive improvement, I love the new competition api. I think it’s a great success and they made the right decision to push through with it.
We know you meant "composition api" but while I agree there are some good improvements sprinkled in Vue 3, I deeply lament now that we have literally two core competing APIs -- the classic "options" api, and the newer "composition" api.
Now when starting a new project there has to be a debate. Some people will advocate for trying the new thing, and as many others will be more conservative.
Worse, within a project there is now opportunity for competing technical approaches allover everywhere.
To be fair, React has been pulling this type of thing version after version. It seems like we MIGHT be settling on functions and hooks now, but only time will tell.
The real kicker would be if they removed the options API, for small components, it's all you need and I find prototyping with it easier than the composition API. So I for one am hoping they don't drop support for it in Vue 4!
React does the same in fact, and its documentation for class-based and hooks-based are not up to date last time I checked. I would rather having two clearly separated but documented options in vue3(class-based vs functional-based), instead of React's "we're mostly likely just use hooks alone in the future but oops our documentation is pretty much still non-hooks yet".
I think the trouble is that due to changing how reactivity works in Vue3, really it’s a completely new framework that just looks quite like Vue2. I don't think they could have made the changes in a phased way, it’s a kind of all or nothing situation.
This time last year I helped with adding Vue3 support to the TipTap editor and went headfirst into Vue3s internals. It’s a completely different machine.
Vue3s changes to its reactivity system is like Python 3s change to make strings Unicode.
I can't say I disagree, vue3 felt like a react metoo-release, and now it looks like some features are temporary deadends requiring more tricks to manage.
In some ways, Vue is a victim of its own success. I enjoy working with Vue and will continue to support the framework as the transition to version 3 continues. Ultimately, tough choices need to made and I understand the pushback from long-time users that depend on older features. (I use the term "old" loosely, since time and legacy in the front-end JS is skewed.) Like Python 3, the essence of Vue remains in Vue 3 and the framework will move on.
I reject that it's specific to "our generation". The people who made the monumental balls of complexity that Java is known for certainly aren't part of "my generation" at least. And we have contemporaries who embrace simplicity in significant and impactful ways.
Java and Java ecosystem are an interesting case. Looking back over the last 15 or so years of Java most orgs went through massively over complicated setups like EJB containers to slightly better spring (GWT probably deserves a mention), to much better spring boot, and now to smaller, saner frameworks such as javeline or micronaut.
The language itself is leagues and bounds ahead of what it once was in java 7 and before. And of course, the all consuming drive to use every conceivable design pattern is not in style any longer.
Generation has nothing to do with it, but trends have everything to do with complexity and constant change.
The new hipster shit of overcomplexity is putting every code snippet into a micro service, or just skip microservice and deploy everything as AWS lambda functions. Hype-driven development is a tradition.
I did a lot of development with Java in those days and virtually every Java package that mattered was a library, not a framework, and if anything the reason everything was so complex was because it was so configurable and pluggable, making it easy to use that with this and a little of something else without having to decide on a "framework".
I mean, you don't have to use pretty much any of the listed "framework" components. They've just transitioned to official core support. You can just use the base Vue view library if you like, and plug in what bits you want from there. Maybe you don't want a router or vuex (hell, with provide/inject in Vue 3, you kinda don't even need it), so just... don't use them. And it remains very simple.
There's no hatred here, I really think you're projecting.
the simplicity of tools falls apart when you need to increase the number of your tools as your problems become complex. Because when the number of simple tools increases the defining feature is the complexity of interaction of your tools rather than how individually simple they are.
And that's why frameworks exist. Because people want their overall environment to be simple (by means of having a properly integrated system) rather than individually simple tools.
This is effectively just systems theory 101. The complexity of a system is the result of the interaction of its parts, not just the sum of its parts taken in isolation.
I think you can see this in practice with larger React projects. While React itself is more or less small and simple, all pieces you need for a large application together are no longer simple or small. Angular on the other hand is disliked by some for its "over complexity", but it just brings (and integrates!) all the tools you have to pick up and wire on you own with a small tool like React. That is not meant to be a rating, I just wanted to point out that sometimes the reasoning (and the hate) doesn't make sense.
Alpine actually uses the Vue reactivity model under the hood.
I like the idea of it but for what I work on the CSP non-compliance is a deal breaker (their CSP compatible build is not ready and you lose most of the alpine benefits).
Originally we started out with VanillaJS & hand-rolled MVC pattern however the productivity slowed as the App was getting larger, switching to petite-vue was a major productivity boost giving us a productive reactive UI, ability to componentize our App into modular components & resulted in the fastest UI we've seen in a client UI.
> What I liked about Vue was that it was a simple view library.
My go to for that would be lit-html. It's part of googles Lit thing, but lit-html is un-ashamedly just a view library. All it does is render dynamic html on the client side in 3.2kb.
Maybe this is also related to the tendency to consider abandonware software which is not continuously updated. Imho sometime a piece of software should be simply considered completed, especially in the case of libraries and frameworks.
For who is looking around for a simpler but effective alternative to Vue I'd recommend Svelte:
A couple years ago people were recommending Vue as an effective alternative to React's complexity.
Then Vue itself became complex.
Now people recommend Svelte as an effective alternative to Vue's complexity.
Will Svelte remain simple?
It's not hard to see this constant cycle of "simplicity -> people need more -> complexity -> let's jump ship" if you're a web developer with more than a few winters. Every time there's a new simple library around the corner that makes reality so much easier to deal with, but it's mostly just hype speak and this simplicity never lasts for long.
But bicycles don't stop existing because they become cars. In computing there is this bad habit of over-designing everything, so that in the end you don't have any simple things left.
You aren’t wrong, and frankly I am dismayed at the new API in Vue 3. It does feel like a downgrade in structure for a dubious gain.
But framework and complex are not synonymous. I like well designed frameworks that let me get shit done without getting in the way. Vue is pretty close to that. Django is very close to that. If I could have Vue 2.x supporter permanently I would be happy. It lacked native forms support but router and VueX made it nearly perfect.
In practice they absolutely are. The average project using a popular batteries-included framework uses a fraction of it's functionality. Composing smaller libraries will always result in less lines of code running in production. Usually by an order of magnitude.
You can still just use Vue as a runtime view library and leave it at that – no build step, state management, routing, etc. It's not a bad way to work if you have a smaller project; I've done so myself more than once.
React has more mind-share and there are libraries for every feature imaginable, basically. But there is (or at least has been, historically) a lot of churn and fragmentation that is not suitable for all projects.
Angular and Ember sit at the other end of the spectrum – maybe you have all features nicely integrated but it can be hard to adapt such a big tool into a small, legacy, or otherwise non-standard project.
I think Vue occupies a nice middle ground here. There is a limited number of official libraries that more or less evolve together and cover most of what you need. But it's still totally feasible to just use the core runtime and call it a day if you don't need routing, state management, etc.
Express + React.
JS and Mongo if it’s just a proof of concept, TS and Postgres if it has some small chance of becoming a real app one day.
Zustand is my favourite simple state management solution, and it’s not too hard to swap it for Redux Toolkit later on.
If I was building something where the Django Admin Panel could be a huge advantage I’d use DRF instead, but overall for most small projects I like it less than Express.
Front End bloat doesn’t really matter when you’re just trying to get a prototype done as fast as possible.
Hatred is a very strong word. There's a new simple view library made every week at this point. Look at the popular ones, look at their source code, and pick one that fits your needs. Just because it's not on the front page of hacker news doesn't mean it's not a great option for your use case.
> There seems to be a hatred towards simple tools in our generation that I can't fathom
I have people bothering me about when things will be done. Something not great that plays nicely is preferable to something great that requires configuration in these scenarios.
I upgraded our app from Vue 2 to 3 and I have no idea what this means in practice. I think they were talking more about how the Vue team curated their codebase, not the developer experience.
I recently inherited a Vue/Nuxt headless website. It is grossly over-architected and a nightmare to manage. Things that are simple in html, like an <a> tag, are implemented in complex and inconsistent ways across the site. This site doesn't have any real interactivity and headless GraphQL and Vue are a giant waste of time and hurt site performance. In this case it wasn't hatred of the complex but I think just chasing shiny things and maybe project complexity for the sake of bill padding.
Vue 3 perhaps is ready but not its ecosystem. Important libraries (like form management) port to v3 is still in alpha. It was one of the most painful development experiences because of that.
It's crazy how much of the ecosystem is behind, despite Vue 3 technically being available for a while now. Honestly think I'll be looking to migrate away from Vue instead of up to 3.x.
This was one of the things I was wondering about. Vuetify is one of the bigger libs for Vue2 so if I were to do some upgrades it would need to be ready.
I tried Vuetify with Vue 3 about a month ago in case it was "semi-ready" and lots of basic functionality was still missing.
As much as I love working in Vue, Vuetify is the entire reason I use Vue today: if there were a Vuetify for Svelte I'd be using that instead.
All the Svelte component libraries, and indeed all component libraries I've ever tried, pale in comparison to Vuetify. With perhaps the exception of Quasar.
Using Tailwind after Vuetify feels like going from writing C# to assembly.
Unfortunately, not even VueX, the official store management library of Vue, is compatible. There is a huge performance bug [1] that makes migrating larger Vue2 codebases impossible. Pretty disappointing, but noone seems to care.
Yeah the synced "official ecosystem" was one of Vue's advantages over React but the Vue3 transition has weakened that.
First vue-router and vuex were not ready when vue3 was released.
Now Evan You says in this very submission that Pinia is the new store library? I thought that it was destined to be vuex v5 or vuex v5's starting point, after the not-so-great v4. Very confusing. (I didn't even know about Pinia until last week actually, when looking about progress on vuex getters caching).
I'm not even sold on the Composition API. It makes sense when I read the doc but basically never when I'm in my actual projects.
Yeah, in my opinion they shouldn't have called Vue 3, Vue. If its such a breaking change that most your ecosystem isn't compatible then it should have become its own project and tried to gain adoption by being better rather than brand value.
This is great news, Vue 3 looks much better than its predecessor.
However, I had to migrate a Vue 2 + TS app to Vue 3 and their guide at the time was pretty underwhelming. Props to Evan for dedicating time to migrate a sample app and publish the migration as commits, but the app was quite basic and dependency-free so I had to figure out a lot of stuff on the go. The compatibility build actually slowed down my progress as it took me a lot to figure out that I didn't actually benefit much from it and could just drop it. Till this day I don't have a clear idea about what @vue/compat is for.
Hopefully, with them pushing Vue 3 as the new default, there will be more detailed how-tos available.
That's been my experience, as well. I got everything working because I'm very familiar with Vue, but I did end up removing a lot of TypeScript from my app just to make it all easier. Luckily, Vue makes it easy to mix and match JS and TS (for better or for worse).
I jumped on the React bandwagon because I didn't like the Typescript support in Vue 2, and did not see much improvements for V3. Vscode Vetur was slow and unable to do full typechecking in Vue files. Much of my code was based on Vue Class Components, which was not going to be compatible with the new API. Vuex did not seem to be going in the Typescript direction either. A bit sad if you consider Vue 3 is written in Typescript.
TS support has been improved dramatically with volar VSC extension and vue-tsc CLI tool.
When that was released (I’d need to check when but in 2021 or even late 2020) my React FOMO disappeared as I get full TS support in script and template tags.
Composition api + VueUse are wonderful together.
I’ve been lucky to start fresh with vue 3 mid 2020 (in beta?). But I and can understand frustration to migrate.
fwiw, I started using Vue 3 recently for a project and the new composition API + new script setup feature makes Vue 3 comparable to Svelte in a lot of ways in terms of lines of code. Script setup definitely reduces boilerplate and once I was able to wrap my head around it, I really liked that.
That said, I don't think their documentation at the moment conveys why script setup is so useful (at the time of writing this comment). For example a lot of their examples in their documentation used their old API.
In my opinion, script setup + composition API is really nice. I haven't used React in a few years, so I'm not sure how it compares, but using Vue 3 features decreases the number of lines of code you have to write and maintain (in comparison to Vue 2), and I'm generally always for that. I would go as far and say that they would officially come out and say that the old API is deprecated.
I guess my only quandary is whether to use Vue 3 or just bite the bullet and use Svelte instead. If Vue 2 => Vue 3 is a decrease in 60% of the code, Vue 2 => Svelte seems to be a decrease of 65% ish. Is that extra 5% worth it? I don't know.
If you are considering upgrading from Vue 2 with Vuex note that store getters caching is not working in Vuex for Vue 3, potentially hindering performance significantly.
The only relevant discussion you can find regarding a privacy policy is a twitter thread that ends with the developer saying "I really should discourage adoption because it's getting too big."
No dig on them, but, really... at some point we need to start doing a better job of owning this stuff.
Why does vue look more and more like react. What's even the point of having a different library then? I'll just use React if I need to write useX nonsense.
It started when React had that license fiasco some years ago, and Vue picked up a huge surge of new users as a result. They have, IMHO, been chasing that high ever since.
Having said that, I still like Vue for a markup-first kinda of framework. React is code-first, markup later.
I tend to favour using React for most development scenarios, however, as most are code-first - and also because there are a dozen React candidates for every Vue candidate in my experience.
Our company was React (after that fiasco died down with React changing the patent/sue clause).
About 2 years ago our new tech lead decided that we would use Vue instead. Ever since that decision I found myself walking more and more into backend development. I just felt like all the Vue code we wrote felt like I was writing 2011 AngularJS code. Not sure what people find so compelling about it.
A month ago our tech lead decided we're going back to React for everything using Next. Everyone loves it. Everything is type safe and every variable has full type hints. Props are type hinted. It's great.
I wonder what the reason was to move to Vue in the first place.
We had similar discussions in a company I worked for, but most of the senior devs decided that trying to align frameworks for the sake of everyone working in the same one didn't make sense. Given our size, there were more than enough teams working in React/Vue to keep people happy, but moving everything to one or the other felt like a colossal waste of time rewriting existing applications versus executing against our business goals.
This reads the same, you went from React -> Vue -> React in the span of 2 years? Sounds like a colossal waste of the company's resources.
1. Vue has automatic dependency detection
2. Vue’ composables can be used outside of vue component
3. Do not suffer from over rendering or stale closure
And that is just hooks. Vue also has first party router(vue router) and state management (pinia). Along with awesome devtools, which allow any vue library to hook into it.
React has typed templates with way less syntax (dsl) overhead with magic props nor a magic reactivity/plugin system.
Then there’s many well thought out and useful features like portals, suspense, (async state) transitions, error boundaries, server components that vue just does not offer.
I think there is a fair argument that React has implemented some useful concepts and Vue wanted take certain advantageous concepts and add them into the fold. It's a decision and with any decision like that there are certainly going to be pluses and minuses.
Having transitioned from Vue 2 to 3 the biggest thing I love about v3 is no need for `this.$set` anymore, as almost all properties are fully reactive now by default.
Even after working on some rather big projects we never used composition API once. It feels more like a hindrance than an asset and greatly disrupts the simplicity of Vue, which is the most beautiful thing about it. But thanks to Evan's/team insight they've made it 100% option to use and so it didn't get in the way much.
Overall the number of improvements in v3 are amazing and the new native elements like <teleport>, fragements, etc are god-send if you ever had to struggle with them in v2. I really wish they didn't remove the event handler ($on) though. That really made life very easy and using a separate lib for that is a bit of pain imo.
I get the impression that Vue 3 was a greater effort than expected. It was talked about for years before beta release (on Full Stack Radio, for example). March of 2020, I was at Vue Conf (days before Covid lockdowns began), and I heard a few people complaining that this wasn't the expected official Vue 3 release. Here we are almost two years after that and it's just becoming the default.
That said, I understand that there were monumental under-the-hood improvements, some of which spawned off Vite.
Even if you think you're making sure to not fall into the trap, it always happens. The first version solves a specific problem and has enormous success, there might be some cleanup (v2), but then the Big Rewrite is going to clean up all the little issues and add in some highly requested features which will be so much easier because of the new architecture, programming language, etc. You estimate about six months, tops.
Then three years goes by.
I find the phenomenon amazing because I've experienced it personally and it's maddening. All the hours spent talking about the second system trap and planning how to avoid it had absolutely zero effect on it actually happening. It was like a black hole void where you just kept making one step forward and two steps back.
It was great effort. It included reactivity internals updated to proxies, composition api, typescript support, EJS modules adoption etc. and all that including surrounding core libraries and docs.
I'm surprised, too. I'm happy they took their time as Vue 2 was/is still a great framework, but I probably would have chosen Vue 2 for some projects had I known it would take this long to get Vue 3 out the door.
Some day, eventually, after all the dust settles in the JS ecosystem, there will be a stable framework for managing UI state in a sane, sensible, predictable and well-understood manner - and someone at the WHATWG/W3C will finally write up a spec and the functionality will be baked-into Chrome, Edge, Firefox, etc.
And we'll be free from having to learn a new JS framework every 6 months. And maybe even npm hell too.
Until then, time to buy another Pluralsign training course...
If W3C would stop doing initiatives like Web USB and give us a way to style a select box (finally going to be a thing) we wouldn't even need web frameworks.
* Styled select boxes
* Good cross platform datepicker with ranges that looks good
* More form validation options / dynamic form validation
* A good drag api that does edge detection well in every browser
* Bring back frames (would allow good nested routing)
* A built in rich text editor
* A good modal API (or bring it back)
* A way to submit a form via AJAX with just a property (think Rails UJS) to just render html.
I agree radio and checkbox inputs are still huge warts in HTML forms, though there is a workaround: if you have a hidden input with the same name and "false" value then you'll get what you want. See here for an example: https://stackoverflow.com/questions/2697299/
"Web Component" is a great name, but Shadow DOM and Custom Element are terrible APIs. WHATWG should just quietly abandon them and then come up with "Web Components 2.0" based on a native reactivity system, native VDOM diffing, and (this already a thing) CSS layers for style isolation.
I've been thinking like forever that if we had a standard, pure-html equivalent to jQuery's `$('.foo').load('url...')`, we could have a lot of great sites without any JS at all (I'm not talking about the minority of legit cases where react/vue/angular shines).
Similar to a link targetting an iframe, but without an actually ugly iframe.
Yes, that's the same core idea. I mean, there are plenty of solutions in JS, and it's a one-liner with fetch anyway, but having a native way would have been cool.
I was thinking about something more like `<a href="..." target="#someDiv">`.
That could be some handy (albeit rudimentary) foundation to build maintainable sites on a static server without any JS or build pipeline.
I hear you, that's another thing that has plagued our industry. Most of the time a regular select box is fine, but sometimes you need to have images or something more in the options (colors, etc)
None, probably, but these days it's de rigeur to spend half a (web or mobile) project's budget making sure even the select boxes are "on brand" and "delightful" or whatever. Often at the expense of usability.
I'm not very up-to-date with JS frameworks, so please bear with me. I know that new libraries pop up here and there, but if I'm not wrong, React is by far the most popular, and React has been around for almost 10 years. Vue's not much younger, and now it's 3rd major version.
Is there such a big difference between JS front-end frameworks and the rest of the world?
The ecosystem largely settled out in 2014 when everybody was "javascript fatigue" complaining. The developments since have mostly been refinements on details of the development setup or state management. There's new stuff but I'm pretty sure anybody who wrote React at the time would be comfortable with the slight modifications in the patterns of how things fit together.
We're kind of into the next generation of frameworks (Solid, Svelte 3, Vue 3) and that's more about how much JS is getting delivered to the client. The current area of exploration is "partial hydration" where the goal is to write stuff using the component model but do server rendering and only send JS for the parts of the page that'll change client side. For quite a few classes of application this would substantially reduce the size of JS over the wire. All this is less of a benefit than the state control React brought so I expect slower/partial adoption.
More broadly, there's been a resurgence of the render everything on the server and send html diffs approach in the form of alpine and htmx. The other potential area for change on the horizon is web assembly getting host bindings support so it doesn't have to bridge through JS to affect the DOM and other browser APIs.
Thanks for a thorough explanation! I've heard about NextJS, NuxtJS etc. and I know they're built on top of React and Vue, but didn't really know what kind of value they provided, now that's clearer.
It's not that bad. I am lead on a large Angular 13 project and we love it, easy to work with, build, deploy. We have literally no issues at the moment. .Net 6 C# APIs on the back-end, Oracle database. It just works.
> Google Cloud console downloads like 20MB of resources.
That's literally the biggest (publicly known) Angular app in existence, and the fact that it's slow doesn't have anything to do with Angular. E.g. FWD:Everyone pages load in well under half a second:
This is just on first page you load. As you navigate it loads a LOT more more stuff. I opened the console and it loaded like 20MB, then I navigated to another section and it loaded 15MB more.
And the problem is not only the bytes loaded but how clunky and slow it is in general.
The Electron argument doesn't make any sense as it includes two runtimes ffs.
I feel the same way about Angular. There some minor bugs that have had open issues for 5+ years and may well never get fixed, but by and large the day-to-day experience of writing and maintaining code is pretty great.
I just don't get the concept of people being like, I'm going to start a project that's likely going to take the ten years to become successful, but I'm not willing to spend the twenty hours to read the documentation so that it will be successful.
Yea...Angular made a huge (and hardly documented) change to their internationalization library that forced us to migrate to a third-party one.
Basically, they now (as of Angular 12) force you to build a difference version of your app for each language you support, and either serve them up at different URLs or use cookies to serve up the right version to each user. The technical reasons make sense...your translations occur at build-time, rather than at run-time, but it's a pretty drastic change that occurred out of nowhere.
I think it’s a bit of an outdated stereotype from back in the day when this kind of frameworks started popping up left and right.
It was a major shift from jquery-based sites/apps which scared many people away from diving deeper into front end. Nowadays you can stick to one of the major three and you’ll be fine for the foreseeable future. This new Vue version is the most disruptive change we’ve had since a long time ago in the fe framework space and it’s still ok to get used to.
I think a lot of people got a bad taste from webpack, gulp, etc. projects ~5 years ago that immediately mired you in deep config complexity to do anything. Nowadays there's a lot more documentation and emphasis on zero config / convention / CLI tooling to remove a lot of that complexity. Things are a lot better nowadays, especially if you're doing something greenfield and can use the latest tooling like vite, esbuild, etc.
>... especially if you're doing something greenfield and can use the latest tooling like vite, esbuild, etc.
Well, kinda? I tried to set up typescript, storyboard and tailwind the other day, via create-react-app - and it's not really clear if I can/should use npm or yarn, and what, if any bundles like webpack or esbuild/craco I need... Nor did any of the documentation/tutorials "just work" - and as final punishment I think I had to download more than a gig of dependencies.
I get that there are many layers of tooling, but when I can't seem to get half the features of qt, nor a gui for 4gl development - it does seem like there's a lot of churn and pain for limited gain.
Appreciated, even if it's not a good match for our other tech for most of these projects. That aside, do I then get Storybook and an easy way to integrate with tailwinduikit?
Honestly if anything, web frameworks are way ahead of the rest of the world.
The real difficulty is that web UIs have to be very flexible and varied: you have different screen sizes, mobile vs desktop, and every website has a different UI vs native apps all looking similar. And yeah, there are over 100 different web frameworks most which have a particular use case, although you don't have to use the perfect tool for the job. Also, there are a few quirks left over from the old days of HTML/CSS/JavaScript.
But making a basic website nowadays on modern tools is very straightforward. Clone a vite starter project, write out your DOM in React or Vue or Svelte or Solid.js or whatever, and launch a live-server with a browser inspector to fine-tune the design. There are some especially bad JS frameworks (looking at you Meteor), but that's the case for most platforms.
Honestly if anything, web frameworks are way ahead of the rest of the world
Made me chuckle. Web frameworks are thin-to-medium layers of dealing with bs that web graphics are by nature and design. Their entire purpose orbits around that. Runtimes that do not suffer from these birth traumas don’t even need all that complexity. E.g. with apple core ui libraries you can in hours design a new flex/grid/stack/align/etc geometry container (which takes decades in the web), can animate things, make them cheap-scrollable, sizeable, constrainable out of box. Do you really think that web reflows and size dispatch up and down a hierarchy is a complex issue which only a “top-notch” web tech can solve?
Of course web traditionally was more game-like and does not have any guidelines and presentation standards beyond “reset”, allowing to focus on design better than the rest of the world (and due to widespread nature monopolized by a single platform), but calling frameworks which basically deal with its own shortcomings and ancient issues ahead of the world is pretty misleading.
What exactly is ahead of the world in there? My bet is on reactivity, components, caching and lazy redraws, which “weren’t a thing” before web, because, you know, jquery and comctl32.dll were bad.
making a basic website nowadays on modern tools is very straightforward … and launch a live-server with a browser inspector to fine-tune the design
Ah yes, something we had at VB/Delphi 3 times but not quite as RAD. I mean, maybe launch a live server, drop a query and see live data in design-mode, or enumerate columns and make some of them editable out of box? Or fill a form with master-detail link? You can’t. Web praises primitive/workaround things which nobody even had a name for before, so trivial and obvious and default it was.
Things were really a mess for a while, maybe 6-7 years ago. Nothing was compatible with anything else, even itself from last month. But nowadays things are pretty stable, if you stay away from the hotness of the month which will be forgotten next month.
Why are people so obsessed with finding one true way to do everything until the end of time. Things change, things become more diverse, and the world is richer for it. There already are sane, sensible, predictable and well-understood frameworks for it, it's called Vue, it's called React, etc. You don't need a committee to bless it before you can enjoy such a stable environment. This is a lot like the 19th century US Commissioner of Patents saying "Everything that can be invented has been invented." Society and technology won't sit still.
It's your choice to learn a new JS framework every 6 months. If you don't want to use the new thing, then don't. Just make something valuable and use what suits your needs. That's all that has ever mattered.
NPM hell is what got me to move from beloved TypeScript to Golang. Coming back to pet projects a few months later was true excruciating pain every single time.
Today, it's Go in the backend and Svelte in the frontend, or vanilla JS for very small and simple tools.
As someone who programs on backend, frontend, and Android apps, I can't agree more. Javascript frameworks and NPM hell is terrible. You rarely have the problems in Go/Kotlin/Java world that are considered normal in the NPM world.
I never understood this npm hell reference people are speaking off. Is this just the drama of updating an outdated inherited project? I've been working with node/npm since the early days and don't consider it worse than what you find in Java, Python or PHP.
I learnt that much later. Apparently the current version of webpack that you get by following the official react project setup is missing certain polyfills!
I have been _very_ bullish and excited on LiveView and its cousins from other platforms. Hotwire was the first time it's entered my personal dev world and I've been working on a hobby trivia app since Christmas and it has been an absolute _joy_.
It's obviously not a one to one replacement for an honest to god frontend application, especially one that can be recompiled into an offline capable native app, but where you can use it, it does a lot of lifting.
It's already invented. It's called HTML. You then use whatever language you want to generate it. We were doing it a long time ago with Java Server Faces. Now there's stuff like Liveview and Turbo (Rails community)
I use Vue 3 without the new composition api. It looks and feels more or less like the old Vue.
I actually think things are pretty great these days. Even amongst the different frameworks and tools, things are settling into a common set of ideas and concepts.
If you made the choice to build an app on React/Vue a year or two ago, that decision is still valid today and I think that speaks a lot for how far things have come.
This comment is just low-effort complaining that we see on every JS thread on this site. Vue 3 is an option you don't have to use, same as React, Svelte or just jQuery. The implied suggestion that nobody should ever publish new code is tiring.
Yes, that was half of my post - but the first half is my hope that eventually the functionality from React/Vue will be built-in to the DOM (or at least baked-in to the browser). We're already half-way there with WebComponents (though I'm not a fan of WebComponents as-is, but that's a tangent).
Also, I still believe that web-pages should be functional without JavaScript. For all of my traditional SSR / non-SPA projects I definitely put effort into ensuring my projects exhibit graceful degradation.
There's already a lot of things we can do without any scripting at all: animations and dynamic content, for example - and we can even use CSS trigger-tricks for basic interactivity (e.g. show/hide toggles) all without scripting. What I'd love to see next is something like WPF/XAML's declarative data-binding in HTML (but in a less broken way...) - and I'd like to be able to submit a <form> element directly as JSON, as well as AJAX-like <form> submissions that don't replace the current document, all without scripting - that's the dream (oh, and CSS positioning relative to an arbitrary named element, I could go on...).
> We're already half-way there with WebComponents (though I'm not a fan of WebComponents as-is, but that's a tangent).
I think this is actually not a tangent at all, but rather, it’s kinda the whole point! I doubt we’ll ever get to a point where there’s a single standard, because a single standard can’t satisfy everyone.
"And we'll be free from having to learn a new JS framework every 6 months"
You are already free from this. The only one putting that pressure on you, is you. Pick something and stick with it, and spend your time learning _how_ to build things, instead of _what_ to build it in.
Likewise, one day I will achieve transcendence and suffer the ills of the human realm no longer.
I'm totally on board with building better tools and solutions. And with pointing out the flaws of tools as we find them. However it is folly to thing this work will ever end.
It’s hilarious you say this as React is arguably introducing the biggest paradigm shift since hooks (which was also a huge change) with Suspense.
It’s fine to say React is a decade old but the way we write apps with React has drastically changed multiple times with the only real constant being JSX.
And let me be a bit proactive, yes, I know react is backwards compatible for the most part, but similar to PHP, just because the syntax is still supported doesn’t mean that’s the recommended way to write apps today.
React arguably started the churn of JS fatigue we all complain about now.
Eh, agree to disagree. I understand your point, but I think those points you mentioned are also changing.
Take lifecycle. It used to be very explicit. Then hooks turned it into this weird implicit thing where you have to know how use effect works and how to only trigger something once, but then the empty array thing is an anti pattern etc etc. Now with suspense, that lifecycle is changing again in a way. I’ve seen some tutorials where the teacher refactors out of use effect into throwing a promise. But then you can have use effects inside your thrown promise and dealing with module scope potentially.
It’s late and im a little out of it, but to me, this is all a lot of churn and creates long periods of uncertainty as developers try and decide which of these features they want to use and when.
At a certain point it can get really frustrating when it feels like you need to rewrite your app to stay up with “best practices” and attract new talent into your org. It would be one thing if the best practices were making things better functionally, but I find that argument hard to justify for anyone outside of Facebook scale. Angular and Vue stuck with a more traditional lifecycle ideology and there are plenty of apps building at scale on those frameworks. That stability in low level APIs gives a community time to grow and mature without leaving a bunch of people behind.
I honestly believe React would not be anywhere near the scale of what is today based on merit alone. They were lucky to see the demise of angular 1 and learn from that mistake and now Vue is sorta suffering the same way by moving too far away too quickly from 2 to 3.
> But then you can have use effects inside your thrown promise
That doesn’t sound right. The linter will certainly yell at you for doing that, and I’d be surprised if the program did not crash. The “rule of hooks” due to their implementation is that you can only call them from directly inside of a component function block, I.e. not from within an if block or a promise.
Developer choice is one of the things people cite as a reason not to use React already, since you have to pick a router, state management library, etc. What’s a couple more decisions about built-in features? =)
I will say that I feel the opposite way about hooks: I only became interested in using React after hooks were added, because classes in javascript always rubbed me the wrong way, and I want to get as close as possible to functional programming style from start to finish. We’re using it now, and reasoning about the app is much simpler than before. I can’t say how much is due to hooks specifically vs overall React app architecture, but the components are much more pleasing to my eyes!
Agreed. I really liked AngularJS in spite of all its shortcomings. To me, it felt a lot more traditional I guess, and coming from Python/Django, I really enjoyed that. React on that other hand, I can't seem to gel with it at all.
Angular, if I wanted to say AngularJS, I would have written as such.
However, if you see other posts from me, you would also notice that I am largely involved in projects that are quite strong in Java and .NET stacks with SSR.
Like many others, I wasn't a huge fan of the composition API. Felt like we were giving up many quality of life features in the name of a weird "must be like react" push.
On the other hand, once I started actually using it, I found myself liking <script setup> very much. I also like the "ref" thing because I have been pushing for this approach for a long time. Values are objects/proxies is a wasteful, yet powerful approach.
I am not going back to writing Vue 2 style components and encourage all of my co-workers 5o do the same. They are slowly but surely coming to accept it. No more lazy hacks for them
I've had the same experience. The TypeScript support, explicitly defined reactivity so you have fine-grained control yet still simple and understandable code using the same models of computed, ref, and watch etc which anyone can grasp in no time.
I know the churn in the Vue ecosystem is attracting a lot of resentment but I'm absolutely loving it. The Composition API is clean and effective and <script setup> takes it further to svelte-like succincity, Pinia builds on simple reactive state instead of the needless complexity of Vuex, Vite is fast, Volar finally brings type checking to templates and VueUse offers hooks for several little niceties that just make the experience more pleasant (https://vueuse.org/). The only thing I dislike is the macro based reactivity transform proposal which would auto add .value to special refs during the compile step, but that isn't even finalised yet and of course completely optional.
It's a great time to be a Vue dev and I hope they continue developing 3 because even if it's not the same library it was, what we have now is too good to lose and I love using it.
Worth noting that major frameworks have yet to update for Vue 3. Make sure you check all your dependencies before embarking on that course. I like Vue 3 so am finding this seemingly slow adoption to be a real pain.
Chose Vue3 on whim for a weekend project last week. I was well into the first couple pages until I realized that some of the documentation seemed to have a completely different approach.
Then I realized the difference between the Options API and Composition API. That an pairing it with Typescript made things really unecessarily hard for learning. All the TS documentation assumed you already mastered the old and new APIs.
Really glad they have the Options/Composition toggle in their new docs now. Looks like I chose exactly the wrong time to look into it.
I moved from using vuetify with nuxtjs to using the quasar framework because they successfully moved to vue 3 and I haven't looked back. Quasar is hugely underrated
+1 for Quasar. I find that it allows me to get things done fast without having to think about and build boring and tedious components. It's easy to restyle or modify it's component library and I'm finding it quite nice. I wish there was a robust vue to native app tool available.
I've got a real sour taste in my mouth over Vue. React is the industry standard, and it's what the overwhelming majority of libraries, frameworks, documentation, and tooling around front end web development is geared towards supporting. People use React because it's the right tool for the job, and they have no real strong opinions about it either way.
But people use Vue for ideological reasons. For some opinionated reason or another, they take issue with using a framework created by Facebook or they have some silly little nitpick about a particular detail of the API that they use to justify their zealotry. My company is now full of these "loud minority" ideologues that have successfully lobbied the entire engineering organization against React. The majority who preferred React were silenced, because they are not ideological about their technology choice and would rather just placate the people taking issue with it. And now we're rewriting perfectly functional software to be more "standardized" with the rest of the company in Vue. It's insanity.
There's certainly no industry standard for JS frameworks. It might be in your circle, but that's certainly not the case in the industry.
In my experience, I've found Vue to be a lot easier to learn and to teach to others. I can task a junior developer with a new feature in Vue, and generally speaking, the biggest changes are to simply break large components up into smaller ones. Meanwhile, I've inherited several React apps developed by shops that focus on React, and they all have weird race conditions due to 'hooks', and all sorts of code that breaks web standard.
I know a lot of people out there are very productive with React, but in my experience, the whole process is much more enjoyable when working with Vue. Neither Vue nor React are the only solutions out there, and it's important to not be too dogmatic about which tools people choose to work in.
Competition is good. At some point, someone in charge of React might do something stupid (like what happened to AngularJS) and you'll be happy there is a non bullshit alternative to keep the former dev team in check.
Yea, the way they handled the RFC comments about the default component style gave me a lot of confidence in sticking with Vue. Listening to the community before making sweeping changes to the framework is so valuable and rare.
React isn't a better choice than other frameworks by any stretch of the mind. It's "industry standard" because developers don't use the correct tools anymore, they just use these buzzwords to build their resume to jump from job to job every year and leave the previous job with a pile of shit. The web is slower because of React. Luckily I see the dominoes falling, people are over it.
Here's to the next generation of frameworks, Svelte, Vue, SolidJS, or just literally returning HTML with Liveview/Turbo.
I first tried to learn react in 2015. And I gave up after failing to control webpack. I googled other options and found vue.vue worked and made sense to me.
Last year, I participated in a hackathon and needed a GUI interface. So, I picked html, css and js. I took a look at current state of react (react is the most popular js framework). I didn’t like what I saw. There are many different ways to do same thing, the recommended way hooks, also happened to be most error prone, and hard to learn. Apparently, it also necessitates Eslint plug-in for catching common hooks error(validation of dependency array). To top it, vue/svelte do not have the entire class of issue at all.
I was somewhat familiar with vue 1, so picked vue. I needed a bit of refresh. With Vue docs, vue devtools, and some grit, I was able to get a working GUI and complete my project.
So, at least from my experience, some people use Vue for pragmatic reasons. Perhaps if you were to give others the benefit of doubt, you might find that they too are trying to be pragmatic
Anyone who has used both Vue 3 and React that wants to share their experiences? Which framework do you prefer overall (including dev experience and ecosystem support)?
Vue botched their upgrade path to Vue 3 and now it's stuck in a similar limbo to Python 2/3. They "released" Vue 3 long ago but basically none of the ecosystem including officially supported libs like the Vue-Router/Vuex was ready and now a long time later many are still using Vue 2 because the ecosystem still hasn't caught up. The docs for Vue 3 when it was "released" were not good at all.
I used to host a Vue meetup and was originally excited for Vue 3, but most of the people I talk to who use Vue in their projects are still stuck on Vue 2 and have no plans of upgrading due to most UI libraries still not being ready.
Even though there is a core team now, it seems Evan himself has been less focused on Vue and moreso on Vite and tooling in general lately. I don't complain much because I love Vite, and no longer use Vue but I do know some Vue devs who are losing confidence.
---
I use React daily and at the very least they have rarely if ever broken backwards compatibility without being very fair on the ecosystem in terms of the time needed to upgrade, and releasing experimental versions for people to test/play with. Both are similar when it comes to dev experience, both have dev-tooling and editor integration. Though TS support for Vue was always lacking behind React. "Vetur" which is the VSCode/Editor extension to get good support for .vue files worked well enough until your project grew beyond mid to large in size at which point it slowed to a crawl for every dev on my team. Didn't have this problem with React. I think there is a new extension for Vue nowadays though.
Some of this is obvious a side-effect of there being many more devs working with React daily both in a hobby and professional capacity than Vue though.
Thanks for your insights! I have used Vue on several projects before but I have noticed that the entire ecosystem is basically in a beta stage.
Things are changing all the time. For example, the default state management solution just switched from Vuex to Pinia but a Vue 3 compatible version of Vuex still exist. Will it be the new default in one year? No one knows.
It's the same thing if you want to use things like SSR and not implement them yourself. You can either use Nuxt and continue to use Vue 2, or you can use the non-production-ready Nuxt 3 beta, which supports Vue 3. Both aren't great options.
Because of these issues, the strong community in the React camp really makes me consider switching to React for new projects.
I would pick Vue 3 over React just for performance alone. With React you do not have much breathing room and without specific optimizations like memo specific components, being aware what rerenders what: don't even try to use context api in large app for often changing data. Vue is much more forgiving and new composition api is nice. Both frameworks ecosystem and developer experience are pretty similar at this point.
As other have mentioned, Vue3 is barely out, its still fairly new, and for the most part most people I know are also sticking to vue2. The pain of switching to vue3 might just warrant a rewrite in react.
For all of what facebook is worth, React has almost never broken backward compatibility, and the core idea has not changed much, while vue switched from 2 to 3 to adopt a more react like approach, go figure.
It's more sane. It does fine grained updates without having to manually optimize like in React - useCallback/useMemo/React.memo/splitting components. Think of a list view where you want to update a single item in a list.
People generally understand Vue better because you can just push to an array and it reacts to it properly without having to commit to the React immutable data religion.
Basically if you were to competently build a framework you would have Vue, if you were trying to impress your colleagues and bring up bullshit comp sci principals so you can write 50x more lines of code while spending 100 hours trying to optimize a list re render, you would have React.
After using React professionally since 2015 I've come to the conclusion:
Only very few people at companies actually understand React beyond the surface layer. Everyone else just kind of gets by because on the surface it seems simple. It's actually really really hard to build performant React apps, but most developers are naive because they have $4000 mac book pros and Chrome cpu throttling isn't cutting it anymore. It's really an infection that has spread through our industry.
In my experience, I've found Vue to be a lot easier to learn and to teach to others. I can task a junior developer with a new feature in Vue, and generally speaking, the biggest changes are to simply break large components up into smaller ones.
The single-file components are really nice. You still have separation of concerns, but everything is organized in once place.
The config-style components might be something some devs don't like (boilerplate code), but I find it a lot easier to quickly scan a new component and understand what's going on. Easy to identify the component's private data, computed values, child components, etc. In React or Angular (or Vue 3's new syntax), these different types of data could be anywhere in the file.
Being able to choose TS or JS in a component file has saved me a lot of time. I can set very strict tsconfig rules for files that benefit from typing, and simply use JS when I'm prototyping a feature or I require some library that doesn't have good TS support.
And finally, the developer experience is top-notch. Excellent browser dev-tools extension, ESLint rules help avoid common problems and confusing code (and a lot of them are auto-fixable), and I've never had an easier time with hot reloading than with Vue (HMR still doesn't work out of the box in Angular 13, and apparently it was a major focus of the last release).
I've used both extensively now. Out of the two I prefer React. I'd describe Vue as more bells and whistles, less safeguards. I think developers prefer Vue because it doesn't get in your way like React does (despite React having very good reasons for getting your way!)
Interesting. I've found that with Vue's ESLint rules, it has excellent safe-guards. Every React app I've inherited has been full of race conditions due to 'hooks'.
Vue has single file components with isolated CSS styles built in by default. I really don't like the CSS conventions in the React world. Seems everybody has settled on CSS modules, but I'd rather not have two files that represent a given component. You can of course inline styles and use alternative approaches, but none come close to ease of use and readability of Vue scoped styles, while preserving component level isolation. I know this because I've spent hours trying to replicate it in React. It's odd that mixing html components into JS via JSX (which I agree with) caught on, yet the same is often not done for CSS. Conceptually would like everything in one file, and with proper isolation (not affecting child components)
More subjectively, I feel React has a lower floor for writing poor quality/hard to reason about code.
Not a problem for personal projects, but at larger companies it's not as great. I'll have to spend some time thinking about and quantifying the specifics, but always seems to be that react projects end up being more difficult to decipher, all else equal. Not due to framework paradigms, just the collection of conventions and style that pushes you towards. One of the things is that in Vue there's a forced separation between markup and logic oriented code. This is best practice in react too, but easier to mix by mistake due to prevalence of JSX.
Also if/else statements in JSX being done via ternary reads very poorly in my opinion. I have seen third party components for this, but not sure why there's not a native implementation. Fragmenting your view code and assigning to variables/JS if else does not read well. Ordering of markup in Vue always matches ordering it will be evaluated in. Whereas in a react codebase there may be many variables or components declared within the same file and stitched together later, which requires the reader to reverse engineer what the evaluated code will look like.
React does have greater flexibility for mixing UI composition with scripting logic, which comes in handy for particularly complex use cases, but is often not needed. Of course you can use JSX with Vue as well, just not very conventional.
Finally, Vue is implementing all supporting major features from a first party perspective, whereas react projects tend to be more of a patchwork of open source components. E.g. static site generation, state management, cli, routing. I believe some packages like redux got formally adopted, but Vue is approaching from single implementation/first party first. Which leads to more consistency between projects in ecosystem.
It's more internally consistent by design. It means "you can't miss a update because you forget to do something or something" or "this thing only work correctly if you do something or something",
e.g. change the code in useMemo and forget to update the dependency, add a callback and forget useCallback results in re-render everytime. Those guarantees are opt-out instead of opt-in in vue by design.
You have to specifically call some api in vue to opt-out the guarantees if you really want to optimize it yourself. In other word, you are not going to get blazingly fast performance by default if you actually do nothing and use it like html, but you also won't get shit like performance if you use it like that. (Generally you get a decent performance that you won't want to open devtool to check "what the hell framework is this site use?", you are probably not even going to realize the site is using vue)
At this point in time we can all learn that Vue was broken by incompatible changes. The horror you see in the whole ecosystem was predictable, but Evan did not understand how destructive his strategy is.
It is really clear that the changes in Vue 3 where implemented in a way where it is simply too much of a hassle to migrate for too many people - most of the ecosystem still does not work with Vue 3.
A new version breaking old code can be bulldozered into the world only by real godzilla projects like Python - and even there it triggers years of discussion and upgrade-resistence and lots of dead projects.
As a programmer of a small JS library you can learn from the fail of Evan: breaking backward compatiility is breaking your ecosystem - the most important resource you have. Disrespecting this resource will kill you.
The Vue project nowadays can be seen as dead - many projects got that "Angular-Burn" and will never upgrade, but switch to something else.
People still hanging on are the slow crowd that get things too late - we have many of these, but there is no creativity in these people, nothing to expect, just copypasta followers.
Hopefully other projects finally learn from this sad example.
Even if you don't like the exact setup , you can customize it to your liking (and there are a number of forks that do exactly that), but it puts together quite a few things that you often want as an "out of the box" experience.
This plugs together some of the nicer features from Nuxt 3, and other toys by adding the necessary plugins to your vue 3 project, Nuxt 3 is more of a whole toolset / layer on top of vue 3, but having played a bit with it, its not really ready (which is essentially what they say also). I'm guessing once Nuxt 3 is stable and released, it is going to be well maintained as a cohesive set of features, where this is more of an opinionated configuration of plugins as a starting point.
If you're choosing between those two, then I find Vue still better at this than react, where you have to go full JS rendering. Vue 2 had inline-template support which allowed progressive enchantment of HTML. Vue 3 however dropped support for that (there are few workarounds).
All in all both frameworks aren't too great at sprinkling dynamic functionality on server-side rendered HTML.
If we consider Vue 3 and React - they are not great at progressive enhancement because they are not built for that purpose if you're not using corresponding server-side renderer. If your backend return simple HTML - there's no way to mount Vue3 or React on top of that HTML and be sure that it won't be fully replaced by JS-rendered HTML because it has small differences between them.
Vue-Petite is definitely interesting and I likely will use it in the future, but talking strictly about Vue 3 and React - they are more suitable to SPAs than to progressively enhance your HTML.
I feel like we’ve been trapped between Vue 2 and 3 for a little while. A lot of libraries and wrappers have not been updated for use with 3 and I’m not good enough with JS to try forking and updating them myself. And then there’s stuff we’d like to use (like Headless UI from the Tailwind folks) that’s only available for Vue 3.
I am currently on Vue 2, but would like to migrate to Vue 3 at some point.
I am curious if anyone has as used the TypeScript class syntax with the decorators. Last time I tried to migrate it, there were a bunch of things that failed. Presently it looks like one other dependency I need hasn't been migrated to Vue 3, either.
Unfortunately they pretty much dumped the class syntax early on in Vue 3's development, so you'll probably find it quite hard to transition to Vue 3 if you Vue 2 codebase is full on class components. I had a similar issue having adopted the class syntax and I think rewriting is probably the only way out.
In retrospect, I’m so happy I did not jump the class syntax bandwagon, that always felt a little suspicious.
The best option seems to be migrating components to the (still supported) options API, which is arguably going to be harder if you have class style syntax you need to get rid of first…
