Hacker News new | past | comments | ask | show | jobs | submit login
Vue.js vs. React (vuejs.org)
732 points by fanf2 on Aug 19, 2017 | hide | past | web | favorite | 471 comments

We moved away from React to Vue about 8 months ago and everyone on the team is a lot happier.

First reason is we hate JSX. It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading. It's like writing shitty PHP code without templates. It also forces you to use a lot of boilerplate like bind(), Object.keys(), etc.

Another problem with React is that it only really solves one problem. There is no official React router and we hated using the unofficial react-router for a number of reasons. A lot of people end up using MobX too.

With Vue there is no need to resort to third parties for your essential blocks. It provides an official router and store called Vuex, which IMO blows Redux out of the water when combined with Vue's reactive data.

Vue docs are probably one of the best I've used. They provide technical docs, plus excellent narrative docs (guides) for all their projects (Vue, Router, Vuex, templates, etc).

I won't say that Vue is perfect, but we would never go back to React.

If you don't like Vue but want to get out of React, check out Marko, the UI library by Ebay. It's better in every way than Vue or React except that the community and ecosystem are almost non existent.


> It's like writing shitty PHP code without templates.

For me, it's the other way around. I feel like you can still separate the logic and markup, but instead of the template engine syntax you can just JavaScript.

From the top of my head, I can at least remember six template engines' syntax I've learned: Smarty (PHP), Mustache, Blade (PHP), EJS, Angular and another custom template engine. When I tried React I was so happy that I did not have to learn another template syntax as it all was just JavaScript.

Another template engine syntax? No, thank you. I stick to React.

To be fair, JSX has its own idiosyncracies too for templating, such as className, htmlFor, and the obnoxious attribute name for dynamically inserted html. It is not immune to the criticism that it requires learning.

Those names have nothing to do with JSX or React, they're the actual properties you're setting. JS properties don't map 1:1 to HTML attributes: while for example the "src" attribute is controlled using the "src" property, the "for" attribute is controlled using the "htmlFor" property, and the "class" attribute with the "className" property. All React is doing is setting the properties you tell it to.

(The reason for the name change is that old versions of JS couldn't use keywords - like "for" and "class" - as property names.)

I agree. Those examples have nothing to do with learning a new template syntax, it's simply the API of React.Component.

Granted, there is still some syntax you need to learn for JSX, but it's very little. If you already know HTML's syntax, the only new things I can think of are the curly braces for using JS expressions as prop values (you also need to know what a JS expression is, lest you try to use an if statement), and spread attributes.

I think you misunderstand. The names are unrelated to React as well, they are native. Defined by the same standards bodies that define JavaScript itself, implemented by the browsers themselves. On a blank HTML page that includes neither React nor anything else, the line `document.body.className = "foo";` sets the body's class to "foo". (And `document.body.class = "foo";` does not.)

All JSX is doing is transforming `<div className="foo">` into `[create div element]; div.className = "foo";`. If you wrote `<div class="foo">`, JSX would faithfully transform it into `[create div element]; div.class = "foo";` - which doesn't work.

Whilst you're correct, that's where the names are from, it's also not totally accurate to suggest it has nothing to do with React.

React defines `React.createElement`, `<div class="foo"/>` transforms to `React.createElement("div", { "class": "foo" })`, so React could convert that under the hood to set className correctly.

Preact does something similar to allow this. However it now seems it is now too late for React for too little benefit. And there's a downside [1]:

> The JSX transform used to do that, but we don't recommend it because it's confusing if you ever try to pass class= or for= as a prop to your own components – you wouldn't expect to access them with a different name.

[1] https://github.com/facebook/react/issues/4433#issuecomment-1...

Good point. I didn't realize that the native DOM properties are also called "className" and "htmlFor". My point still applies though, that this isn't a JSX syntax issue, your point is that it's also not even a JSX-specific semantics issue.

not quite, the list of reserved keywords was made up by the committee that designed the first version of ecmascript in 10 days (or however the exact story goes).

many years later, the workarounds like class -> className were designed by whatever party exerted most control over the JS DOM API (which is not really part of "Javascript itself") at the time, and who also brought you inconsistent camelcasing such as "onclick" ...

it's neither quite "native", nor is "defined by the same standards bodies" much of a sign of good design or worthy of copying.

feels more like if someone were to build, say, a modern high perf numerical library that includes necessary workarounds tributed to the eax/ax/ah/al peculiarities of x86 assembly.

ah so you only need to memorise the list of js "reserved" keywords and it's intuitive as a banana :)

mistakes were made. then copied, repeated and finally, standardised :)

Actually those idiosyncracies are React, not JSX. Using JSX with Mithril I've had no trouble using reserved words as attribute names. Dynamically inserted html in Mithril/JSX is just {m.trust(str)}

Edit: I should also mention that Mithril comes with routing built in, as well as XHR utility and streams. I'm finding streams super useful for sophisticated state management.

> To be fair, JSX has its own idiosyncracies too for templating, such as className, htmlFor,

those are the Javascript attribute names.

> and the obnoxious attribute name for dynamically inserted html.

Depends on your taste, but this is a plus for me, personally.

> It is not immune to the criticism that it requires learning.

It's takes maybe 10 minutes if you're already a little bit familiar with XML and know Javascript.

You're right, but it's one of those things that you can basically treat it as html until you can't - and the points at which you can't are quite specific and other than className - are rarely used. Also the dynamically inserted html param being obnoxious is by design - they don't want you to dynamically insert html, and that's a good thing. Honestly you shouldn't ever be using that param.

>I can at least remember six template engines' syntax I've learned...

TBH, in 2017, I'm not sure why we're still hand-generating HTML with any template language.

Instead, I'd really like to see a framework that gets away from the idea of HTML templating altogether and presents a true component/properties model on top of a canvas with flexible, property-driven layout options.

I think the intense UI-demands of progressiveness/SPAs expose the unsuitability of HTML for the task. But, simply because HTML is what we're stuck with browser-wise, there's no reason we have to think or work in HTML. Use tooling to abstract it away altogether and let a translator generate it.

This is exactly what we're aiming for with https://anvil.works.

We have a components+properties model, driven in Python, which gets translated to HTML+JS+CSS. We also have a visual editor, and abstractions over a bunch of the client-server stuff that's typically icky on the Web.

The challenge of such a system is that the web platform is so huge and sprawling, and constantly growing - and all of it's written in JS/HTML. So we've made the pragmatic choice to prioritise usability by non-web developers, and open an "escape hatch" for doing layout etc in HTML if you really need to. But most of our users don't need it, and we're constantly working to extend the boundary of what you can do with simple properties and components.

Very interesting. Yes, at a glance, that's exactly what I had in mind.

>the web platform is so huge and sprawling, and constantly growing

>we've made the pragmatic choice to prioritise usability by non-web developers, and open an "escape hatch

Makes sense. And totally worth the tradeoff for the developer if it helps me flip the 80/20 rule around. And, if the component model is extensible such that, when I do have to open the escape hatch, I can plug a resulting component back into the framework (lay it out and set properties in the visual editor, etc.), that might be even more optimal. Either way, I'd rather a framework do the heavy lifting and let me deal with the edge cases than me do all of the heavy lifting and plumbing, so that's a win.

>and all of it's written in JS/HTML

And, this is the part where I do have to scratch my head a little. I'm going to guess you've heard this question 4,321,257 times, but why not support JS? It is the lingua franca of the Web (as your quote acknowledges) for better or worse, and virtually all devs already know it. There's also a rich JS library ecosystem.

The idea that I have to pick up Python just to try it out introduces more friction. I'm guessing that might slow adoption with a huge percentage of your potential audience who might otherwise have the knowledge they need to jump right in.

> Yes, at a glance, that's exactly what I had in mind.

Thrilled to hear it! If you do try it in more depth, please do drop me a line (email in my profile).

> why not support JS?

Two reasons:

1. Basically, the moment you use JS, any discipline or abstraction you were trying to introduce dissolves. People will reach in and use the DOM/combine it with other Web frameworks/what-have-you. And then you'll still need to know HTML and CSS and all these other pieces, as well as this new framework, and you've done the opposite of simplifying web development. This is the "Javascript Framework of the Week" failure mode.

2. Contrary to your assertion, "most devs" don't actually know JS. It's something people only learn because they're learning front-end web development, and it's difficult to learn it without the whole HTML/CSS/frameworks hairball. Python is much friendlier to, eg, data scientists or embedded programmers or back-end developers, who have every right to think they should be able to put together a web app without learning three new programming languages and two new frameworks.

(This is another way of putting what I said earlier about "prioritising usability for non-web devs".)

>Basically, the moment you use JS, any discipline or abstraction you were trying to introduce dissolves.

I see. Kind of a purist approach that eliminates all temptation by not offering the option to go there. Sound reasoning, as JS definitely has slippery-slope potential.

>People will reach in and use the DOM/combine it with other Web frameworks/what-have-you. And then you'll still need to know HTML and CSS

I'm probably too biased to make a call on this. I'm so wanting to be released from that madness that I'd fight tooth-and-nail not to descend back into it.

So, I look at it the other way around: My JS would be more disciplined (and there'd be les of it), as I'd be released from the need to use it so much for stuff like DOM handling. In my ideal world, I wouldn't even know there was a DOM or HTML or CSS. I'd just use JS in event handling and, perhaps, functionality that directly supports the same.

>"most devs" don't actually know JS...people only learn because they're learning front-end web development

That's what I intended--that most web devs know JS--as I was speaking in the context of web development.

But, I missed the emphasis on the "non-Web devs" portion of your statement. I do get that and applaud you for staying with your focus. The product has to have a market and an identity. OTOH, it feels so close for guys like me in the Web dev world who know there's a better way!

>please do drop me a line (email in my profile).

Will do. And will try to reserve any web-dev specific comments. :)

You have tons of well established platform tools that will give you way more power at your fingertips if you wish so.

Have you tried QT or Xamarin?

>Have you tried QT or Xamarin?

These are for desktop/mobile apps right? If so, yeah, there are other options as well.

Was thinking more something like this, but for SPAs.

See Elm.

I feel that the focus on graphics has faded a bit in the most recent versions.

When I last gave it a try I had to manually generated the HTML document but without a (at least of of the box) syntax like jsx. If I recall correctly graphics is still there, but it's mainly used for games

Check out the style-elements[0] package and the author's talk at Elm Europe introducing it[1]. It outputs HTML and CSS but doesn't base its semantics on either.

It has a clean-slate design, and there's a ton of buzz in the Elm community about it. :)

[0] http://package.elm-lang.org/packages/mdgriffith/style-elemen...

[1] https://www.youtube.com/watch?v=NYb2GDWMIm0

Sounds like you want Visual Basic.

I've never worked in VB, but I've compared the concept to Swing for Web apps.

You can use JSX with Vue, and still get its other benefits. :)

Also you can do with just JavaScript. With render-function.

h('ul', [ h('li', 'one'), h('li', 'two') ])

And use native array methods instead of v-for v-if and filtering data with component methods

> With render-function.

This is even worse as for me. Generally the JSX/React.createElement approach itself and the fact that many people like the idea make me cry. Do people like it just because it's given by FB?

The syntax to me is irrelevant. The important bit is to use as much JS and as little string/DSL template as possible.

Why? Because tooling. Anything that's in JavaScript can be linted with ESLint, can be typed with Flow or TypeScript, is subject to dead code elimination by my minifier, can be shared via ES6 Modules/CommonJS wihin my project or NPM with no magic. All editors that understand JavaScript will give me all of their shinies (eg: tell me if I screwed up a conditional) without needing special framework specific support.

JSX itself used to cause these problems too (but createElement and the factories of old did not), but now that they're pervasive and that anything that supports ES6 supports JSX, I get all of these benefits for free.

The moment I hop into template/DSL land, I either hope there's a plugin with all the same benefits (often there is not), or I'm sad.

Note that people who use React + JSX and make stuff like "if" or "else" components fall into these problems too, so those have to be fully avoided.

This thread is about 'yet another templating engine'. With Vue you can use JSX or even without any templates.

Sometimes it might be useful, for small components,something like

   render: this.menu.sort().map(item=>h('li', item.title))
But i am using Vue with Pug and Stylus, i am fine with it.

> Another template engine syntax? No, thank you.

JSX is another templating language. One built on top of JavaScript rather than HTML.

Been using angular for years, and recently picked up react -- as time goes on the HTML based DSL within templates starts to approach JavaScript

> It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading.

I don't get this complaint at all. Between map and ternary expressions, you can get both loops and conditionals in your markup, e.g.

      {listOfThings.map(thing => thing.isX ?
        <X thing={thing} />
        <Y thing={thing} />

Not to mention that if a section of markup gets too big, you can break that down to it's own method that returns tiny snippets so you can have really simple methods that end up creating the more complex end result i.e.

_renderXOrY = (thing) => { return thing.isX ? <X thing={thing} /> : <Y thing={thing} /> }

//inside the render method <div> {listOfThings.map(thing => this._renderXOrY(thing))} </div>

I personally prefer this because when creating the top level of a component, I largely don't care about the individual elements of a list, but rather am structuring how that list will be contained etc.

And let's not discount then the value that JSX brings of being able to easily unit test that your conditional logic renders the correct output easily (Jest + Enzyme = easiest tests I've ever had to write, bar simple functional checks).

Right, being able to compose, test, structure and develop my HTML in the same way I'm doing it with my application code is for me the main Reason for never wanting to go back to anything that's based on classic string-like templating. The latter always felt as clunky as programming without a proper function abstraction.

For me it's quite the opposite. I find that so confusing when you look at html in JavaScript and don't know right away what the result will be. It's like were back in 2002 doing PHP.

Different strokes for different folks - my thought to that is pretty much that I don't really care what the result will be on the grand scheme, but more specifically isolated nodes and how they will interact with my model/data etc.

Having the ability to see exactly what's in scope right next to the markup to me is invaluable - one of my biggest dislikes in templating languages is swapping between files that define the data in the scope and the template to use said data.

I'm with you on this. JSX is quite a bit easier for me to reason about than the Angular-like expressions of Vue. But I am glad that there are viable alternatives available for those who don't feel the same way.

But you can use JSX with Vue if that's what you prefer. Vue passes everything down to render functions in the end anyways.

React forces JSX use, so a lot of times the battle between Vue vs React seems to be Vue Templates vs JSX which never makes sense to me.

React does not force JSX use. JSX just compiles down to React.createElement.

I feel React.createElement is so unergonomic it's not really an option to use directly. A lot of React supporters mention it when people criticise JSX, but I don't think it's a pragmatic alternative.

I know people who use React without JSX and it reads fine, as long as you assign React.createElement to a shorter alias. I like that you don't have the visual noise of closing elements. I think it's mostly a matter of taste (and how much you care about your HTML-generating code resembling HTML).

And you think that's easier to read and write compared to any templating language of the last 15 years?

Btw you missed :

It's slightly less easy to read than <li ng-each={myList}>...</li>

But it means you don't have to learn a library's HTML API.

Or when you want to loop through myList, but exclude a few particular items... you know how to write that in JS, but have no idea what to do in the mark up language. You could create a filteredList, but it's often not ideal

I cannot really understand how today mixing logic and presentation in JSX is considered a good thing. The first principle when writing complex systems should be to completely separate the logic from the presentation layer. Nowadays people seem happy with intermingled monstrosities like the one shown in the JSX code upstream.

All of the "logic" inside render is _presentational_ logic. What would be a better place for that to go?

Because you don't really understand separation of concerns

I think I understand it quite well having worked for more than a decade on complex systems. I can't say the same for you if you think that putting some logic in the presentation layer like the example above is a good thing. I would always transform my domain in the model object while the presentation layer should only present the transformed model. Using a map function directly in JSX is a sure recipe for disaster in a complex system. But I seriously doubt that you can understand this looking at your answer.

He is right taught. You are allowed to have all the logic you want in your presentation layer. As long as it is presentation logic this perfect. If it is "Business logic" then this is wrong. Have you realised than having a if statement is already "logic"? Template system that don't have if statement are absolute trash IMHO.

Ah ok. So for you using a map with a ternary operator over a list of objects in JSX is perfectly fine and you can't see what is wrong. I don't know Vue.js, but in WPF I would have simply bound an ItemsConttol to the list of models. Stop. Finished. No presentation logic at all in the XAML file. WPF will automatically bind the correct DataTemplate to the specific ViewModel contained in the list. I would have never ever approved a pull request in which someone implemented that using a monstrosity similar to the one shown in this thread. The XAML file, as the HTML layer, should be completely devoid of logic and should delegate the whole work to the underlying model. Reading this thread, apparently in React is encouraged to do whatever sh@t you want directly in the JSX file rather than delegating it to where it belongs. Heck, you are even excited that JSX is Turing complete, as if it was a good thing. I will continue happily to write my code respecting the separation of concerns, leaving all the logic out of the XAML or HTML. You are free to continue to put everything in the JSX if you like it, but don't expect me to stay silent when you mislead many people in thinking that writing logic in JSX is the right way to go.

> So for you using a map with a ternary operator over a list of objects in JSX is perfectly fine and you can't see what is wrong

I don't really know JSX much and without a specific example this is pointless to discuss. But basically JSX is syntactic sugar over javascript. A ternary is just a "if" condition so I don't see where is the issue here. Are you really using a template language devoid of conditionals? Even mustache the "logic-less" template has a form of it.

> The XAML file, as the HTML layer, should be completely devoid of logic and should delegate the whole work to the underlying model

The role of the model is and has always been to handle /business/ logic not presentational logic. If you put your dirty presentational logic inside my models I can tell you I will /never never/ accept your pull request.

So let's recap.

* You don't know JSX

* You have no idea of the specific example posted in this thread that I'm speaking of

* You have no idea about WPF and what is a view model

But nonetheless you feel entitled to discuss about things in which you have zero knowledge. This is the JSX code posted in this thread:

<div> {listOfThings.map(thing => thing.isX ? <X thing={thing} /> <Y thing={thing} /> )} </div>

Instead of this monstrosity in XAML would be like this: <ItemsControl ItemsSource={Binding ListOfThings} />

But of course for you is better the JSX code. Luckily for me you will never have to review any of my pull requests, I seriously doubt that you can accept something that you don't understand.

No, but he knows that templating languages have been wrestling with pretty much the same three or four issues since the beginning of HTML templates. It gets old.

It gets really old to see people try failed experiments over and over again, which pretty much is what you are suggesting.

Also, you got some display logic in your examples there, buddy. If you can't see it then no wonder this conversation is going in a circle.

I didn't have to go very far inside ItemsControl to see the example of the "presentation logic" you say doesn't exist. E.g.


What is that if not an horribly verbose switch case for modifying the representation of different elements passed to the ItemsControl?

I am not advocating that the JSX is particularly pretty or clever. I am objecting to your crazy notion that there should be no logic in the representation layer.

I asked you to please don't speak about things that you don't know. The page that you linked has nothing to do with presenting multiple items with different types. It is defining the visualisation of the control itself, defining the arrangement method for the contained items, defining the same visualisation for each item and finally it defines the container visualisation for each item. To replicate the JSX logic in the example discussed the code that I posted is all you need. It will bind the source of the ItemsControl to a list in the ViewModel that contains the different ViewModels that you need to display. WPF automatically will find the DataTemplates defined for those ViewModels and use that in the visualisation. No if, no switch, no map and nothing at all in the XAML file. Just:

<ItemsControl ItemsSource={Binding ListOfThings} />

I think you are comparing Apple with oranges here. React doesn't have a ViewModel notion that would binds data with Component. The binding is happening in the templates themselves so in the Component themselves and there is no in-between layer AFAIK.

If you are looking for exactly this feature you might be disappointed.

Vue.js and Angular have the ViewModel concept.

I have used those 2 frameworks in the past. Could you point me to the documentation about ViewModel in Vue.js I wasn't able to find anything relevant other than:

> Although not strictly associated with the MVVM pattern, Vue’s design was partly inspired by it. As a convention, we often use the variable vm (short for ViewModel) to refer to our Vue instance.

I am sure it wouldn't be very hard to develop such a layer within React if needed.

It's useful to separate mantra and intent, here. Yes, separation of concerns is a useful thing, but if you just take it to mean that no logic should ever be involved in your templates, you're taking it too far and unnecessarily complicating things. If a section of the page is scrollable or expandable, the scroll and expansion state (and event-handlers) clearly live in the presentation layer and don't belong in any of the data model. (They aren't the only examples, but they are ones that most people accept.)

> Or when you want to loop through myList, but exclude a few particular items

Easy, just create a computed property in Vue.

+1, Also as a side effect you will get a cleaner declaration of the filtered list (rather than making it a part of the rendering process, lol).

Yes, that's easy, but adding something to your model just because your view wants it rather seems like the cart driving the horse. If your view needs something that your model otherwise has no use for, then it does not belong in the model.

There's no real clear cut line where you can say that a model had no 'use for' a certain field.

If your point of view is that a model is meant for more than just doing the view, then yes, adding view only fields may pollute it for others (e.g., analytics).

But if your model is meant to drive the view of the app, then the story is very different. And some times you can't even tell if the model is just there to drive the view our not, since requirements change often.

and marko => `<if(...)><li for(...)> ... </li></if><else><i>no results</i></else>`

Yes, by a long way.

> First reason is we hate JSX.

I feel like this is often the reason people dislike React, and it mostly comes out of a misunderstanding of JSX and es6 syntax and interaction. Why do I say this? Because I've yet to hear an argument that came after a statement like above which was actually true in any way. Most arguments that come after actually expose the fact that the author of the statement simply doesn't understand the syntax usually because they've never really bothered to try to use it and instead are simply turned off by something new in their code.

> It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading

This is quite simply false, it doesn't force you to do any of these things. A lot of people seem to think it does which again comes from a misunderstanding of the syntax. You're quite able to either embed your logic into the JSX or not, whichever you prefer. I most often see people lean toward the former unless the logic in question is extremely complex in which case it could be argued it's best being removed from the markup anyway. But JSX itself does not force you either way.

> It's like writing shitty PHP code without templates

I simply don't see a viable comparison here at all.

> It also forces you to use a lot of boilerplate like bind(), Object.keys(), etc.

Again, this is simply untrue. In fact I'd argue that if you're using lots of .binds you're doing it wrong. .binds inside your render function are actually bad practice due to the fact that they mean you're adding overhead of creating new bound functions as each .bind returns a brand new function every time your render tree executes. The overhead of such is probably negligible, however it's still inefficient and cumbersome and thus is bad practice.

As for Object.keys() - While I share your dislike of the overuse of this particular method, I'd love an example of where you think this is forced on you by JSX because for the life of me I can't think of one.

> There is no official React router

This I completely agree with, it is annoying, and I too am not a fan of react-router. However it's so easy to create your own routing setup and/or plug and play other lightweight ones that I don't usually think of it as a particular plus/minus point when comparing to frameworks like Vue.

Our team had the same thoughts on react-router. I'd suggest checking out https://github.com/kriasoft/universal-router. It uses the HTML5 History Library (https://github.com/ReactTraining/history) for navigation.

> First reason is we hate JSX. It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading. It's like writing shitty PHP code without templates.

here here! This has been my experience as well

In my experience, the folks that feel the strongest against JSX lean anti-JavaScript in general. JSX is Turing-complete. There are no gotchas, you can't paint yourself into a corner, you can set breakpoints in your map statements, it's more testable...Lots of benefits and a big step up over string-based templating languages stuffed into HTML.

And how in the world is that a good thing? I'm really starting to wonder if people that exalt JSX with his mix of logic and presentation have ever worked on complex systems where the lack of separation between the two layers brings you quickly to an unmaintainable mess.

JSX & React were literally built to solve Facebook's maintainability concerns, which is one of the most complex client side web apps I can think of. JSX was a hard sell at first 4 years ago, but Pete Hunt did a great job then, explaining how the false separation of concerns between HTML and JS really is unavoidable. You end up with logic in HTML tightly coupled to your JS no matter which way you shake it. https://www.youtube.com/watch?v=DgVS-zXgMTk

And HTML string template languages have been shown to have numerous shortcomings at scale.

Separation of concerns != splitting logic from presentation.

SoC comes from MV* architectural patterns. In real world front end applications, people who separate based on the file extension often end up creating JS files that breach SoC - they are both handling view rendering as well as application logic inside a JS file.

If there is something that should be conditionally rendered, using JSX is no different to a template language - only thing is the variable you're using to do that isn't actually in that file either (so, over-separation of concerns?). Both of these are logic - one handles it inline and the other handles it across multiple files.

No one is advocating that JSX should break SoC (a component should never talk to an API, or implement business logic - it should be responsible for given a set of inputs, it will render the same output time and time again).

*hear hear! ;)

In fairness, it is entirely possible that the parent was correctly indicating the location of a salient / appreciated point in this discussion thread ;)

I'm not OP, but that's unlikely. This is general language construct and is used in the beginning. No one use "here here!" :D

Just use ockham's razor, would you suppose he misspelt a general language construct or created a whole new one? :)

I can end this post here, but I want to mention one more thing I'm reminded of: In Sherlock Holmes TV Series (don't remember the episode), a woman dies while writing "Rache" in her own blood. Other characters tell him that Rache is revenge in German. Sherlock posits that she was trying to write "Rachel", a much simpler (I mean with less assumptions) assumption to make in the context.

"HN Pedantry" is rubbing off on me :D

The funny thing about "Rache" is in the original story it was the other way round. :)

here-here document spotted in the wild

Jsx is one of the best parts of react. No way I can go back string templates and it's own languages.

Vue optionally supports jsx, too

Absolutely agree. Most front-end meetups/conferences I've been to have had the majority of people there expressing a dislike for JSX. I still don't understand that to this day, to me JSX is one of the best things about React.

I feel like JSX is the biggest failed promise of React. It's supposed to make the behavior of views transparent by building markup in plain JS. But what actually happens is you have to write noisy JavaScript that obfuscates your markup.

Just look at any component that dynamically generates CSS classes. Template strings with ternaries? Another dependency for generating nice CSS class strings? Give me a break.

JSX falters because JS is not terse enough. You end up with templates that have neither readable logic nor readable markup. And naturally, programmers being as lazy as they are, these templates become a holding bag for -every- concern.

> First reason is we hate JSX. It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading. It's like writing shitty PHP code without templates.

You could theoretically write some template components and "avoid" javascript altogether. I wonder if anyone has actually done that?

JSX isn't perfect, but I find the dirty things about it can be mitigated by keeping your components small, and if that isn't possible then keeping the render function small by breaking it out into several functions that return pieces of your markup. Writing small functions is sound general programming advice, but it seems especially true with JSX/React.

Yes, there is a project called react-templates by Wix that does that.

We used it, but once you start using libraries like that one or MobX, why even use React at all?

>We used it, but once you start using libraries like that one or MobX, why even use React at all?

Well, you've got a point. I can realistically see some developers preferring to piece-meal their front end solution though, or build just the parts they need themselves. I like Vue, but the API seems enormous. I get that a lot of people like that about it, though.

Personally I don't think Vue's API is that big. Most of the bread and butter stuff are learned in an afternoon.

IMO the argument that React's API is really small is a fallacy since React is but a small piece in your project. You get nowhere without a router, local and global state management, transitions, etc.

The other factor to consider after the learning curve is productivity. Vue has a pragmatic nature and in my personal experience I can get the job done faster.

I think React is idealistic.


I'm surprised to hear you say that Vue has a large API, because one of my reasons for adopting Vue was its small API. It allowed me to hold a mental model of the API in my head.

You can go through the entire docs in less than an hour and get down to business. I did not have this experience with Angular 1 (don't know about v2) or React.

I don't think I buy your defence. Sure, you can make JSX look readable - if you decompose your markup into a thousand scattered functions. But this just swaps one problem for another: indirect code, verbosity, not being able to see the component markup at a glance.

I just feel JSX is too awkward and verbose to be pleasant working.

Hm? You can actually write loops and conditionals inside of the markup. And... why would you strictly want to do that?, you can write cleaner code by separating your logic/UI. This look more like a rant overall.

Ultimately you can, but your JSX code becomes more difficult to read and write.

> you can write cleaner code by separating your logic/UI

That's precisely the point of using a templating language: separation of concerns.

JSX mixes producing markup with your component logic.

> This look more like a rant overall.

There is a difference between an opinion and a rant. I really won't debate whether Vue is superior to React, I'm just stating why I prefer it.

> It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading

What does this mean? I have a sneaking suspicion this is a symptom of poor separation of concerns.

It means that you can't loop where you actually need that loop and that makes reading and writing markup harder than it needs to be.


Since JSX mixes logic and markup indistinguishably I'd say that's where the poor separation of concerns really is.

I'm not sure I follow. To use the basic example from the link, as opposed to this:

  const listItems = numbers.map((number) =>
  return (
What's wrong with looping this way?:

  return (
      {numbers.map((num, i) => <li key={i}>{num}</li>)}

> What's wrong with looping this way?

The problem IMO is that it's harder to read and write than:

        <li v-for="num in listItem">{{num}}</li>
That's Vue's syntax, but any other templating language is more readable to me than JSX.

I find the JSX loop infinitely easier to understand what's going on. It's a javascript map. With your Vue example, what is listItem? An array? Can it be an object? Does listItem need a special decorator for v-for to be able to loop through it?

So many initial questions that just aren't there if you just use Javascript.

I'm not entirely sold on Vue, I've never used it before, and I'm happy to use JSX but the Vue template code is far, far clearer to me.

it's just plain for(x in list){ .. }

v-for="item in list"

if you need idx:

v-for="(item, i) in list"

pretty standard stuffs

Cool, but in JSX it's just javascript as you would write it anywhere else in your app, except encapsulated in braces. How is that not simpler for people who should be Javascript developers?

I thought the whole point was that you didn't have to write loops in Vue.js and yet here is a loop in Vue.js.

How does this actually work? When I see JS-esque code passed as a string I get a little queasy. Is this "eval"-ed so I can use real JS there? Or is there some Vue parser that reads this little mini language and interprets it? What is `listItem` exactly, and how does that template have access to the data represented by it?

When I'm trying to digest a bit of code, the superficial representation of what's present on the page is only half the battle - I also like to understand what it's doing under the hood. For me, then, JSX is way easier to grok than this bit of code, since I have a mental model of how JS works, and JSX is just a very small serving of syntactic sugar to compile an HTML like template into native JS. I know the transformations that are happening, and I can envision the code that it's being transformed into.

Templates have always been nice for basic examples. But now what happens if you only want to show odd numbers in listItem? It's not obviously clear how to do that in this example. Then you start adding in filters or Angular pipes. And the syntax grows in complexity until it becomes unwieldy. If you know the basic rules of JS, you already know how to achieve this with JSX. There's no need to go read the docs.

Haven't used VueJS but the obvious thing to me would be to do your data transformations before hitting the view code - separating view code from business logic.

So is this really a problem?

You don't always want to transform data, sometimes this is merely a UI concern...as in filtering, sorting, etc.

Yeah, so filter and sort it before you hit the view (and by this I mean the markup jsx or whatever) code, and problem solved ;)

Classic MVVM pattern

Then you're back at OPs original complaint which was that loops take you away from the markup you're currently writing.

Sorry, I shouldnt have said 'business logic' here. I really mean separating presentation and presentation data.

Since the logic inside of JSX is just JavaScript encapsulated in braces, you're basically saying that Vue's angular like attributes are better than just simple javascript syntax?

I don't understand how

        <li v-for="num in listItems">{{num}}</li>
is less readable than

        {listItems.map((num, i) => <li key={i}>{num}</li>)}
Both are pretty readable, but the latter is essentially normal javascript, with the idea that you can return dom elements in it. The only thing that a javascript developer with zero jsx experience needs to know is that you can express dom elements within your javascript and treat them exactly like functions that return that element (which is what they are).

What someone has to know to parse your vue example is the exact syntax for for loops in vue, evidently the syntax in this example is quite simple but what if they want to perform extra logic in that loop to modify which elements to show? In the react example all they have to do is know javascript.... in Vue they have to go look up how to do that in Vue.

How is that more readable? Furthermore, does that break at runtime if listItem is undefined or you typo'd the second num? JSX would catch it as a syntax error.

Do you need the whole text of an error or answer "yes" will satisfy you ? :)

Yeah, runtime errors are bad. I don't know why you'd want to inject a string-based language inside JS.

I guess it's taste, but that's far less readable than the JSX with `.map` example to me. JSX is easier to use and read because you just use the JS constructs that you already know rather than a whole new DSL.

GP formatted it wrong, you could write the JSX example like this:

  return (
      {numbers.map((num, i) => (
        <li key={i}>
Which with syntax highlighting is, imo, as readable as any piece of code.

The advantage is that it is statically checkable with a linter, so you would get a compile-time error if you misspell the HTML tag, a variable or anything else.

If you use something Typescript, the compiler will even check the props given to components (and if you use VS Code, you'll get auto-completion for variables, methods, props and anything statically checkable). You can even apply inheritance to components for dynamic component switching.

I briefly used Vue before switching completely to React (with Typescript, Webpack and Mobx) and it finally became enjoyable to write Javascript applications.

Yes, this much easier to read. Only `v-for` is a bit of a black box so you need to find it's implementation in the Vue code to find out what's exactly happening

What makes Marko better then all others in your opinion? Apart from speed which is the only thing I could gather on the Google.

And why are there no interest? Because it is from Ebay? I mean look at the reply and no one even want to touch on it.

Marko is faster and lighter. Also the syntax of single file components is more minimalistic than Vue, which is a good thing.

I'd say there is no interest because the single file components are quite new, and before that the project was focused on being a really fast templating engine.


Check this presentation about Marko, I found it illuminating.


Thanks for sharing this. I'd never heard of Marko until you brought it up and it looks amazing so far.

We run marko in production. My favorite part about Marko is the automatic dependency management. If you already defined a `Modal` component, you can just use it in other components / pages by writing `<Modal />`. The JS files AND the CSS files will all get auto-bundled into your page.

Marko is also the only framework that supports server-side rendering streaming. This means that your user will start to see HTML even before the page has finished rendering. Afterwards, the page is bootstrapped and components run on the client side. It's very fast.

I've been using marko for ~1yr now and don't work for eBay.

1) It's a templating language, not JS, not ternary operators, etc. Where this really makes sense is the following (probably valid marko). I _dare_ you to rewrite this simple search-results component in your FE framework or programming language of choice. Note how "state" is transferred in to a component

.../components/my-component/index.marko ``` <await( results from component.resultsPromise(state.search) )> <ul if( state.search && results.length > 0 )> <li for( r in results )> <!-- the "a href" will be prevented in a single-page context --> <a href="${component.getLink(r)}" on-click('emitEvent_ResultClicked', r ) >${ r }</a> </li> </ul> <ul else> <li><i>no results</i></li> </ul> <await-placeholder>Loading...</await-placeholder> <await-timeout>Timed Out!</await-timeout> <await-error>Errored Out!</await-error> </await> ```

.../component/other-component/index.marko ``` <div> <my-component search="whatever user searches for" on-result-clicked('handleUserSelectedResult')/> </div> ```

2) It's like PHP (mostly the good parts) ... there's only one negative I currently have with marko and that's the deprecation of "<var />" or "<scope />", as with "really large templates" (already an anti-pattern), the lack of scope can cause variable shadowing.

3) you can break out into "just javascript" at any point ... `$ var xyz = 1 + 2 * component.functionAbc( 123 )` and then use ${ xyz } right after. I personally prefer having `scope...` in my arsenal so I don't accidentally re-use `var xyz` but it's really rare if you make small components and keep an eye on your refactoring.

4) It is _designed_ for both "virtual dom" + "HTML streaming" ... virtual dom is what helps diff trees efficiently (client side), but HTML streaming is the real genius. Given a relatively declarative template (which is what marko deals with), marko will actually take your "foo.marko" and literally compiles it into: "make_a_tree(...)" or "make_a_string(...)" which runs on client or server respectively.


``` $ mkdir foo && cd foo $ marko create xyz $ cd xyz $ npm start $ open ```

Follow along with the docs / tutorial and then humor me and run the following:

``` $ npm start $ curl -s | wc -c 5388

$ NODE_ENV=production npm start $ curl -s | wc -c 1678 ```

I've used angular 1.x, ember 1.x, a touch of react, and I'm most hopeful for marko, as I really see a way for an SPA to start up using the smallest-possible-html-bootstrap, marko to download after first paint, attach handlers, etc. and be "as active" but "as quickly as possible" ... harkening back to the "good old days" of PHP and JSP where the content rendered quickly ... mixed in with the "good days of today" where subsequent page renders don't just blank out the browser, but instead, efficiently load up only the changed portions (ie: the SPA / single page app / progressive experience).

It's easy to do a "progressive" experience requires a 1MB download of JS before first paint. It's actually really cool to be able to render a 100kb page in only 100kb of network traffic, but also to have all your handlers / regular JS working from the remaining 900kb ready to work automatically _enhancing_ your page, but not to have to make any tradeoffs or think about it in order to do it.

The quality of ebay's website gives me a lot of hope for marko /s. Seriously though, if they're going to build this why not fix the UI on ebay itself? Is it just too large an application or are is an update just around the corner?

Also the scroll jank on markojs' homepage doesn't make me feel extremely bullish about the framework.

Aurelia has a great router and many other things going for it as well.

I like JSX.

> It's like writing shitty PHP code without templates.

I don't think you or your team knows how React works or even PHP.

> Another problem with React is that it only really solves one problem.

You and your team hate React for the wrong reasons. You just simply don't know what React is in the first place. React is not a framework, is more like a view framework, it was never designed to solve routing, models, problems.

You'll see quotes in this thread like "The demand for both React and Vue.js is growing tremendously" thrown around. It's good to check out npm install stats to get an unopinionated comparison.


In reality, React is downloaded roughly 4-5x more than angular and 7-8x more than Vue. In August so far, React has 75% market share among these three libs. Interestingly, this share has grown in August compared to both last month (July) and beginning of year (January).

While this thread and the license thread might indicate that React is dying, it's not. It's growing.

If Vue is going to be what React is today, it has quite a long way to go.

Something worth noting is that both Angular and Vue are far more script-embed-directly-into-page friendly (mostly due to templating) compared to React. Almost all React users get it from NPM, while I would expect that the proportion of Angular or Vue users who get them from NPM is lower. I've seen a lot of projects for those two run without any build system (and anecdotally, I'm pretty sure I'm not the only one who's learned Vue with just a script embed).

Perfectly said. I've used Vue for a couple of months now (a couple personal projects, experiments and some dashboards) and used Angular for ~2 years before (admittedly, mostly Angular 1), and have literally never had to start off from 'npm install', unlike react (which I used for a year or so before), where everything needed a lot of boilerplate setup.

Most devs I know start a react application by cloning some standard git repo which has a working webpack/tidyCSS/redux/some test suite etc. and then write your first line of useful code. The boilerplate is enormous!

Most Angular 1 projects I saw would start off with a Yeoman/Bower MEAN stack implementation. The boilerplate no less enormous there. I'll admit Vue is nicer about these things than either Angular or React, but Angular has tons of boiler plate.

I've used react without npm at all. Just download the react and reactdom scripts from its official site, put two <script> tags in your HTML and that's it.

Angular 1 is, but Angular 2+ is not at all. Angular's CLI is Webpack based, and leverages NPM for package management.

As for build systems vs. script includes... I think Vue is probably being used in a lot more hobby projects than npm downloads would seem to indicate...but using a build system is a stronger indicator of a professional web app and pretty much necessary for any non-trivial project.

I think this would be very likely. For instance, we are still using a bower install of angular due to rails asset pipeline that is committed into repo. Our tens builds per day that would be fetching fresh are not fetching angular for that reason.

A very large number of people use React in the same way, linking to a cdn.

Could you explain your rationale? I highly doubt that a very large number of people are hand-writing render functions... I personally gave up on React and only picked it up several months later after finding out that using it with just a script embed was exceedingly painful.

  <div id='root'></div>

  <script src='https://cdnjs.cloudflare.com/ajax/libs/react/15.6.1/react.js'></script>
  <script src='https://cdnjs.cloudflare.com/ajax/libs/react/15.6.1/react-dom.js'></script>
  <script src='https://cdnjs.cloudflare.com/ajax/libs/babel-core/5.8.38/browser.min.js'></script>

  <script type='text/babel'>
    const App = () => <div>Hello World</div>;
    ReactDOM.render(<App />, document.getElementById('root'))

A lot of people will have a bundle that they've transpiled, but use the global React object from pulling in React and ReactDOM from a CDN. Other folks will use a library that offers syntax like:

  elem.div(elem(Component, {prop: 'value'}), {className: 'foo'})
It's surprisingly common, and it's listed not too far down on the React installation page:


You can include a babel script that compiles everything on load. There's a performance hit but people do it because it's easy.

Edit: more information: https://github.com/babel/babel-standalone/blob/master/README...

Babel-standalone was put together as part of the pretty good reactjs.net .Net implementation of react, after the 'official' version of babel-in-the-browser was killed off.

It's /really/ not intended for use in prod.


Edit. I kinda sent off on a stream of conciseness about reactjs.net here, feel free to ignore this bit.... :D

Infact, as well made as it is and despite using reactjs.net heavily for the last couple of years, the only time i would be inclined to use it on a new app is to leverage the universal rendering, or if your react app is just freaking massive and takes forever to run a build - otherwise you may aswell just throw everything at webpack --watch via iisnode or regular 'ole vanilla node.

Then again we had to make a bunch of changes to the package itself to fully support our bundling (we don't like cassette so we made our own) and to support multiple server-side bundles, none of which are agnostic enough to warrant a PR, so upgrading reactjs.net to a more recent version is a hassle, making me slightly biased against using it ;)

The "angular" npm-package is for angular1 only though, angular from 2+ forward is located in the @angular namespace on npm. So a more correct package to compare to would be something like @angular/core, or if you want to track all versions combine angular and @angular/core.

edit: looks like angular had 1 million downloads last month and @angular/core 1.7M.

From the charts, it shows that Vue from 2016 to now well over doubled it's downloads (over 100% growth) while react's only grew by 50%.

It can be deceptive when you look at charts that list totals when what you're concerned with is growth rate.

So from 2016 to 2017, React's market share grew from 74.6% to 74.9% while Vue's market share grew from 5.4% to 9.3%.

A more accurate narrative would be that Vue is eating the dying Angular.

From the beginning of 2009 to the beginning of 2010, Chrome's market share grew from 0.2% to 6.4%, while Firefox's market share grew from 32.1% to 32.9%. Both were eating the dying IE, whose market share slipped from 60% to 50%:


Which one do you use now?

I remember that when Larry Page granted the Founder's Award to Chrome, there were several TGIF questions saying "Isn't it premature? Chrome's market share is only 5%, and the vast majority of web users have barely even heard of it."

Larry's response was "In my mind, Chrome has already won," and in hindsight, this is probably what he was referring to. When a large number of users are flooding into a brand new product, even though there's already an alternative that's pretty good on the market and still growing, that usually means that the new product fills some burning need or deficiency that existing alternatives don't. That comparison will continue to hold unless competitors address it. That's why investors look so heavily at growth rates: if you're growing 15x faster than your competitors, you're probably going to end up with the whole market, given enough time.

That what people said about the early growth in windows phones too.

I literally remember standing there listening a microsoft rep tell me that 'When you don't have much market share, there's always room for great growth".

...just saying, you can spin the story however you like, but the fact is that Vue currently has a reasonably insignificant market share.

Beyond that, all we can do is speculate.

More that 9% and growing at more than 100% per year doesn't seem insignificant at all. Windows phone arrived briefly at just over 3% and then immediately declined. The comparison between vue.js and windows phone doesn't make sense at all.

> As of the third quarter of 2013, Gartner reported that Windows Phone holds a worldwide market share of 3.6%, up 123% from the same period in 2012 and outpacing Android's rate of growth.

Sound familiar? (and I assure you, that 3.6% is a whole lot more than a 135k measly installs a day).


That's called 'unsustainable small scale growth'; and it's what you're seeing with vue right now.

A good year over year growth of 2 or 3% is far far far more compelling than a tiny 100% growth rate from nothing to nothing.

Look at chrome's history of growth and that's what you'll see. In fact, if you look at the long term history of all three, that's what you'll see with reacts growth as well: https://npm-stat.com/charts.html?package=react&package=vue&p...

Sure, maybe vue and windows phone are different beasts and they're difficult to compare... but the comparison to chrome makes zero sense either at this point.

This '100% growth' stuff is pure hand waving nonsense. Its obviously unsustainable.

The question is, can vue turn its current trend into a sustainable consistent growth and take on react? I dunno, but I can guarantee you the answer to that question is something that no one knows at this point.

If you only look at Vue and React, you can see that there is an increase in Vue's share on the weekends.

That may not be a true leading indicator of adoption, but it is hard to argue it isn't an indicator of increased interest.

I tend to agree with this. I think the age of the monolithic front end framework is coming to an end, replaced by smaller component-centric frameworks like React, Vue, Inferno, Marko, etc.

AngularJS maybe is dying but Angular is on steady growth.

What makes you say that Angular is dying? The chart seems to show a significant grow in downloads.

Another chart worth viewing:


Hiring is a lagging indicator, but I see React hitting a plateau the way angular did. I see Vue is on the cusp of takeoff. Time will tell if it fails to launch, but I'm seeing more interest in Vue at meetups than React.

I think a lot of this has more to do with React's state management than licensing. One of the react developers said it best. Paraphrasing;

Everyone stopped saying React is fun after Redux.

> Everyone stopped saying React is fun after Redux.

From my understanding managing state is a fundamentally hard problem, and Redux just make it very explicit and avoid the confusion of a state living in multiple places.

Did not try Vue but is the state management simpler?

way simpler. it's just Redux down to it's core minimum, which is really just an abstraction layer to setting variables.

Redux's core minimum is already pretty incredibly minimal; I have a hard time imagining things much more simple than that.

react-redux, which is neither redux nor the only way to integrate redux with react, is a bit more complicated but still not very complicated.

Angular didn't hit plateau, but collapsed after ng2 was announced. React will replace angular and hit plateau just because the number of f/e jobs is limited.

Redux is completely optional, 3rd party library. So I really don't understand why anyone would say that. You don't like Redux? Don't use it.

Everything is a 3rd party library when it comes to the building complex React based app. Redux is a part of the hype train, so you are going to use it if you are on the train.

There's two mainstream options for state management right now: Redux and MobX. But even the creator of Redux says "You might not need redux" https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

Right, and MobX like thing is built-in into the Vue.

Note this chart is actually showing AngularJS (1.x) only. NPM only started exposing stats for @scoped packages recently, so @angular/core (Angular 2+) only has a few months of history.

See https://npm-stat.com/charts.html?package=react&package=vue&p...

Here in NYC I have yet to see a job posting asking about Vue. It's all either React or maintaining an older Angular app.

usually it takes a few years for a new framework to take hold, since the react devs are probably still working on their projects and wont be switching in the middle of it. but in two years, who knows, you might be glad you picked up vue when you see almost everyone starting their project in vue come time being.

I don't think one should base the decision what to choose solely on "who gets more downloads".

Otherwise we would all be still using PHP instead of Python or Ruby.

I think it's going to get there. The sheer number of JavaScript developers means there's always someone out there who wants to try something new, and haven't invested in learning React yet. Doesn't hurt that contributing a meaningful library for a framework comes w/ a healthy dose of internet points.

React was in the same spot a few years ago. It went from a dark horse to the default over the past two years.

I really don't want Vue to become another React. React used to be a single </script> dependency in the browser and now it is difficult to find examples and discussions that don't require downloading npm and all these other components.

What do you have against npm install create-react-app?

Because I'm programming Rails and I don't want another ecosystem polluting the devspace for these projects. (See the unholy mess that is react-on-rails, what with bringing in v8 when Rails already uses another JS engine). I also strongly disagree with node's module culture, and prefer mature environments. The browser loads scripts, why can't that be enough?

I see React and Vue as tools for scratching very specific itches: fast DOM manipulations and databinding that actually works. React was this, then it grew and grew and grew. Vue is threatening to move away from this.

Also, still pissed that my year-and-a-half old react code is now hopelessly out of date, and requires updating (guess what, I'll be porting it to vue instead). That is bullshit.

Your year and a half old React app shouldn't be "hopelessly out of date" unless you did something very wrong.

If you want to use React with Rails, use Rails in API mode and keep the front-end separate. I'm not sure how rewriting in Vue is going to solve any of your problems at all.

"The browser loads scripts, why can't that be enough?"

Not sure what you mean by this. Whatever you use, the browser will be loading scripts.

From a Rails perspective...

Vue doesn't require nodejs to follow along with the examples

Vue doesn't prescribe to me how I should write my markup (beyond Angular-style attributes) or force me to violate separation-of-concerns.

Vue doesn't require it's stuff to be stored in $ROOT/app/assets/javascript/components, when all the rest of my code lives in $ROOT/app/whatever

Vue doesn't (or didn't) prescribe all these stupid little companion addons to do things I learned how to do (and do better) years ago

Vue doesn't give me a shitty markup language (JSX -- class vs className? Fuck off!) or even worse alternatives (its super verbose JS-DOM alternative) if I don't want (or can't) use it

Vue doesn't have nearly as large of an obnoxious, inexperienced, harebrained, and cloud-huffing crowd that will argue with me when I express distaste in it

"Vue doesn't have nearly as large of an obnoxious, inexperienced, harebrained, and cloud-huffing crowd that will argue with me when I express distaste in it"

Personal insults aren't cool.


Indeed. There is a lot of hype around vue.js, and maybe some is even warranted, but companies and devs are almost entirely split between Angular2 and React in my experience (been hiring, so reading lots of CVs and talking to devs).

Vue.js might be better than React in some ways, but is it enough of a paradigm shift to throw away a bunch of hard earned knowledge?

This is a great point. I see Vue and I like what I see. However, the difference with React was that it was a big step up from everything that came before it. Vue is more of an evolution and not a revolution in front end dev. If it's better than React, it's marginally better...and that marginal benefit is offset by the massive ecosystem and developer mindshare that React has accrued over the years.

NPM stats are not representative at all because for every big project there are tons of NPM downloads. For every branch, every deploy, every pull request. This grows exponentially.

Just like Github stars arent representative because only (active) Github users would add a star and when a project has critical mass, the amount of actual users will no longer correlate to the amount of stars.

Anyway, I don't think there is a good way to measure usage or popularity of these frameworks. Maybe Google Trends or stackoverflow tags? I don't know really.

Google trends are particularly difficult for this case because angular (the library) is not a "topic" there. React however is, though.

Stackoverflow tags comparison here: http://imgur.com/a/O3mSB

The tool used is here: http://data.stackexchange.com/stackoverflow/query/201360/que...

I felt happy looking at this. Angular has everything (the complete package of router, speed, and all the components you need), and was surprised why react was more popular

Who's to say 99% of the downloads on npm aren't just from CI servers? Some of my side projects made it to 1000s of downloads when I was the only one using them, on various package managers.

Google trends is more useful.

Having worked for a big company, one of the things that people look for in a framework is a tech giant like Facebook supporting it. One of the reasons why people are shying away from moving to Vue is because that it's completely community driven. Think about Angular's huge initial success - it had the backing of Google

JQuery was authored by one guy. One a technology reaches certain threshold no one cares about its origins as long as it's open source.

i think we all learned that a huge company backing has no bearing to the success of the project.

just ask any ex-angular devs.

Or Adobe Flex..

Or KnockoutJS


What's also important is that Vue 3x'd growth while React 2x'd growth.

I grabbed a point around the middle and one near the end. React: 642K > 1,184K. Vue: 53K > 155K

npm downloads seem to exaggerate how many actual people are downloading packages rather than bots.

A funny pattern that emerges in the above chart is that downloads drop sharply on weekends. I have seen packages that exhibit the opposite pattern (downloads spike on weekends). And this pattern is correlated with popularity, the most popular packages are downloaded largely by 9-5 industry coders, and mostly via continuous integration bots.

I work in a coworking space in Seattle. Most of the startups here use React and a few Angular. Not one, that I know, uses Vue. This is a fairly large coworking space and while I don't know every company's stack, the reach of React is impressive considering it wasn't that long ago that Angular dominated.

A more interesting graph would be one that includes Angular 2+: https://npm-stat.com/charts.html?package=react&package=vue&p...

npm stats are slightly deceptive because Vue is huge in China. In China npm is very slow so most devs use mirrors to download their packages. so the * here is npm doesnt really include China, which is arguably Vue's biggest market.

I've built semi-large applications in both Vue.js and React. I like both but prefer React.

For me Vue.js is like a light-weight Angular 1, in a good way. It's very intuitive and you can start working immediately. It does however easily end up in confusion about where the state lives with the two-way binding. I've run into a lot of implicit state changes wrecking havoc. The declarative nature of React definitely wins here, especially working with stateless functional components. If you're serious about Vue you should adhere to unidirectional bindings, components and use Vuex.

The best thing about Vue.js for me is the single file components. It's such a nice feeling to know that everything affecting a certain component is right before your eyes. That's also the reason I started adapting CSS-in-JS in my React components.

The biggest problem for me with Vue.js is the template DSL. You often think "how do I do this complicated tree render in Vue's template syntax? In JSX I would just use JavaScript". For me, that was the best upgrade going from Angular to React and it feels like a step backwards when using Vue.js.

Vue removed real two-way-binding in 2.0. The v-model you commonly see is just syntax sugar.

Also, here's the obligatory "Vue supports JSX" link: https://medium.com/js-dojo/using-jsx-with-vue-js-846f4fbbf07...

I personally feel that JSX feels a bit "unnatural" compared to Vue's DSL, but that's a matter of opinion. It's always good to have the option :)

Thanks! That's cool and yes, it supports JSX but it's still not a first-class citizen like in React. I don't know the practical implications though since I haven't used so maybe my fear is unfounded.

I have been building web apps for 19+ years. I like many of the frameworks out there but for some reason I HATE React. I think JSX is a huge turnoff for me. I just can't get past html in javascript. It feels wrong.

With that said, there are so many VERY smart people embracing React, so I am always questioning my "hate". Maybe one day I will change my mind.

I haven't use Vue but watched/read about it and seems very cool and simple to use.

For now, my favorite framework by far is Ember JS and it really blows my mind why it is not the most popular framework out there. The amount of stuff you get out of the box and the incredible productivity and happiness it brings to the developer experience is IMPRESSIVE. It will take you 2 weeks of work to make a new React app have the same feature set as an Ember app*

* I could be wrong.

For a long time, people have been saying "separation of concerns" to support the idea of keeping HTML, JavaScript, and CSS in separate files.

The problem with that is that the document, application state, and styling is all highly coupled when dealing with web apps. Web pages which are content based are fine with these being separate, changes to one don't necessarily affect another.

For web pages, the separation of languages is a separation of concerns. However, for web apps, the separation of languages becomes a barrier, since everything about a certain behavior in your program could be in three different languages or more.

React changes this notion with the idea of a component. A component is ideally pure, meaning that it affects itself and it's children, and nothing else in the application. Components are composable, so you can combine multiple components, allowing for very DRY view code.

Idiomatically, React components have elements, styles, and the relevant code in a single file. This keeps things encapsulated and easily maintainable.

Separation of concerns means put your styles in a <style> tag rather than the style attribute of a tag, and behaviour in a <script> tag rather than in an onclick/onhover/whatever on the tag.

Grouping logically related components together makes perfect sense (and this is coming from a backend Rails dev who thinks the rails directory structure is totally wrong as well).

While it didn't start out this way, these days Ember apps lean heavily on components and all of the apps I work on use a pod structure that groups each component into a directory containing a component.js, a template.hbs, and a style.scss file. This maintains the spirit of "components should be self-contained" while not having to define html and css within javascript. Ember has React to thank for the idea, but I prefer Ember's implementation.

Interestingly, I had recently joined a team that was using Ember, and we found that Ember hampered our productivity. We switched to React and was able to rebuild 4 months of Ember work in about 3 weeks of work in React (not sure how many developers were working on the Ember app originally, but it was mainly 2 of us who built the React app), including requisite tests.

I’m of the opinion that Angular is much better than Ember (note: I have 4.5 years of experience in the Angular ecosystem, including in open source), and I think I am overall perhaps more productive with React than Angular, although I feel like there are less issues with state management in Angular, which has been a pita in React. All the libraries/frameworks have various tradeoffs ultimately, so I don’t believe there is a cure all for everyone’s preferences.

A note about JSX - I am not a big fan of it, but I see it more as having tradeoffs like more traditional templating languages, but different ones. I have been a bit resigned that this is the direction the ecosystem has turned towards, so I have personally decided to hold that dislike more loosely and focus on more important architecture issues. It does little good to let dislike over style paper over higher level issues if you can help it IMO. I don’t think we’ll ever see a perfect template language.

A rewrite is always going to take less time to build than the original poorly-specified version when people were trying to figure out what to do.

And the original team could have been more junior, or if similarly-experienced than your 2-person team, adding more people to the team without good leadership can also affect productivity---or as they say in Scrum, "velocity".

Very well put. This has helped me crystallize my own opinions about react.

There's something very unlikeable (to me) about basic things like a router not being in the library (or should I say framework) I'm choosing.

I like the way how you articulate your thoughts about keeping dislikes aside and focusing on architectural issues more.

Regarding state management, have you tried MobX? It makes state management almost ridiculously simple. I've noticed a slight performance hit using it for deriving values for 60fps animations on React Natuve but in normal usage you'd never notice.

I worked with Ember for a few months and I like it a lot - it definitely deserves more recognition. One thing that frustrated me a lot in Ember was the run loop. The docs suggest that you don't have to worry about the run loop at all and its merely an implementation detail, yet we had to constantly us Ember.run, Ember.run.schedule, etc. all over the app. But of course in order to know which Ember.run methods to use, you end up diving deeply into the implementation details of the framework itself.

> It will take you 2 weeks of work to make a new React app have the same feature set as an Ember app

You're probably right about this. But it's not always the whole story - maintain and grow your app for a year, and you may find your experience shifts dramatically.

Disclaimer: I haven't used Ember for anything but the tutorial, and I hear it's pretty good these days.

Thanks for the Vue bestpractices!

For newcomers like me, I've found these videos very useful: https://laracasts.com/series/learn-vue-2-step-by-step

Extra tips:

* use axios to transfer data, no need for jQuery

* when you find yourself reaching for jQuery to change DOM, eg add/remove a class, think again. v-if depending on component state data variables worked well for me.

* after trying several authentication libraries, found it simpler to build my own layer, storing user state in Vuex

Anybody has more tips to share? Something you wish you knew earlier?

working anything with loops and conditionals, Vue is way nicer than JSX all the way around, especially the more complex it gets with *-level nested json data trying to mix in with conditional portions of the view, and even saving reactive data back the scope of the loop, etc. i'm not sure why you'd think otherwise. JSX code with many loops and conditionals can start look incredibly ugly pretty fast. if you can provide an example, we can compare between the two to see which is nicer.

I have a JSX example. It isn't React, but it's Mithril which is similar: https://github.com/brlewis/brlewis.github.io/blob/master/201...

Blog post accompanying said example: https://medium.com/front-end-hacking/how-it-feels-to-learn-j...

I'd be interested to see the equivalent vue.

Maybe it's just me but I've struggled a lot with especially Angular's template syntax.

Would love to see a side-by-side comparison of complex nested data structures in Vue and React.

I've been in this gig for years upon years and I still don't see what's terrible about two way binding.

Can someone actually justify it without handwaving statements like "you'll notice at scale", or red herrings like "Angular is slow"?

Side effects and testability. Two way binding is great for simple forms, if you have like a dozen or so variables on a page? Two way binding is awesome and allows you to write very terse code and logic.

If you start adding dynamic forms, multiple developers, unit tests, and advanced interactive application logic, then you are left with a spaghetti code mess (with 2-way binding). The problems really creep up when you start adding observables or watchers, which watch a particular variable for changes. If you two way bind a UI element with a controller variable, and then have watchers or observables on that variable...it is now no longer clear what side effects you're triggering as your interacting with that UI element. Wonky things can and will happen to you as your app's complexity grows.

> If you two way bind a UI element with a controller variable, and then have watchers or observables on that variable...it is now no longer clear what side effects you're triggering as your interacting with that UI element.

I've heard this argument before, and I really don't get it.

Let's say I have an input bound to a model variable. What does that mean? Well, the model is the single source of truth of state. And the user can change it. Sometimes we have derived state, like computeds in Knockout. These are read-only and are not ultimately sources of truth (though they will never contradict non-derived values).

In this model, I cannot see what is wrong. Why do you need to reason about the side effects your input triggered? Your input should be bound to something that is a fundamental, atomic, irreducible element of the app state. When it changes, the app changes. You never need to reason about this happening because there should never be a moment where a model changes and the app does not.

Excuse me for my naïveté, but it looks to me like two way binding can only cause problems if you are binding inputs to derived values, or if your model is not truly irreducible. In which case, you are knackered before you start: how is your app ever supposed to guarantee consistency of state?

If you are writing Angular or Knockout code properly, in my opinion, the data flow should be unidirectional just by dint of using an irreducible model and never manually overwriting a derived value.

Just because the template has a two way binding to a model does not mean the data flow is pandirectional. Likewise, one way binding does not guarantee unidrectionality: I am fairly sure you could write a React-Flux app where components emit arbitrary actions in response to state changes. Perhaps this is banned in Redux, though.

Input Field <-> Controller/ViewModel field two way data bindings are fine when they are kept simple, as I said in my comment. Two way binding is great for simple web form apps. If all you're doing is pairing a Name input field with a name variable on your controller or viewmodel, you're golden.

But having worked on complex dynamic form generators and enterprise apps at scale, I've seen the mess that KO observables and Angular $scope watchers create in practice.

Neither KO nor AngularJS actively encourage great patterns for data flow in their architecture design. It becomes all too easy, in some deeply nested directive or KO observable, to reference external/parent context or scope. React was specifically opinionated about this because Facebook hit real problems in production with two way binding.

Another benefit of one-way flow is that it becomes trivial to refactor your UI into modular components. Because the data flows in a top down manner passed in as props, it's easy to break up a complex component into several sub components.

React encourages you to fall into the "pit of success" by its design and there's very few traps.

I recommend taking a look at how Angular 2+ does it - the Angular team originally intentionally omitted it, but they found a way to make it work in a technically sound fashion (output changes being evented).

The side-effects problem was certainly true with Angular.js - it is not true with Angular.

Angular2+ is an improvement, no doubt, and the eventing based system is not unlike React's in that sense. Although it does require you to instantiate an EventEmitter which is somewhat arbitrary. Still, it's a better data flow model overall for sure.

It's pretty much an issue of getting to a "stable" state, which means that model stabilizes to a certain value after all the actions by user and code. That can be a problem with 2way binding and sometimes it causes very subtle bugs, but it boils down to the infamous event storm. So that's why they gave up on 2way binding and made it more optional and deliberate

I honestly don't remember since I don't use two-way binding anymore but the last problem I had was something with copying one person in a list of people with inputs from one place on the page to another and things got really messy. Sorry, don't remember the details. :/

The problem with two-way binding is that people use more than one source of truth and blame that questionable (to not use stronger words) decision on the framework.

At least that's what I've seen it come down to.

I love single file components. I used Polymer before React and that is the thing I miss the most. I've also been using CSS-in-JS for the same reason. I landed on JSS for now, but I'm hoping we'll see a solid scoped CSS solution soon.

I'm still to be totally convinced by single page components, the idea of mixing languages within a file just doesn't feel right.

I think I'd prefer to have a component directory with HTML, JS/TS and CSS/SCSS files in.

Doesn't that depend on pipeline? I've been doing for polymer components with html css and js split into separate files. They get concatenated into single file in build process.

Not by default as far as I know. There's more info here, it's doable but not pretty.


The last example looks normal to me?

I've been very impressed with styled-components - it's outstanding. Inline, scoped, fully native CSS.

If you're using vscode add plugin "Template literal editor" and you get full intellisense on the CSS too!

Very Nice summary

> I've built semi-large applications in both Vue.js and React. I like both but prefer React.

> If you're serious about Vue you should adhere to unidirectional bindings, components and use Vuex.

> The best thing about Vue.js for me is the single file components. It's such a nice feeling to know that everything affecting a certain component is right before your eyes.

>The biggest problem for me with Vue.js is the template DSL. You end up with the "how do I do this complicated tree render in Vue's template syntax?

In this thread people are fighting about their _opinions_ why they use Vue.js or React. And why X is really better than Y.

In reality these programmers don't want to have the feeling they might have made the wrong choice when they used X instead of Y. The idea that they might have taken the poorer choice hurts so much that they need to defend their decision so heavily while in reality taking ReactJS or Vue.js is like ordering pizza or pasta. You usually don't want to have both at the same time. So you need to explain why pizza is better than pasta tonight. Only that you usually have to stick longer around with Vue.js or ReactJS once chosen. Enjoy your choice and solve real problems, but stop fighting about it, programmers. Pasta and pizza will always both win.

This should be the top comment. This sort of "debate" has happened since the dawn of programming and will continue to happen until AI programs for us.

The reality is it is all shite! Just get your job done.

You can't compare react and vue with pizza and pasta. Pizza and pasta are two finished products, while react and vue are two different ways of building the same product. Your comparison doesn't make sense at all to me.

If you imagine pizza and pasta as ways to get satisfied, then you can consider your final satisfaction as the finished products.

Whether you choose pizza or pasta depends on your personal taste. And maybe on your skillset, if you need to prepare the food. Both lead to mostly the same outcome – your satisfaction.

Whether you choose React JS or Vue.JS also depend on your personal taste and skills. Both lead to a finished product.

Say you're about to cook pizza or pasta, you use flour and tomato for both. Comparison not 100% off IMO.

No. 1000 times no. For the pizza base you use flour, water, salt and yeast. For fresh pasta most of the time you use flour and eggs. The process moreover is completely different. You NEVER use tomato for making the fresh pasta or the pizza base. You may use tomato as a condiment for pasta and pizza. This comparison is even more wrong than comparing apples and oranges. But I expect that unlike me you never cooked pizza and fresh pasta if you can't see the obvious difference.

In fact I'm a seasoned pizza cook but pasta is still a pending subject of mine.

In fact I'm a seasoned pizza

I completely misunderstood your comment. I might need to go get food soon.

To me the whole idea of client-side HTML templates seems bad. They start out easy enough, but then they either limit you in power or introduce new and weird concepts to replace things that are easy, familiar and often better designed in the host language.

Here is an example on which I'd love to be proven wrong:


Its a generic spinner component that waits on a promise then passes off the fetched data to any other custom jsx. It can also take onFulfill and onReject handlers to run code when the promise resolves.

The concrete example shown in the fiddle renders a select list with the options received after waiting for a response from the "server". An onFulfill handler pre-selects the first option once data arrives. The observable selected item is also used from outside the spinner component.

With React+mobx and JSX its all simple functions/closures (some of them returning jsx), lexical scope and components. With Vue I'm not sure where to start - I assume I would need to register a custom component for the inner content and use slots?

Here is an example of that code implemented in Vue.


I really haven't run into anything I could do in React that I couldn't do in Vue. What I mainly miss in Vue is react-native.

Great, here are my thoughts on it

1. Render methods make vue basically the same as React plus MobX, right? (and afaik you can use JSX too)

2. The spinner component was registered in the global scope. Will normal build tools know about the file and properly include it, or an import will need to be placed somewhere for that to work? What happens if another module registers a "spinner" component? ES6 and CommonJS modules have already solved this elegantly, and I believe its a must for larger scale applications that may consist of multiple complex modules

3. I see many wheels being reinvented, and as a non-vue user I have no idea what they mean. For example, does `<template scope="data">` name the first argument passed to the function? Is `default` the name of the first unnamed template? And this page is utterly baffling: https://vuejs.org/v2/guide/components.html#Scoped-Slots as I cannot figure out which thing is the template that is being passed arguments and which is doing the passing (and how).

edit: re (3) I finally got it, a `template`'s `scope` gives the props passed to a `slot` a name.

It seems to me that templates look like less learning initially, but they end up being more...

1. The MobX-like functionality is moreso simply a native feature of Vue. All data values are converted into observed values. A render is triggered by changes to data. I believe Evan himself basically said React + MobX = Vue. Using a render function was just a choice. It could just as easily have been written with a template.

2. Again, this was basically just a choice for the example. The spinner could be defined in a module and imported/registered locally. Codepen/JSFiddle just isn't the greatest place for that kind of example.

3. Scoped slots are a way for a component to expose internal data to elements contained in a slot (content thats contained within the component but defined by it's parent). I agree, its initially one of the more confusing concepts in Vue.

Ok I think I figured out how to use a template with a slot in the spinner component:

    <img v-if="this.status == 'pending'" 
         src="https://media.giphy.com/media/10kTz4r3ishQwU/giphy.gif" />
    <slot v-if="this.status == 'success'" :list="this.data"></slot>
    <div v-if="this.status == 'error'">{{this.error}}</div>
Then in the template the option line becomes

    <option v-for="option in data.list" :value="option">{{option}}</option>
Not too bad. Guess I'll have to come up with a new example of what Vue templates can't do now!

You nailed it :) You could also destructure the passed properties in the scoped slot (scope="{list}") so you could just use "option in list".

I wonder if the JS snippets in those attributes is syntax checked at build time or run time.

Vue templates are compiled into render functions. They are checked when the template is compiled. If you are using a build process, then that would be at build time.

Is there any editor support for that? One of the things I like about React + TypeScript is that the JSX is syntax-checked and type-checked in my editor as I type. My understanding is that this is possible because TS has built-in support for JSX.

Not yet as far as I know.

    or introduce new and weird concepts to replace things that
    are easy, familiar and often better designed in the host
Oddly, that's exactly how I feel about the "{condition_expression && template_evaluation}" idiom in JSX.

Personally I prefer the ternary operator in those cases, however I think do expressions will fix most of the if/else awkward stuff: https://babeljs.io/docs/plugins/transform-do-expressions/

I'll use a ternary if I want something in the "else" case, but otherwise the `&&` / `||` approach is more readable to me (there's more to read in a ternary to figure out that there's nothing happening in the else case, whereas it's obvious with the boolean approach without reading further).

Can that actually help react look better here? I'm currently imagining:

  { do {
    if (condition_expression) {

For a single expression some of it can be omitted:

  { do { if (condition_expression) template_evaluation }}
But I gues thats not really better.

I'm hoping jsx will eventually default to `do` expressions though, and then it becomes

  { if (conditional_expression) template_evaluation }

Hmmm, I really like the terseness and obviousness of that approach, I use it all the time :)

I have sometimes been caught out by doing `{somearray.length && thing}` though, which leaves `0` hanging out there in the false case...

I used React for a few years and it was great and powerful, there were many things however that I disliked.. Particularly I was not a fan of JSX. I liked React but I did not feel comfortable using it.

When I first saw VueJS I had a hard time understanding how it would be any better than React, that is until I saw single file components.


I fell in love with the eloquence of being able to separate my HTML, JS, Styles for a single component.. it seemed /right/ to me..

In any case, I've been using VueJS ever since for my new projects moving forward and I'm very happy with it. It has everything I would ever need from React but in what I feel is a more polished and thought-out way.

Just my two cents :)

Completely agree! Single-file components are more natural to how I think about the web.

It's worth noting that Vue also supports render functions with JSX (https://vuejs.org/v2/guide/render-function.html).

One of the reasons I moved to vue was the template section allowed normal html. Saved me so much time styling.

I do like jsx for simple things but always felt it bogged down the design piece having to convert even if its just the class to className

> I used React for a few years and it was great and powerful, there were many things however that I disliked.. Particularly I was not a fan of JSX.

JSX is no more than sugar for vdom function calls. You can use React without JSX, and you can use Vue with JSX.

> When I first saw VueJS I had a hard time understanding how it would be any better than React, that is until I saw single file components.

> I fell in love with the eloquence of being able to separate my HTML, JS, Styles for a single component.. it seemed /right/ to me..

You… can do that just fine in React? The logic and "template" are in the same file in the first place, and there are solutions like styled-components, csjs or react-styl if you also want the JS.

Everytime the discussion of React vs. VueJS comes out, there are always people that make the argument that you can make React do everything VueJS can.

Of course you can, these are open sourced projects and you can modify and add packages to do just about anything you want it to do.

However, when presented with an option that is designed from the ground up to work exactly the way you like it, why not use it?

I can install a dozen different packages along with React so that I can get it set up exactly how I want, or I can just use VueJS whose creator's philosophy are more inline with my own and is designed exactly how I like my front-end.

I've used both. What makes me pick Vue in the end is the fact that there is no compiler needed, no jsx and all the non-sense that goes with that.

If you want a full blown huge application to last years, then go Angular... Although who knows if Angular will be there in 5 or so years.

There is no perfect library/framework but I love Vue because Vue does exactly what it says on the tin.

> If you want a full blown huge application to last years, then go Angular.

After what they did with Angular 1 -> 2 not a chance.

At least with Vue you can swap it out a lot more easily if it does go away in 3 years.

Right now a great option with "forward-compatible" applications would be to go Polymer.

I saw a talk on Polymer about 2 years ago where it was the next big thing, here we are two years later and it doesn't seem to have progressed at all - I do get that it is the future I just don't think it's one that's quite ready yet.

The update from Polymer 1 (Web Components v0) to Polymer 2 (Web Components v1) was huge for both code simplicity and performance. I know that my huge hangup with Polymer was performance, but it was solved (mostly) by Polymer 2 (released last May.) I'd give it a second look, especially now that most of the major pieces of Web Components v1 are shipping natively in browsers.

On the other hand, a lighter Web Components library I've been looking at has been Xtag.

Does it make that much of a difference? My applications are still on 1.x, I did migrate my components to hybrid though. One other interesting libraries to look at are svelte or skatejs - haven't used them personally yet.

I haven't used either extensively so take it with a grain of salt, but my anecdotal experience is that Polymer v1 at release vs. Polymer v2 in the latest Chrome is a massive world of difference.

I also think v2's switch to ES2015 classes instead of v1's prototypal inheritance is much better and cleaner, but that's more of a product of Web Components v0 vs. v1. :)

You mean it hasn't catch on with the community or it hasn't progressed as a technology?

The former, no idea on the latter.

I tend not to pay serious attention to technologies until they are popular and have been used for a while (I always adopt on the back side of the hype/productivity curve, since I'm not completely a front end developer).

Yeah, certainly it doesn't seem to get love here on HN.

However now https://www.webcomponents.org/elements has over 1k elements and Polymer slack channel is over 8k users, the community is active and there are lots of enterprise users adopting it (Netflix, IBM, GE, EA - not only Google).

IMO while that is not bad at all, react is obviously more popular, but when we talk about hype driven development - VueJS is one man project as you can see on GH, 99% of code is by single contributor - but based on hype you would feel safe adopting it.

Not sure I would tbh, I've been looking at Vue for the last 6 months as a replacement for Knockout and I still haven't bit the bullet, going to have to soon though because I need to give the frontend at work a good kicking and I have to pick something, thanks for the info on Polymer.

A lot really depends on your tastes, I didn't like react and I have to work with it daily. I like Polymer and what I saw in Vue docs, but at same time Vue is one man project really so that was the main reason I did not go with Vue - I might try it for my next project just for fun.

I think you should just do a tutorial in them and pick what fits your brain.

I understand DOM and elements so Polymer it was natural pick for me, also interoperability with other frameworks/libraries was important factor, they want to be the jquery of webcomponents basicly. I made my bet on a solution that is baked in inside the browser, since webcomponents are W3C standard, and polymer is really small (20kb), it won't suddenly stop working for me the same as jquery work for billions of people.

No application lasts "years" nowadays, so I'd suggest not go "go Angular" simply because it's Angular. The modularity and speed-to-productivity of Vue is the reason I choose it. Plus, the community is quite supportive; always nice.

I work near, but not directly on, an application that's lasted about 20 years so far. It's still actively maintained, and still making money. It's mostly written in vb6 and classic asp. Yes. Some applications far outside the hype cycle can last decades.

I've been working on a large web app (SaaS, so you won't have heard of it and can't try it out) for the past 5 years, and it's one continuous history codebase using Backbone for UI. It's not going to get rewritten any time soon. I'd expect it to still be using Backbone or something very similar (perhaps switching out some rendering subtrees for Vue or React) in another 5 years.

React has multiple alternatives to JSX too.

I would also add that language additions like TypeScript are not REQUIRED, but one can use them without any additional tech stack concerns in their build pipeline. In other words, things that React and Angular suggest (almost seem to require, given that documentation is written for them) as tech stack recommendations are entirely left to your initiative.

I've never seen a SPA last "years" without some eventual rewrite or major change. The only sites I see last year are serveres rendered ones or very simple ones.

You probably don't see them because complex web UIs aren't always consumer-facing. The ones you're familiar with are probably maintained by large corporations rather than specialist companies, and can more easily afford rewrites.

> What makes me pick Vue in the end is the fact that there is no compiler needed

Why are then Vue components written in .vue files and compiled to Javascript then? ;)

You don't have to use .vue files to actually write Vue[1].

.vue files are there for simple single file components[2].

[1]: https://jsfiddle.net/yyx990803/y91wy85p/?utm_source=website&...

[2]: https://vuejs.org/v2/guide/single-file-components.html

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