Hacker News new | past | comments | ask | show | jobs | submit login
Vue.js 3 (github.com/vuejs)
768 points by simulo 37 days ago | hide | past | favorite | 305 comments

Vue is the only one of the most popular 3 frameworks that can easily be used on a minimal basis to sort of "spruce up" old applications by selectively adding it here and there in the templates.

Seems like they should try more marketing and community outreach toward that end.

Gradual adoption is a feature / selling point not many web development frameworks can claim.

You can do the same thing with React though, you can arbitrarily render a React root anywhere, and an arbitrary number of times on the same page.

For instance, I work on an app that was originally written in Backbone / Marionette, but I was able to write generic connectors to allow us to drop in React at any point in the tree. Similarly, we can go back to Marionette / Backbone at any point in the tree. It's made gradually migration towards React possible.

Claiming React can't do the same sort of sprucing up as Vue is just a lack of imagination. Show me an old app, and I'll show you how to do it.

> you can arbitrarily render a React root anywhere

I think this exact capability is what led to such strong React adoption. It's almost viral within an application. The main application that I worked on a few years ago was on Backbone / Marionette and we evaluated React by writing several small but complicated nested components, with state controlled by existing mechanisms. After liking both the flux application architecture and the ease of gradual transition, we pulled the trigger on React. It slowly ate our application from the inside out, but never forced our hand.

React isn't "lightweight" (JSX being the primary hurdle), but it is very easy to adopt incrementally!

Why is Jsx a hurdle? Because you need a transpiler?

I find it the other way. Vue has a big learning curve. Learning their special directives and double binding gotchas takes a while.

While jsx is a very thin layer for existing Js. All control flow is good ol js. The tags just translate to createElement/h calls. React (class based React) was easy to pick up.

Yes, the transpiler (though everybody is already bundling these days). I really like JSX, though it's not everybody's cup of tea.

I also think other folks in this thread are referring to mounting on existing DOM in jQuery-esque use cases.

React is a quite bit more all-in than Vue though. For example, an old app I'm aware of has HTML generated by JSP with its own convoluted maven build process and uses a mix of AngularJS and jQuery to hydrate client-side functionality on top of it. The development workflow is a draconian exercise in acrobatics through remote desktops and VPNs in really old laptops (because "security" and unions).

Vue has similar hydration capabilities as Angular, but with React, you are pretty much forced to describe the view from scratch in JSX. To make things more fun, many islands need to be aware of each other, something that is not super idiomatic in React land.

Just some food for thought.

I don't know if "from scratch" is really a fair statement. React accepts HTML in the render function, so the only thing you'd need to do is modify the variables to match JSX's variable syntax, which is exactly what you'd have to do with Vue.

I think it's all pretty much the same deal. You might argue Vue's template syntax is closer to HTML than JSX is, but that doesn't really feel like the major issue when slowly refactoring a large application.

I'm not talking syntax. I'm saying that vue can be added on top of a third party DOM that may have server-rendered data embedded in it. You cannot hydrate React on top of dynamic HTML that was generated with JSP/PHP/.NET/etc unless you a) give up JSX (a big departure from idiomatic React) and b) interpolate server variables into your JS (a no-no in pretty much every non-SPA framework)

For example, take a rails app, then do the equivalent of $('#foo').toggle() based on some condition. In React, AFAIK you can't unless React knows what the markup being toggled is somehow. Vue can do it without knowing anything about the markup inside, and more importantly, the code will look idiomatic.

> and more importantly, the code will look idiomatic.

That's the kicker.

Whether a thing is possible or not is a far cry from whether it's a good idea. And when you consider what someone who opens up the code 5-7 years later without any frame of reference to start from will think (which can just as well include the original author if the original author has moved on to other things), familiar syntax goes a long way.

Yeah I don't know about all that. We sunset it now but about a year ago we enhanced an AngularJS (1.x) with Typescript and React. It was pretty easy using r2a [1]. It was pretty much an angularjs 1 app for the most part. Then we had like 5 React tags that we built more complex components that used our GraphQL layer natively. It was pretty easy too because all we had to do was typically pass one or two arguments to them, then the r2a'd tag did the rest - all react code from there. There's also a2r [2] for anyone that needs the opposite

1 https://github.com/coatue-oss/react2angular

2 https://github.com/coatue-oss/angular2react

>you are pretty much forced to describe the view from scratch in JSX.

That's just not true, I've just finished working on a client project creating a migration scaffold between react and angular-js - like someone mentioned above, there are libraries to support communication and embedding both ways.

This is also just plain false you aren’t shipping jsx and react doesn’t depend on anything but there being a stable host DOM node. It’s literally the other way around, vue uses global registration making it the only one of the three frameworks likely to give you any issue at all https://vuejs.org/v2/guide/components-registration.html

The JSX point boils down to this: you can't say with a straight face that using react without writing JSX is as idiomatic as pulling vue from a CDN, and you can't say that using JSX is as easy to setup on a legacy codebase.

React doesn't depend solely on there being a stable host DOM node. It also generally assumes data is programmatically structured. Try rendering FAQs as HTML with PHP then sprinkling answer toggling functionality with React and you'll see it's not straightforward at all; it would require refactoring backend code into a REST API or similar. With vue, add v-if and you are done.

Nobody's saying vue doesn't have faults; it has plenty of them. Let's not get all fanboyish when someone points out a legit con in react.

Not true. In fact, the first page of the react guide shows setting it up with jsx entirely in the browser. You also include babel via cdn and you‘re done.

You've moved the goalposts from "not possible" to "not as idiomatic"

Look, I gave a challenge to implement FAQ page answer toggling on top of legacy PHP HTML. Show me that it's possible to do it in react in a not god awful hacky way without refactoring the backend first, then explain how it's comparable to a vue one using v-ifs, then we can knock off ourselves out debating semantics.

How do you get the data into your Vue code?

You don't have to refactor much I think. You can inject the data into global scope in your PHP template, before you include React script. I'd do something like `window.__PAGE_DATA__ = "<?php echo json_encode($data) ?>";`.

Then, in your React code you'll be able to access it in a pretty idiomatic way for React. Instead of calling `fetch` or something similar, you'll have to call `JSON.parse(window.__PAGE_DATA__)`. You have to use `try`/`catch` block around it as well to handle errors from JSON parsing - just like you have to have the same block around `await` calls. You can treat the data as immutable to a degree as well - accidental local property updates will not get to the global scope, you'll have to set the property in `window` object.

I've used React in a few projects, embedding it into a Wordpress website using this approach. Seems to work well for me, but YMMV.

In vue, you don't even touch the data, you just sprinkle an attribute on the existing html to augment functionality much like you'd do unobtrusive js w/ jquery.

The approach you mentioned sort of works but a) it does require refactoring backend code (which by itself may already be a non-starter depending on whether you're dealing w/ a "old guard" backend tech lead, for example) b) it opens up potential security holes if implemented as you describe, c) you might lose SEO visibility and/or fail more catastrophically (i.e. a js exception might blank out the page entirely, vs merely breaking toggling), etc.

A more nitpicky code reviewer might also question the usage of babel off of a CDN if you went with a no-build JSX approach, the usage of window, etc.

By comparison, the vue snippet would be trivial, "production worthy" and it handles all the things above correctly.

> In vue, you don't even touch the data, you just sprinkle an attribute on the existing html to augment functionality much like you'd do unobtrusive js w/ jquery.

I don't have a lot of experience with Vue, but I don't follow. You include Vue.js from CDN in a `script` tag, and then just add the `v-for` and `v-if` annotations to your HTML? How does Vue get the data, to properly iterate over it in `v-for` or check in `v-if`?

I'm really curious because I feel I'm missing some piece of puzzle here.

I think the idea is that the backend already iterates over the data and spits out for example a ul with a li per faq item. You edit the template the backend uses so that the vue annotations are also produced, which in theory is easier than changing the backend code.


Previous HTML outputted by for loop in backend template:

      <h2>Question 1</h2>
      <p>Answer 1</p>
      <h2>Question 2</h2>
      <p>Answer 2</p>
New HTML outputted by for loop in backend template

        <button v-on:click="expanded = 1">
          Question 1
      <p v-if="expanded === 1">Answer 1</p>
        <button v-on:click="expanded = 2">
          Question 2
      <p v-if="expanded === 2">Answer 2</p>

You pass data into it as json. Or load it from external source as json

I think I know how to code a faq I use react to create a tool for humans to help autonomous vehicles with react. Jsx has nothing to do with how easy it is to embed react in a host app. If you want to compare build systems, VueJS is also less practical and robust without its optional build system. This was used as a reason angularJS v1 would kill react and it’s a tired argument IMO

You are shifting goalposts. Obviously every framework is "similar" enough if your baseline is "can I ship something with it". Heck, there are production apps out there written in choo and hyperapp and mithril. They all work just fine.

The argument here is that there is a substantial difference of effort required for a specific subset of project types (migrations from large non-SPA).

And for the record, all the vdom libs I mentioned are on the same boat as react, because it's an inherent trait of vdom based architectures.

I'm the author of one of them, and while I can't speak about others, I can say that I was ok with requiring simultaneous migrations from server rendered templates to REST APIs for scratching my itch, even though I was aware of DOM-first systems (angular 1, knockout, vue and intercooler are examples of those)

Contrary to popular belief, a framework is not required to be perfectly suitable for every scenario under the sun. And that's fine, nobody needs to get all defensive over it.

Yep, this is my favorite thing about Vue.

People will respond saying you "can do this with React, too". But in practice it's not nearly as nice to do as with Vue. You need React and React DOM AND JSX to really make it practical; writing React render functions is not really what you want to do when you are adding some simple functionality to an existing web app (like form validation).

> simple functionality to an existing web app (like form validation)

If all you are doing is adding a simple form validation to an existing web app, then you only need few lines of plain JS. You don't have to use vue either.

Agree with this sentiment. I was in web dev since pre-jQuery/Backbone, but left during the rise of the js-framework wars. I then returned to this area as I needed to add functionality/"spruce up" a web app within my organization and randomly chose Vue for the task. It went smoothly and didn't require re-writing anything.

Meanwhile the web development team are still fighting with the flagship "all-or-nothing" angular app, still stuck on 1.7 because anything else is an entire rewrite.

i'm afraid this is pretty much plain wrong. react and svelte also support incremental adoption, and i dont know angular but i'd hazard there's a way to do it too if you bothered to ask angular devs.

what you're responding to is marketing, which Vue has done an effective job of. thats fine, but it is unfair of you to conclude "Gradual adoption is a feature / selling point not many web development frameworks can claim."

I think the original commenter might have intended to mean without additional build tooling?

While it isn't pretty, you can drop Vue in a <script> tag on a page and define components with template strings.

In React, you can technically do this, but you need to either:

A. Use React.createElement() calls

B. Use something like "htm" also included via a <script> tag, with template literal tags to wrap your component renders

You can technically include Babel in a <script> tag to use JSX, but it only works with <script> blocks that have been tagged as "JSX", not within regular ".js" files you can import using "src="

Jason Miller a-la Preact is the person I see most consistently working on and pushing this sort of React/Preact no-build setup. I definitely get the appeal, for this exact usecase -- you have a simple, mostly-static website (or something old and built with jQuery) and you want to incrementally modernize it/add functionality without rewriting the whole thing.


I can tell you that not only he is right, but I've used Vue for exactly that purpose before and works like a charm.

You can go pretty far using Vue with a <script> tag before you start needing build tooling.

That's not where they were wrong.

Look, I've used both Vue and React for this purpose and Vue is just easier to integrate. React can do it too, but Vue places an emphasis on it and it shows.

Yes, but that's a different and less flame-baity claim than the top-level's "Vue is the only one".

as someone who has used both Vue and React in a _very_ legacy system, I can say unequivocally that Vue was massively easier to integrate into our system than React was.

Svelte. Popular.

> Vue is the only one of the most popular 3 frameworks that can

I don't know if you intended it this way, but the start of this comment makes it automatically flamebait.

Discussion around release announcements can quickly turn into a flame war. Please use caution.

The "easily" in that sentence is an important word...

And a flame war, aka lot of comments compared to votes on HN, result in less time on the front page. So there is not the biggest benefit to oversell.

What do you mean?

For one, it's not the only one. And instead of just talking earnestly about a cool feature of Vue in a Vue thread, to say nothing of other frameworks, you've now anchored the convo to framework comparison with your incorrect premise.

Why can't React do the same?

I'm not sure about React's capability with this, but Vue can very easily run with no build stage. You can load Vue from a CDN and use a couple lines of JS to point it at a DOM element in your app. Then you can write a plain JS Vue object (what goes inside the <script> tags in a .vue file), and all this logic will apply inside the element you pointed it at. You can also write components, although that gets a little clunky without a build stage.

This has allowed me to do things like create Vue-based tools in a locked-down corporate environment where I was not able to install Nodejs on my machine.

React can be run from a single file from a CDN, and used without a build stage. Only catch is you don't get JSX. While by today's standard some people might consider that unacceptable, it was a fairly common way to use it when it was new (because relatively fewer teams used builds for JS back then, and JSX was far from being widely accepted).

My first year of React development was without JSX even though we DID have a build step (I was categorically against it at the time. Things changed, haha).

React has been able to use jsx without build forever, here is a modern take: [1]

The babel script is huge but it might be an option to get the ball rolling on a big upgrade.

1. https://medium.com/@to_pe/how-to-add-react-to-a-simple-html-...

I mean, using Babel in the browser is essentially a build step. Your code isn't executed as is and has to be preprocessed. It's huge and slow. Not particularly viable. If your goal is just to play around, sure, but the point the Vue folks are making is that they can do the same in a way that is production friendly (maybe not scalable, but still production viable). This isn't.

I find it amusing that you are allowed to run arbitrary Javascript but can't run NodeJS on your machine. Sometimes corporate security can be a theatre.

Frontend JavaScript is sandboxed and you can't really disable it without crippling 90% of websites.

node.js code can cripple your system way more. So this does not really seem surprising.

I wish we couldn't run NodeJS, then the front end devs wouldn't run this monstrosity that takes ages to start, downloads GBs of dependencies, consumes 12 cores for minutes at a time, etc.

I exaggerate, but only slightly.

I find this attitude towards front-end developers unamuzing. If you have a beef with subset of developers in your workplace that happen to to work on the front-end, you should not take your frustration or generalize their behavior over an entire industry.

I don't know what it is about the Node.js ecosystem which leads to the dysfunction, but there's definitely dysfunction, and it's definitely endemic.

Compiling our front end assets takes longer and more CPU than our entire back end with many multiples the amount of source code.

I think it's that JS has no standard library, so dependency graphs are an endless fan-out instead of fanning back in after a while. That's how you end up with 900 dependencies after importing a single Node module, because every author of every upstream lib chose a different way of doing the same thing.

To add to this the Node ecosystem seems somehow to encourage outsourcing extremely simple pieces of functionality (leftpad anyone?) so you end up including a bunch of crap that you don't really need, all because someone didn't feel like using 10 lines to reimplement something simple.

Javascript has a standard library... intended for the language's actual use case, which is lightweight scripting and DOM manipulation within the browser. It's not a deficit of the language that some startup decided to pretend JS was the new C++ and that an insane and byzantine ecosystem developed around the attempt to force Javascript to be something it was never intended to be, and make it seem more "enterprise."

Endless dependency graphs and single-function modules and left-pads weren't a problem back in the days of JQuery and sane libraries. None of this madness is necessary. No, not even for front-end frameworks. It's unnecessary in the vast majority of cases.

I mean, you gotta trust someone at some point.

If they don't trust Google, Microsoft, and Apple to keep Javascript in the browser sandbox-jail then they're gonna be re-inventing an awful lot of wheels ;).

React can, but less ergonomically than most developers are used to.

Could you comment more on how it's done?

Modern React uses JSX which is then transformed at build time into function calls.

You can write those function calls yourself, but it would be a tremendous PITA.

In this case, you could use `htm`: https://github.com/developit/htm#usage

That's cool- but unless you're targeting greenfield browsers only you aren't going to use the syntax in that documentation without a build step or using the babel transpiler directly in the browser which, while cool from a POC standpoint, isn't a good solution. At that point you might as well just add build tools and use JSX or whatever the framework you're trying to use intended or otherwise is well documented.

Yeah totally. Or even use Preact by the same author which is smaller and faster than React.

I suppose it could, but there are annoyances with JSX defaults.

For instance, Vue provides a method to explicitly declare your template variable delimiter syntax. Last time I looked this was requested of React, but not implemented, someone correct me if I'm wrong on that and it has come along in the last year or two. So.. lets say you wanna put some modern Javascript in some Django templates to make them look spiffy. With Vue you can just declare your delimiter to be `[[` instead of `{{`, (because `{{` conflicts with Django's template variable syntax) with a one-liner setting.

I'm sure you could do this in React with a custom parser function (or maybe there's a third party library?) but it's a lot easier when the framework just gives such things to you out of the box.

If I do this all over the place and some other guy comes along years from now with no documentation on what he's getting into, he doesn't need to know too much to figure out what's going on and work on it. Right away he'll see "delimiter = [[" at the top of the script block in a template and can grep double brackets in the whole project to get an overview of what's being done.

React doesn't have templates, so that's a non-issue. JSX is sugar on JavaScript, but it's not a string. So template delimiters don't matter (that is, if you didn't use a build step, then it would be straight javascript functions calls)

That’s the whole point of the discussion: Vue makes it easier to have Django spit out <tr @click=doThing>My data here</tr> and then Vue notices and adds the event listeners. In React, it is very difficult if React has to start with foreign template output because it wants to own the (V)DOM.

For sure! I was just pointing out that discussing how easy Vue made it to change the delimiter ala Mustache isn't exactly a benefit vs React, since the whole concept doesn't reall exist there at all.

React and Vue can both be used directly with script tags, however the biggest difference is that React uses JSX while Vue uses HTML templates (but also supports JSX).

99% of the time, HTML is easier and faster to write, with the built-in directives providing all the functionality you need. More importantly though, HTML can be generated by every single server-side framework, and this makes it very easy to have server-side code from any language stack that becomes interactive using a Vue client-side layer.

That's exactly right and this is a much underrated capability and I think it's the point being missed by those saying "well if you do XXX you can include React with a script tag too!"

Please someone correct me if I'm wrong. It seems like you can only implement React using the full "modern JS stack", i.e. Node/Webpack/...

So if you want to use it on one page, it's a hard sell to set up all that infrastructure (and document it for the team)

On some sites I've used Vue.js by simply adding a <script> tag with vue.min.js.

On sites already using Gulp or similar, it's pretty simple to incorporate the Vue bundle and use it on one or a few pages.

React can be added to a page with just a script tag in the same way as Vue:


Having said that, React is normally used with JSX syntax, which requires a compile step.

You _can_ use it with "raw" `React.createElement()` calls, but that's generally unwieldy and almost no one does that.

However, there's a very neat library called https://github.com/developit/htm , which is an almost-JSX-compatible syntax that uses JS template literal strings, and requires no compile step.

React can also be used with just script tags. It uses a compiler to turn JSX into a render function (the same as Vue which accepts JSX or HTML) and these compilers are written in JS and can run in the browser. Also modern browsers are much better at supporting JS modules which makes it easier to include other libraries.

This looks like the perfect place to mention my project template used to create Vue 3 apps without the need for Webpack or any other build tool:


I already integrated vue-router, and am currently on the process of fully integrating Vue server renderer. I already have a basic usage implemented, where the home page is compiled to a html string, but I still need to make it easy to compile all pages and to implement client-side component hydration.

There is no need to run NodeJS in production with React. In fact, React doesn’t even require a fancy build system (though for anything more than a toy app you’re tempting fate.)

I wouldn't say this is the main selling point of Vue. For me Vue is superior exactly in the opposite scenario: when one has to build a complex SPA. State management, routing, and the like is all well integrated in the Vue ecosystem whereas, for example, in the React world it's a pita. I like React's simplicity, but I cannot deal with any of its complementary libraries for state management.

You may want to look at projects like preact-habitat, stimulus, and web components (a la polymer). Vue isn't the only game in town for this functionality.

You can do this with Angular. Just create a component, insert the compiled script tag, and then you can reference it in the html like: <my-component />

Stencil, Elm and React can also be be gradually adopted as they can produce individual component, which can be mounted to a part of webpage

Couldn't be more excited how Vue 3 would become the basis of the next amazing project

As far as I know, what you are talking about was the main reason React was created in the first place.

All this FUD spread by the Vue fans is getting ridiculous...

Not trying to hurt any feelings here, but as far as I can see as an unbiased person who's looked at far too many frameworks for their own good, the FUD is coming from the React fans.

I'm seeing a bunch of commenters getting defensive and saying "well technically" while conveniently ignoring the difference in effort required to do islands in each framework. You can't say dropping JSX is at all comparable to plopping in v-clicks on existing HTML.

You can certainly adopt react "incrementally", in the sense that you can implement an entire new self-contained feature and plop it into an existing app if it already uses REST APIs, but react is decidedly not as trivial to sprinkle into a non-SPA where data comes mixed with HTML rendered on the server.

Saying React can do it is a fact. So React devs are not spreading any FUD whatsoever.

Saying React can't do it, to paraphrase you, because "technically it's harder than with Vue" is like saying nobody can drive a stick shift because you have to shift gears manually.

Yes, you have to do it manually, no it doesn't make the car undrivable.

That's what I call FUD.

I gave some examples downthread where react pretty much falls apart. I'm sure you "technically" could make it work by dropping down to vanilla and cloning nodes or refactoring backend code or whatever, but at that point it's not merely "technically a bit harder", it's a pretty huge stretch.

The car gear analogy is again downplaying magnitude. The examples I gave are not a comparison between auto vs manual, it's more like auto vs getting a different license type to drive a 18 wheeler and having to learn how to turn, back out, park, go under bridges and where you're allowed to drive and not all over again. Yes, it's technically doable, no it's anywhere near similar amounts of effort as just learning stick.

To clarify, again, just because it feels like react vs vue is akin to manual vs auto when you're in a codebase that is amenable to being refactored into react, it doesn't change the fact that there are types of codebases (non-SPAs without HTTP API layers) where migrating to react is a significantly larger investment than vue. That was what the OP was saying.

The problem is that somebody gave a compliment to vue, and immediately a bunch of react people came with their "well actually"

React wasn't even mentioned, don't know why so defensive, who cares

I very much doubt the original comment mentioning "the most popular 3 frameworks" didn't have React in mind as one of those, even if they didn't spell it out, so that complaint IMHO makes little sense.

Actually it had both of them in mind.

People whose data validation is done via server-side logic probably don't need typescript either.

> the main reason React was created in the first place.

VueJS has first class support for this use-case while React has "well technically no ones stopping you from figuring it out by yourself" support.

I am impressed how they redesigned both internal architecture and a public API while keeping the users happy. Many well written projects fall into the trap of being a great fit for the contemporary practices but become less relevant over time as the ecosystem changes. Well done, Vue!

curious how easy it will be to move from vue 2 to vue 3

I am working on this right now on a medium-sized project, and it's deceptively more work than we anticipated. While Vue's component API itself is remaining mostly backwards compatible with Vue 2, most of the "core" supporting libraries have changed their APIs: Vuex, VueRouter and vue-test-utils in particular.

After the package update and some very basic find/replace across our codebase, about half of our 600+ tests had to be significantly updated. If your tests regularly mock a Vuex store or a router, be prepared to be making a lot of updates.

If you're using some of the features being removed (filters, $on/$off/$once, etc) or make heavy use of custom plugins, it's not going to be painless.

Having said that, I love the direction the new API is heading and 95% of the changes we have to make are for the better in the end, so it feels worth it.

to be fair though you are doing this in hard mode. to transition an app you should wait for 2.7 to get all the warnings and guides. so good job to everyone that you didn't find it herculean.

The migration guide [1] lists breaking changes. If you use many Vue 2 libraries you'll want to wait until they're updated to Vue 3. (I reminds me of the Python situation where if you used lots of Python 2 libraries you'd write your new code in Python 2 instead of Python 3, until those libraries migrated to Python 3)

[1]: https://v3.vuejs.org/guide/migration/introduction.html#break...

They're working on a "migration build" which is a version of v3 that has support for v2 behaviors + warnings, which should help smooth any transition.

On top of that, v2.7 slated for 2021Q1 also includes the relevant migration warnings, which should help make life easier

I just updated a 1 day app, it took a couple hours. No Vue.set/this.$set, significant changes to render functions, changes to much of the boilerplate. I was thinking that most of the deprecated behavior could be easily emmulated. The performace improvements are worth the pain, but I have a lot of code to update. Hopefully the migration build will solve it. It would be nice to avoid a python3 situation.

Even for a medium-size project it is not that hard. Most things are backwards-compatible and the transition can be gradual.

Our example (look at diffs): https://github.com/Quantum-Game/quantum-game-2/pull/227

Its very easy for users, quite difficult for library maintainers

This is a great tradeoff actually. It sucks to break backwards compatibility, but often that's the only way to move forward. If you have to break something, affecting the least number of developers is best.

This also gives a chance for a refresh of the ecosystem: libraries that are no longer relevant (eg, their functionality has been incorporated or otherwise made obsolete) can go away, and they get a nice "out" so no one has to feel bad about shuttering a project.

It also gives a chance for keeping the libraries using newer APIs, or even newer libraries to gain traction.

Very similar to doing a controlled burn in a forest: Worse than no fire at all, but orders of magnitude better than an actual wildfire.

I am impressed with the amount of energy Evan is pouring in this open source project.

I am curious if he ever experience boredom working on Vue.

I am also curious if Patreon based income is sustainable for the long run. What if there's another new sexy JS framework in the future?

> What if there's another new sexy JS framework in the future?

That's how a market works. It's a strong incentive to keep Vue sexy.

The market also isn't as volatile as people make it out to be. The top most used js frameworks (React, Angular and Vue) have been in the top spots for 5 to 7 years now. I guess the market might as well be settled. Of course there are some new comers every year, but they don't enjoy a large market share. Hell, I've not even seen VueJS used once in any serious project in the industry.

React and Angular are here to stay, and there's no changing that.

I agree that there will be a need for react/angular talent for many years to come. That said, I think engineering orgs are picking up on the fact that rolling web apps this way introduces lots of complexity and requires lots of resources to maintain and extend. I really don't want to think about regularly maintaining a 10-year-old redux-backed react app down the road.

Whether react/angular/vue are able to continue improving enough to justify staying within that world remains to be seen. It's very early days for some of the new frameworks out there, but with web assembly on the horizon, companies will again be motivated to modernize, however that looks.

GitLab uses Vue, that qualifies as a serious product.

Angular seems to be dying. Svelte is an interesting contender. I think it will be React's main competitor given a year or two.

This is a popular opinion particularly if all someone pays attention to is Twitter and Reddit but I'd argue it is a wrong opinion.

Angular is alive and well, and being used/adopted every day for projects no one hears about. It isn't the "sexy" choice, but it is the one a lot of companies make.

And if you're gonna point to opinion polls, and all kinds of respect to those who put them out, but they have a hard time capturing Angular usage due to selection bias.

Depends where you live and work I suppose. I used to work in a consultancy firm in Norway that was all in on Angular two-three years ago. Angular has been very popular in enterprise here. But Twitter and Reddit reach enterprise too in the end. The consultancy firm has now switched more or less entirely over to React because Angular is so out of vogue.

US consultant here with a similar story. A lot of what we're doing now seems to be moving toward headless CMS and headless ecommerce with NextJS/Gatsby for the integration point. I'm still a big fan of Angular, but the amount of work we're getting asking for Angular has dropped off a cliff.

I used to work for a big financial analytics company that used Angular 1.5 for everything. Around the time I left, they started migrating to VueJS instead. Obviously this is all anecdotal, and I have no doubt AngularJS is still being used in a lot of places, but I think there's reason to believe its share might be shrinking.

AngularJS is obviously shrinking. It's the 1.x version, and no one should be starting new projects with it. I don't think anyone is referring to AngularJS. When people say Angular, they'd be referring to v2.0+.

I was referring to all versions of the library. If companies are switching away from Angular, Angular's share will be shrinking.

Similar story in the old company I worked for. Though I have experienced that there are a few companies that are happy with Angular and see no reason to switch.

Angular is massive - MASSIVE - within large orgs you will have heard of but which I cannot name for obvious reasons.

The twitterati and hobbyist crowd seem to love react, but anecdotally I've yet to see it used seriously at a BigCo, but Ng+TS is everywhere.

Your comment seems to present anecdotal evidence as facts about $framework's popularity. I think that's misleading.

I'm wondering if there's a scraper out there crawling Alexa TOP 1xxx pages for use of specific libraries, frameworks? Maybe that would present a more accurate picture about this.

Also it's often misleading since in any company with more than a few employees there seems to be more than one team of developers which often leads to different frameworks being used in different parts of the company. In $dayJob we use Angular in some legacy internal stuff, React in a rewritten consumer-facing project and preact or jQuery in a different consumer-facing project.

It's not that simple to determine marketshare of frameworks I think. We can just present different numbers and draw different conclusions from it, e.g. number of job postings mentioning specific frameworks, number of downloads in a registry, number of domains using it (assuming one app per domain), number of stars on github or number of people claiming to use it in the stackoverflow survey.

A lot of the web isn't publicly accessible. And most .com marketing sites are built on a much different tech stack than the actual product. Example: landing page is Wordpress, actual site is a SPA (be it React/Angular/Vue etc).

Builtwith.com does what you describe although not sure if it can detect react/angular/etc.

Not everything is public facing though, particularly in enterprise

"I've yet to see [React] used seriously at a BigCo" you realize Facebook a) sponsors its development and b) just rewrote their core product in it?

Might be anecdotal, but the new site is pretty rough.

c) I've never worked at Facebook so I've not seen their work and obviously I don't use Facebook.

I can name Google.

Angular is huge inside big enterprises. Much more popular than React.

Svelte is very cool though.

>Angular seems to be dying

lol. In the US open jobs for Angular and React are about 50/50. (Indeed/SimplyHired), in much of the EU Angular is way more popular than React still.

Is Angular the new Rails in this regard? It's not going anywhere, massive businesses use it at a huge scale and it works.

WTF are you talking about... so you don't consider any of these to be serious? sentry.io, Gitlab, Grammarly, Codeship, Behance

Sentry is not using Vue.

React is winning in U.S.

Vue is winning in China

Angular appears to be "winning" in Germany (or all of Europe?).

Not true. I work for Europe‘s largest web dev company, react and angular projects have a 50:50 market share I‘d say.

> I've not even seen VueJS used once in any serious project in the industry.

I've been paid to write Vue code for at least 4 years.

I’ve deployed a number of applications using Ember’s (Octane) and will continue to use that over React, Angular, and Vue for as long as these other frameworks continue to prioritize fp zealotry over getting shut done.

What do you mean 'fp'? Ember was quite literally one of the worst experiences ever. Not having javascript expressions in handlebars is literally excrutiating. I'm so glad I never have to use ember, ever, ever again.

Functional programming. Maybe you should have given helper functions a look: https://guides.emberjs.com/release/components/helper-functio...

Download the league client if you want to be scared straight about ember. Resource usage gradually ramps up until by the 5th game the client is using more RAM than the game itself.

The closest thing I can see to a contender is Svelte.

I'd be unlikely to start any new project on Angular. React remains dominant and would be a viable option, except Vue feels more lightweight and approachable. I'm sticking with Vue for now.

Patreon income may not be, but Vue-based income should be.

This company focuses on development of Coldbox, a ColdFusion-based framework still in active development. If they can support a team and still continue development, Vue should be good for a while


If you have not checked out Coldbox, I highly recommend it.

The Ortus folks are very smart and clever.

Cannot recommend them enough.

> What if there's another new sexy JS framework in the future?

I am sure he can save a lot, with that income.

I am sure he could find a normal job, with those skills.

I am sure he could be a freelancer, with "created vue.js" as reference.

His Patreon based income would slowly die with the decline of Vue.js and he'd have enough time to look for something else.

> I am curious if he ever experience boredom working on Vue.

I was curious about this too when Vue 3 overshot its release estimate and then he started working on Vite, which is a build tool.

Vite looks pretty darn neat

From what I see, Vue.js has a very healthy commercial ecosystem. Many people seem to be making money off their community work. Be it with blogs, courses, conferences, offering plugins, UI, etc.

I think this decentralized web of incentives is more sustainable in the long run than a single corporate sponsor.

Market growth can cover a lot. Even if, say, Svelte gets bigger than Vue in the future, Vue could still be bigger than it is today.

> Vue 3 has demonstrated significant performance improvements over Vue 2 in terms of bundle size (up to 41% lighter with tree-shaking), initial render (up to 55% faster), updates (up to 133% faster), and memory usage (up to 120% less).

What does 120% less memory usage mean, really?

It's definitely not how to show that, but if you follow their link (https://docs.google.com/spreadsheets/d/1VJFx-kQ4KjJmnpDXIEai...), you'll see the numbers.

The math is like, if it did use 100mb, and now it uses 25mb, that's 300% less, because 25mb is the "100%", and you reduced by that amount 3 times. Odd.

Thank you for the link to the spreadsheet. Exact numbers they show are:

- "120% less memory usage" - From 9.9 Mb to 4.5 Mb

- "Up to 133% faster updates" - 13.18 (ms?) to 5.64

In both cases, the formula to calculate the percentage is:

Oh, actually they just changed it. For the memory usage, it's now:

..which shows a more intuitive result: -54.55%.

Is this the lingo that statisticians/mathematicians use?

I’d just say 75% drop for 100mb to 25mb.

No, it’s plain wrong. You could say «vue 2 uses 120% more memory than vue3», but vice versa is thus a different percentage (yes, 75%).

No, I think it's just weird :)

you would say "use 1/4th as much memory" if you were a normal person.

This kind of arithmetic is always very unclear and causes all kinds of confusion / miscommunication. This is why I always prefer to be explicit about the absolute numbers (maybe in addition to the relative percentages): "it used 100 mb and now it uses 25 mb (which is a 300% reduction when looking at the final result / which is a 75% reduction based on the initial result)".


25 to 100 would be a 300% increase.

100 to 25 would be a 75% reduction.

The only people I've seen use such nonsense were marketing departments. Do they think people can't do basic fractions any more?

Thanks for the link. Someone just started fixing the spreadsheet right now!

These "75%"/"300%" numbers are ridiculous, the two numbers are calculated completely differently. At least be consistent.

100/25-1 = +3 = 300% increase

25/100-1 = -0.92 = 92% decrease

i think your math is wrong, bud.

100/25-1 = 3 (300% increase)

25/100-1 = -0.75 (75% decrease).

Yes I made a dumb. oops.

I can only suppose it means 100% less memory consumption by Vue, and then Vue somehow frees 20% of memory from other running processes, which would lead to some pretty interesting results.

also being 130% faster it's rendering results before computations

That one is not so odd. If you drive 10 mph and accelerate to 23 mph, you're now 130% faster.

You can do the same if you measure rendering speed in fps.

I see the confusion.

100% more of something = 2x more

120% more of something = 2.2x more

120% less of something (problem here!) = 2.2x less = 1 / 2.2 of something = 45% of something

I think the writer meant 2.2x improvement in memory usage rather than 120% less memory usage -- the word "less" used in conjunction with a percentage is confusing.

I think this is how you evaluate X% less: amount * (1 - (x / 100))

So 120% less of 10 rocks is -2 rocks, which obviously doesn’t make sense. Which is good, it shouldn’t make sense to have more than 100% less of something.

The only way this makes sense to me is if memory usage was reduced by a factor of 1.2, but that sounds so much more modest than "120% less" that I'm doubting myself.

On a related note, I tend to avoid expressing changes as percentages entirely, in large part because increasing by X% and then decreasing by that same X% doesn't get you back to where you started.

In the latest JS benchmarks[1], Vue 3 RC4 is not doing so great in the startup metrics or memory usage.

Perf is on par with Preact.

RC4 is not the final release though, we'll see how it goes with 3.0.0

[1] https://krausest.github.io/js-framework-benchmark/current.ht...

Means writer isn't mathematically literate?

120% less mathematically literate than the last writer.

What's with the harsh attitude? It may have been a simple typo.

It means the writer isnt great at English.

There are other languages which would use similar constructs where it wouldn’t be wrong.

Do other languages math differently?

I'm seeing this more often, esp like 3x cheaper it hurts my head. For 120% less I'm thinking 100/220= it uses 45% of the memory it used to.

I guess it means 20% memory usage relative to the previous version?

It doesn't need memory anymore. Writes raw to spinning disk. 2% faster -50% of the time

It also goes ahead and downloads some extra RAM for you.

I was surprised to see an update to a contemporary JavaScript framework to be welcomed rather than boo’d by the average HN reader. That in itself is an accomplishment.

the appetite for a credible alternative to a Facebook project is strong. also the vue team has done a great job dripping out information over the past 2 years and building anticipation. very little surprises in this release, hence mostly celebration left. you need to go back a bit further in time to find the critical HN comments.

Live release announcement with Evan You going on right now:


I didn't expect him to say "Enjoy the Vue" ha.

Programmer and dad-level humor can be a pretty deadly combination.

The combination of the two is so dangerous you could say it's dadly.

He took the joke father than he really should have.

in case people wonder, still live as I type

ps: 5min later it's over

So it looks like Vue releases are all named after anime?

For anyone curious, here's the full list:


Is that a JoJo reference?

It's my understanding that anything can be a JoJo reference if you want it to be.

My only wish now is for the TSX experience to be rounded out.

From a reactivity standpoint, Vue has a much more ergonomic/easy to use API for handling component state, effects, and computed values (in my opinion) than React.

But in the last 6-8 months, I've leaned away from Single-File Components because when you want to do something like define a bunch of small components, it's a lot more difficult to do than with multiple TSX functions you can chuck in one file.

So I've been using Vue with TSX, and the experience (in the last few months only, before that was pretty bad) is okay, but not as solid as you'd get with React.

I'm not the only one who must feel this way, because this exists and has a lot of stars:

"Reactivue: Use Vue Composition API in React components"


Unfortunately, this is a weird stance to take in the Vue community, almost nobody uses JSX/TSX. Because of this, the development efforts towards it aren't as much a priority.

Overall, I'd rate the experience as "decent" and "totally usable", but I hope to see the DX for Vue's TSX community improve over the coming months.


Edit 2: Disregard the below, this already exists apparently

Edit 1: Having to write two type definitions for Component Props: one TS interface/type, and one as the JS object sucks. That's my one big complaint.

I know it's impossible because props need a runtime value but someone should make a plugin/babel transform to decorate the "props" key from the generic argument here:

   const MyComponent = defineComponent<MyComponentProps>
Use reflection on "MyComponentProps" to set "props" key.

There's another comment below discussing this drawback too.

> Having to write two type definitions for Component Props: one TS interface/type, and one as the JS object sucks.

Uh, you don't have to? TS inference works with the JS objects. There's no need to provide the generic argument here.

Also check out this: https://github.com/vuejs/rfcs/blob/sfc-improvements/active-r... (auto-generating runtime types from TS interface)

Holy shit, Evan You replied to my comment.

Happy Vue user since 2016.

> TS inference works with the JS objects. There's no need to provide the generic argument here.

That's totally valid -- I am just being nitpicky and complaining because if possible I'd prefer to do it the other way: TS type -> JS object

> auto-generating runtime types from TS interface

Whoa. Well, that solves that then.

I just looked at the sample code you provided. Having no experience with Vue (only React and Angular), but heavy TS user, something came to my eye:

Is it correct that `declare const props` will not only get used to type-check stuff but also emit code based on that?

I think thats unintuitive. TS basically means "take away all the static types and you get what the compiler emits". A lot of developers won't be able to distinguish between TS and the magic that some framework does. I've made similar observations when working with Angular devs.

Correct my if I've mistaken something. /2c

> Unfortunately, this is a weird stance to take in the Vue community, almost nobody uses JSX/TSX.

Typed components is 200% of why I'm writing React these days. Angular has typed components too (they went in on TypeScript early), but the Angular Language Service / IDE integration didn't come to later-- so for a period, no intellisense.

But having intellisense while writing TSX is so wonderful, especially when you're working with complex or deeply nested object structures.

Do you write Vue as well?

I have to hop back and forth between Vue and React frequently and the experience of writing a TSX component is pretty nearly identical.

For stateless components -- it's literally the same syntax as React.

For stateful components, you just need to wrap your component in "defineComponent()" and your TSX elements get returned from a closure in "setup()".

They have improved TSX support in Vue 3. Did you try it? What does or does not work? I'm planning on switching to TSX.

No it totally works, it's not bad. The one big broken thing in August was that the type for components (RenderContext) thought component props should be passed as "props={ myprop: 1 }" instead of "myprop={1}".



Comment I made about this I dug up:

"The issue seems to be that the definition for RenderContext<Props> puts the props under the key "props", so when trying to define them on your JSX/TSX element, it expects you to put them under <MyComponent props={ } />. If you do this though, it breaks in another way because it's missing the other properties of RenderContext and it's not a great API =/"

This is fixed now though I am pretty sure.

Anyone know if Vue 3 is isolated? Like can you use it to make 3rd party widgets and not worry about version conflict like you would with Vue 2?

One thing I'm really excited about with this version is Vite (the snowpack type version of Vue that doesn't require webpack). It should make development so much easier.

As someone who includes we pack in my build chain in order to use vue but doesn't truly understand it and has never used Cute, can you explain the advantages?

This is straight out of the horses mouth:

- Lightning-fast cold server start - Instant hot module replacement (HMR) - True on-demand compilation

This part should be of particular interest to you:


Thank you.

I was hoping for better Typescript support for typing properties, since that is where 90% of our type errors occur. But it seems like you still have to specify the types manually. The example from the manual:

  const Component = defineComponent({
    props: {
      name: String,
      success: { type: String },
      callback: {
        type: Function as PropType<() => void>
      message: {
        type: Object as PropType<ComplexMessage>,
        required: true,
        validator(message: ComplexMessage) {
          return !!message.title
Contrast this with React where this would be something like this (I think; I've never used React):

  interface Props {
    name: string;
    success: string;
    callback: () => void;
    message: ComplexMessage;

  export default class Component extends React.Component<Props> {
Quite disappointing. Maybe not that surprising given Evan said he only started using Typescript very recently, and many beginner Javascript developers don't realise that they should really be using Typescript (fortunately Evan isn't one of them). I would recommend still avoiding Vue for this reason alone.

It's not that we can't implement it like that, the real challenge is in minimizing breakage from v2. We decided it's better to not completely alter how props are declared because that would be too much breakage.

Instead, there's the compiler-based approach with `<script setup lang="ts">`: https://docs.google.com/presentation/d/1VjBM6ae-fuawK1TltYLX... (runtime props definitions auto-generated from TS interface)

But if the prop definitions are generated at runtime that means Typescript can't check them at compile time surely? Better than Vue 2 I guess but still not as good as React.

Fair enough on not wanting to break things, but I still feel like it is Vue's second biggest flaw and worth breaking to fix.

FYI Evan, that doc is currently private.

The google doc is restricted.

You can use vue-class-component and vue-property-decorator as described here:


You get to define your components as classes with their methods and properties, and can declare props and watchers via decorators. Overall a good typescript experience.

That is what I currently do. It's ok within a component, but there's no type checking when another component uses yours and gets the prop types wrong.

The announcement talk was nice to watch, however, it was technically void of any of the implementation details.

It's interesting to me that they did not consider the approach of pushing more work to the compiler and less to the runtime in the manner popularized by Svelte. I wonder what the trade-off between their current rendering approach and the Svelte-based approach are?

> they did not consider the approach

they certainly did, lol. the tradeoff is the same it's been; they want all of vue available in a script tag.

Guess I missed that. That makes sense, it's an interesting trade-off though. I suspect that including Vue via a script tag is not how the majority of users implement Vue; and therefore clinging to the virtual DOM may be a net-negative for most use cases. Personally, I am using Vue for a data-intensive app where performance really really matters. Although, I understand how broadening access to the framework increases availability and adoption; and for most use cases these performance considerations don't have any real world implications.

It is interesting though looking across benchmarks though and seeing non virtual DOM frameworks crushing their counterparts in terms of speed. I wonder if we'll see more growth in that space in the future.

Which benchmarks? In the js-framework-benchmark Svelte is slower than Inferno or Ivi and only slightly faster than Preact or Vue. https://krausest.github.io/js-framework-benchmark/2020/table...

You may be aware but it's also important to note that everyone is trying to cheat these benchmarks so they don't mean much. The implementations aren't data driven and don't look much like how we'd write real world code. See the discussions here including the linked issues and PRs https://github.com/krausest/js-framework-benchmark/issues/77...

I don't really understand the composition API. Doesn't passing values by reference which can be modified anywhere downward the tree make your app difficult to reason and debug it?

I have a fairly large/complex SaaS platform built with Vue 3 composition API. Can maybe shed some light.

A while ago I wrote the same component in Vue 2 and Vue 3 as an example of one versus the other:



If you meant more from a conceptual standpoint -- the usage patterns with Vue 3 is pretty nearly identical for most people. You just replace "data()" property with some "reactive()" state value in setup (or "ref()" for single values).

You CAN write things like generic hooks/"useXXX()" helpers, but you likely won't wind up with a ton of those.

Also, about the reference passing: it doesn't actually really work like that. If you pass a "ref()" or "reactive()" value as a prop to a child component, and you mutate it there, it doesn't propagate to the parent.

Vue will throw this warning:

    [Vue warn]: Avoid mutating a prop directly since the value will be overwritten whenever the parent component re-renders. Instead, use a data or computed property based on the prop's value. Prop being mutated: "someRef"

> I don't really understand [X]. Doesn't [Y] make your app difficult to reason and debug it?

It (passing mutable values around) does make it harder to understand the data-flow, yes.

But we programmers keep assuming our rules & protection & orderliness are helpful & necessary. And those patterns we opt in to keep getting codified, embraced. But along comes someone who breaks those rules, & it keeps turning out, a lot of the things we think we do to be orderly & safe & sensible are actually not that helpful at all, or have impeded really wonderful progress elsewhere.

I think of React. Until React came along, everyone doing web development knew, it was obviously correct, that we needed templating languages. We knew we needed content & code separate. We knew content was obviously a different beast than code & that content should have tools designed for content. As it turns out, mixing code & content actually works really well & that we had ruled out a wide space of possibilities that were really simple, powerful, & direct.

Relatedly, here, with shared-mutable-variables, I'd pitch that hopefully tools compensate for a lot. Hopefully it's possible to run the app & see who is modifying values, see who is being updated when values change. It's nice being able to have the code tell you, up front, easily, but also hopefully watching at runtime is possible, makes it easy to suss out what the connections & causalities are within a system.

I had a similar misunderstanding when I first saw it, but globally declaring reactive variables and passing them around isn't really what it's about. Take, for example: https://github.com/antfu/vueuse/blob/master/packages/core/us.... Any component that wants to use a reactive reference to mouse coordinates can `const { x, y } = useMouse()` in `setup`, but `x` and `y` will refer to different objects in each of those components (since the `ref()` is instantiated inside the call to `useMouse()`). The functionality is what's shared between components, not the state/references.

That said, if you want to use the composition api to share state you can, and you can pretty easily set up some structure to restrict mutability:

    // useStore.ts
    import { reactive, readonly } from 'vue'

    export const useStore = () => {
      const state = reactive({ count: 0 })
      const increment = (val = 1) => state.count += val

      return {
        state: readonly(state), // Readonly so state can't be mutated directly...
        increment, // ...only through the mutations provided, like Vuex

    // store.ts
    import { useStore } from './useStore'
    export const store = useStore() // Now components can share this instance

    // MyCounter.vue
    import { store } from './store'

    export default {
      setup: () => ({
        count: store.state.count,
        onClick: () => store.increment(5),
Or you can just keep using Vuex for sharing state and use the composition API for sharing self-contained bits of functionality. Or, if nothing else, using the `setup` method instead of the Options API just gives you much more control over how you organize your own code within a component.

Modifications in all JS frameworks are the same. Some interaction causes an event, that event is caught and changes some data, that data then triggers the render functions which show the new UI. This is often coded with event handlers linked to actions/mutations/reducers in some kind of state management library.

Vue (and some other frameworks) use a reactivity approach where the data is wrapped with a proxy that basically automates all this code. I find it much easier to reason about since it greatly reduces the complexity and you can focus on the actual data changes rather than all the plumbing to change the data.

No, because they all happen in the setup function, and when you export them at the bottom of setup you use them 100% identically as you would within mounted() etc,

I just started vue 3 and its incredible compared to my experience with react. Way to go Vue team!!!

> and its incredible compared to my experience with react

Could you expand on this a little more? What is it specifically that makes it incredible compared to React, in your opinion?

I like that vue manages dependencies so you dont worry about pure components anymore, but I believe that was fixed recently in react? The biggest thing is I despise writing JSX. To me it just feels absolutely miserable. The upside is that you have incredible fine grained control over the dynamic rendering of components, but so far even in my complex app there's been no need to write a render function yet (similar equivalent in vue to get that same level of control as react).

Also, I really like the data binding which vue took from angular. That was always by far my favorite part of angular, rather than having the binding be written in JS which feels too mechanic to me. I dont feel like I'm writing HTML / front end code, I feel like I'm writing a hybrid mecha mutant of JS + HTML + weird syntax.

For me and my team, it hits the right balance between Angular's structure and React's no-structure. We can use it for small apps within a server-rendered website, or larger SPAs.

I can hand a project to a junior dev and not have to explain project structure or patterns, nor worry about things going off the rails. Generally, after getting a feature working, most of the feedback I'll need to give is "break this 300 line file up into 3-4 smaller ones". Great ESLint rules provided by the Vue team really help with this.

With Vue 3, with the two APIs, I know that I'll be able to hand a feature off to a developer of any level and know they can accomplish it however it makes the most sense.

I can also jump into a legacy Vue app built by another team and have no issues getting oriented. In my experience with React, I haven't seen the same router configuration twice. Most React projects I've inherited feel over engineered

On a more meta level, I think the single-file API its a much better mental model than React's. Your HTML is still just HTML, and your styles are CSS or Sass, or whatever you choose.It's why I preferred AngularJS over the others at the time.

The short version: state in a react app is all over the place and not as easy to reason about as its advertising claims in addition to buggy libs all over the ecosystem, vue has actually achieved sanity by focusing on developer usefulness and how applications change over time.

Ha, I literally just built my first Vue 2.0 project yesterday. I'm already behind! :)

(just a Chrome extension) https://github.com/FastComments/fastcomments-debug/blob/mast...

I still don't see a reason why one would use Vue or React.

I agree that templating of data is something you should use a library for. But there are great templating libraries. Handlebars for example.

Can someone give a short example of code that would be more elegant using Vue then just a simple template engine?

Sure, you can use HBS (or even vanilla) to render a piece of dynamic HTML. That's not really the problem these libraries are solving.

You could also create your own components with HBS templates and figure out how compose them to render a tree of components. That's not too hard to figure out either.

The problem is really in updating the DOM when state changes somewhere in your application. In the jQuery days we had tons of micro DOM managing code so that when some variable changed then we would update some piece of the DOM by "hand". But as your project grows this becomes a mess pretty quickly.

Another solution could be to simply re-render everything and update all the DOM on every frame with a state change. That would simplify your code but it would probably be extremely inefficient.

The point of libraries like Vue, React, Svelte, etc, is about simplifying the production of sophisticated UIs, as efficiently as possible, so you can focus on the right abstraction instead of the implementation details (eg: managing the DOM).

Every library takes a very different approach. If you're coming from the vanilla/jQuery world the learning curve can be pretty steep. But, as someone who has been doing web frontend for 20 years, I think the price of admission is worth it.

IMO Vue is probably the easiest one to get into. You can get started by simply including it in a script tag as if you were using jQuery.

You say updating the DOM becomes messy but give no arguments why that would be the case.

Say a function changes the cars array. All it has to do to update the DOM is:


Where carsTemplate is a HandleBars template that on page load has been initialized with the html to render the list of cars.

Honestly, if manually replacing pieces of DOM works for you, then by all means, keep doing that. I have no horse in the race.

In my experience, the approach you're describing doesn't really scale and only works for the most simplistic use cases. In a real world scenario you would have dozens if not hundreds or thousands of arrays/vars that are related to the view.

Even only considering we're talking about rendering blocks of dynamic HTML: How are you going to keep track which state changes affect which parts of the DOM? Are you going to have hundreds/thousands of innerHTML code all over the place? What is going to happen when (not if) you change your template?

Then you need to start considering, event handlers, initialization code for every car view, etc. Imagine those event handlers modify the state of a single car in your array. Are you going to repaint and re-initialize the events of all your cars on every mouse event? Again, that would probably work on very simplistic use cases.

I'm not describing anything new. These problems are what motivated people to create Ember, Backbone, Angular 1 and other frameworks some 10 years ago. But the JS world has moved on from that paradigm into the reactivity+components thing which is a much better abstraction in terms of developer experience, performance, memory consumption, etc [1].

[1] https://medium.com/dailyjs/a-realworld-comparison-of-front-e...

I use this approach too but it fails whenever there's any state in the elements. An example is input elements:

  function update() {
    let value =   document.querySelector("input")?.valueAsNumber;
    document.querySelector("main").innerHTML = `
    Enter a price: <input type="number" oninput="update()"> 
    Discounted price is ${value * 0.8}
What will happen is each time you enter a character, it will create a new input element, which loses the focus and cursor position.

To solve this we can split it up so that the inputs are created once and the output is updated with innerHTML. No problem, right? But it's hard to scale up because now you have to split the html up into small segments based on whether there's internal state or not. If you want to update the 'max' of an input type=range, you aren't doing it with handlebars anymore but you have to use setAttribute instead.

What react, vue, etc. do for you is handle the updates in a way that reuses the existing elements. If you changed any attributes of the <input type=number>, it will not lose the focus and cursor and any other state. If you change the max of an <input type=range>, it will update the existing element (using setAttribute) without losing any other state. If you change some text, it will update the existing text node using innerText/textContent.

You may not need this type of system. I think React, Vue, etc. are overused. But in some projects it's much cleaner to use a React/Vue/etc. style system rather than splitting it up where some segments use setAttribute, some use innerHtml, etc.

Now let's say your data (cars) changes. Due to some interaction, a car gets added to the list.

What the above code will do is completely replace the HTML for the entire list of cars, when really all that needs to happen is appending one to the end. If the list is big, your app is now slow.

If the user has something focused or edited in that list of cars (let's say they're editing the description of one), not only is focus lost on that field now (its DOM node was completely wiped out and replaced), but the user's text they were editing is also lost.

That's an imperative approach, rather than a declarative one. You can't track where the state is being changed if #cars is being changed in many places. Templates are fine for smaller apps but in larger apps it's more difficult, and there'll be more spaghetti code and bugs due to that.

Ok, now show the cars list in three places, and one of them is a subset of only BLUE cars.

Now you have to update the DOM 3x and remember that the filter you set in that one place over there means you need to only show BLUE cars in this one place over here.

When you start to build things where one piece of data is not just shown in multiple places, but is dependent on other pieces of data, managing your state starts to become more difficult than the methodology you're describing.

Vue and React are more than templating engines. They decouple the state and view of your application. This means your view becomes a function of state, and you only need to worry about state. This solves the problem of trying to keep your view in sync with the application state, which probably everyone who has done some webdev for more than 5 years still has nightmares about.

Which template engine? Then what if you realize you need a router? Then the developer who glued those together leaves, and all you can hire is juniors.

There are benefits to using the industry standard (which today I consider Vue, React, Angular and slowly Svelte), you can learn it quickly, as it has ton of resources and you can hire easily, as you aren't forcing someone to use some obscure, home baked js framework.

That's my take at least.

> all you can hire is juniors

Then you are in trouble regardless of what you use :-)

One example is building an application like minesweeper. Would you really want to tackle that with jQuery and templating engine? I'd rather break everything into components, have them talk to each other through a state manger like vuex or redux, and only phone home to my API for important things, like the final game score.

I made a minesweeper clone in JS and CSS, it's not as hard as you'd think and just a few hundred lines of code. I still want to attempt a multiplayer minesweeper, which might benefit more from something like Vue.

A dashboard is usually for me the primary use case for one of these reactive frameworks.

I would neither need jQuery nor a templating engine to write Minesweeper.

It's great you applied your vanilla JS skills to his totally metaphorical example.

I still don't get why it's okay for every other programming language to use the STL or huge dependencies, but doing so with javascript is frowned upon for some people. You wouldn't write a JSON parser yourself in CPP, you'd install something from conan or use the STL or boost for that. Why is it so bad to do the same with js?

The browser does supply a huge number of APIs.

To set one of the Minesweeper tiles to bomb, you could do:


And you are done. The rendering will nicely take place according to what you defined in the CSS.

What are you talking about? You're just talking about simple class manipulation which has nothing to do with actual reactivity, especially 2-way data binding.

How would you support that with your "templating engines" you keep mentioning, which to me doesn't mean anything at all, in my understanding of what a templating engine is like handlebars.

As I said, I would not use a template engine to write Minesweeper.

So when I click a tile you have some code on the onclick handler to go update the counter at the top? Sounds messy if there are multiple things you need to update when some data changes.

Not the end of the world, but the client will have to download it.

So what. Gzip is a thing. Most apps I build with react don‘t reach the 1MB mark even if they‘re gigantic.

It's well known there's a sharp drop off of visitors for every extra hundred milliseconds a site takes to respond.

If you use Typescript, it means type-safe templates. That's a game-changer right there.

A short example, no, because if all you need is a simple website, then you don't need Vue either :)

If you're building complex user interfaces or a large-scale web app, then hell yeah, you want to use React or Vue.

You can use vue, because for most web-applications with vue3 you will only add an additional 15kb to it. I'd wager kilobyte counts that low are worth it when you consider how much easier it is to add on additional functionality when you need it. A well-built build system can do so much automatically for you, including but not limited to automatically minifying your code, cleaning up dead code, html and styles or compressing your images in the build step.

For reference: I recently built a really large scale website with react, including a content-management-system, custom fonts, around 50 pictures and a ton of tracking. It weighs 1,1MB total. The first request without lazy-loaded resources only uses around 200KB. Can't really argue against that.

Any code involving a mid- to large sized web application that needs reactivity. Templating engines like handlebars are used on the server side, react and vue belong on the frontend (most of the time, but not exclusively). That's the reason people use them: If you want to, you can have your logic executed on the client-side only, and host whatever else you need on a cloud-provider. Client-Side computing doesn't scale particulary well when your userbase grows fast enough.

Handlebars works nicely clientside.


This link might contribute to your evaluation. It's a seemingly reasonable overview of the top three frameworks. Author recommends using all three, spoiler?

It's almost a necessity for complicated apps. Right now I'm building an app which involves a reporting screen with all the following features on a single page:

- 10+ breakdowns for report - 10+ filters for report - Each filter has an include/exclude dropdown list which then has multiple features within even a single filter (so some filters are EQUALS/NOT EQUALS) others are INCLUDES/DOESNT INCLUDE/EMPTY/NOT EMPTY and all the appropriate options for each filter, not to mention clearing filters, etc - column sorting - column hiding - filtering with search - pagination on both client and server side (50K rows batching into sub pagination groups which client side takes over on server batches) - a dropdown at the top which re-initializes EVERY piece of data with a different account and changes quite literally re-initializes 50+ "states" of the UI on the page

Thinks of google analytics

First of all, we can assume doing this on the front end is 100% required. Imagine using google analytics where every single option you change is a backend request. Impossible, so now that weve gotten past that...

Imagine using something like jquery or custom JS where you try to manage the incredibly complicated input/output nature of each component of the page.

Component based design is required because you can keep all your logic for the entire app for a single TINY piece of the app in its own file. So something like a dropdown menu can get its own component called `<DropdownMenu>`, and within that you define all "outer state" that component can use as a prop, or input state (so for example, you want the items that appear in the list to be defined OUTSIDE the component so the component can be re-used). However, that component also has its own internal state, such as whether its open or not, whether its animating or not, what item is selected etc, so if a component has internal state, then you store it IN the component itself. So now the 'state' of EVERY component on the page is defined in 2 places... the originator of the state (such as the component which holds your API calls), or in the component itself. When any change takes place in ANY of those states, all components related to that state "update" automatically to use that new state. This means by simply making a new API call, the outer component state changes, and every single component that relies on that state updates accordingly, even for the most complex UI imaginable its trivial to think about 95% of the logic because all the state is exactly where you expect it to be, and when there are infinite numbers of nuanced side effects, you usually program them IN the component and you dont have to clutter your actual logic (say for instance the api updates your base state, you want the dropdown to reset to zero, so you would code this into the component itself, so that everywhere on the page that uses this component it would all follow suit).

Nothing you describe is easier solved with Vue then with a templating engine.

You can have a "DropdownMenu" template, feed it the data (which you call "state") and update the according element on screen just fine.

What do you mean by 'templating engine'. Give me a specific example. Templating engines to me are like handlebars... do you have a sample code example?

Say a function changes the cars array. All it has to do to update the DOM is:


Where droppy is a HandleBars template that on page load has been initialized with the html that makes your fancy dropdown menu.

Yes, you are definitely missing the point of component based frameworks. That strategy is not even remotely scalable when you have nested complex state chains that vary slightly across multiple implementations of the same component, as well as 2-way communication with the original source of the state (from form inputs, and other parts of the UI).

Each UI action in google analytics affects some other part of the UI. If you change a filter in one area, it might disable sorting in another, and simultaneously change the calendar to be only < 1 year. It might also disable some setting portion of the UI, reset the chart, change the input option on the chart axis, and then show a text input you can type in, and when you type in it, ALL THE previously mentioned states now react to the input box that appears.

You want the logic for those components to be IN THE COMPONENT. With your strategy youre putting all NON business logic and trying to account for "every possible scenario" which is the exact purpose of what reactivity does. You're not writing 1000 extra lines of code to account for every single possible combination (which can be hundreds in complex apps). Instead you quite literally write 0 lines of code, because the reactivity is handled (both ways)

Good to see this out. I want to pick a good frontend scheme for future projects but I don't really need most of the fancy SPAs and the complexity coming with it.

Invested a few weeks on Vue a few months back, then the concern about 'React has 80% market share and you can find React developer much more easily in the west" never went away.

Maybe Mithril is the way out? I just need a really light-weight client-side-ajax MVC for some embedded product webUI, in fact jquery+BT might do the job well but again, jQuery is not modern any more.

Not a frontend guy, picking a direction there has always been challenging.

I think what is not mentioned with any of the big SPA frameworks is the amount of time you invest in the churn between versions. After dealing with this in Angular for a number of years, I ended up going with stock JavaScript for my recent projects and could not be happier. Performance is much better. I have a better understanding of what goes into the product. And, I am not constantly dealing with a new version and breaking changes every 3-6 months.

That's really an Angular problem; React and Vue have had very few breaking changes over the years.

indeed. React 16 celebrates its 3rd birthday next week. (https://reactjs.org/blog/2017/09/26/react-v16.0.html)

So you suggest switching from one of the Big 3 to Mithril because you are concerned about market share, while Mithril probably has magnitudes less market share?

if i have to invest into one of the Big 3 then market-share becomes a concern, each of them requires quite some time and efforts to master, and you normally don't have enough extra time to switch after a while.

if I pick less known but easier-to-learn-got-job-done option I expect to invest less efforts, thus market-share is less critical for the concerns.

AlpineJS? A bit polarizing, but definitely lightweight...

Alpine is great for the niche it fills. All the stuff where I used to say “Vue would be overkill for this, I’ll just throw something together with jQuery”, I now use Alpine for instead, and it’s a much nicer experience. And at 7kb you can’t really grumble.

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