Hacker News new | comments | show | ask | jobs | submit login
Comparison with Other Frameworks (vuejs.org)
256 points by wanderer42 on Oct 22, 2016 | hide | past | web | favorite | 147 comments

It says they tried not to be biased, but it doesn't look like they tried at all. Apparently every design decision made in Vue is superior. This isn't a fair comparison and shouldn't try to masquerade as such, it would be fine if it was positioned as an opinion piece on why we think Vue's approach is better instead of a "perfect framework" ad it is.

But after using JSX I'm never going back to a templating system. JSX has an intuitive direct mapping to JS that lets you use the full power of a programming language without needing to learn another crippled DSL syntax.

If you've never used React before after reading this you could be forgiven for thinking it's a complex monstrosity needing a week of prep to build a HelloWorld app which is a biased gross over exaggeration. React has one core concept, Components, which is easier to create, encapsulate and reuse better than anything else I've seen. I also believe in React's being able to use JS for Views, Style and Behavior making it easier to encapsulate cohesive Components.

I consider Ecosystem, community, dev resources / backing, encapsulation and reuse integral for adopting a framework which React wins easily on but is quickly disregarded here.

Whislt this is a biased guide Vue has convinced me enough to evaluate it, I'm especially interested in its performance and being able to reference it like a jQuery script tag which I believe is the biggest shortcoming of modern JS fxs which has succumbed to npm micro module madness inflicting complexity and friction on all developers which is IMO the major source of complexity when adopting a modern fx.

I like that Vue seems to be carrying Angular1's torch of "make it easy for non-programmers to write templates" but I feel like that has been an illusory strawman from the start.

Not only does it mask the fact that the supposed non-programmer template designer would still have to understand HTML and CSS yet somehow not have even the most basic knowledge of JS, but they would still have to be able to use whatever build tools are necessary to actually render those templates, including version control and node.js (which is the de facto platform for client-side build tools these days). The target audience seem to be old-school "webmasters" who FTP their PHP templates to the live server yet we're talking about technologies requiring a workflow that already precludes them.

So we're talking about a scenario that only benefits people who already tick all the boxes for "front-end developer" except they apparently suffer from a nervous breakdown if they have to look at an if-block or understand a for-loop yet they'll be fine learning another template language that is typically based on JS expressions anyway (though Angular was guiltier of this than Vue).

Maybe these people exist. Maybe there are teams where optimizing technical decisions for these people results in a net benefit. But I strongly doubt that this scenario is so widely applicable that this design decision makes a framework inherently superior when the cost of JSX to a team of JS devs is practically nil.

I am that person. Coming from an electrical engineering/Low Level programming background

HTML is a Markup language. I get those.

CSS is stylesheets and in my opinion very straightforward. The hard part is making designs that are functional and beautiful and making it cross browser compatible, but CSS has very few warts if the "wtf" variety

JavaScript and it's ecosystem is disgusting for me. It's not hard, I can write stuff in it, it's ugly. I just don't want to touch it if I can avoid it. Pure personal preference. Typescript and elm help me to minimise the work I have to do in that mindspace. Maybe vue aims at similar clientele with less taste for statically typed/functional programming

You admit you understand it and it's just a personal preference. Therefore you're not that person.

The stated goal of making templating accessible to programmers isn't to shield people who don't like JS, it's to shield non-programmers who don't understand programming languages. This is the absurdity I'm arguing against.

If it was just about making JS look different, there would be no need to use Vue in the first place.

I thought the point also was not to mix the programming language in with the display logic, which was done a lot with PHP in the past, resulting in messy applications.

Yeah, and that idea was always pretty stupid. They'd create some some new, terribly ugly, syntax. Maybe at first functions were limited, nut inevitably, they'd add connectors for every function in the "host" language (php/js/...). Or just something generic, allowing you to do something like <this-is-definately-not-a-programming-language native="Kernel.exec('sudo rm -rf /'"/>.

OF course it meant you had to learn a new language, even though you were perfectly capable of perfectly suitable language already. But at least designers didn't have to learn "programming".

There's no way around this. Templates need logic, mostly for loops (or maps, same difference), or dynamic formatting.

Templates need some level of logic, yes. Putting the entirety of the business logic in your templates is not only bad, but dangerous. Because unless you're replicating your business logic in your non-template code, I can change things in the DOM, and potentially corrupt the system.

Unless I completely miss the boat about how Angular/React/Vue/etc are supposed to be used. I only know from my previous years of seeing it done in the way I mentioned above, and every time, the work always ended up duplicated in the non-template code.

What's your definition of business logic?

  > "make it easy for non-programmers to write templates"
  > I feel like that has been an illusory strawman from the start.
You're right, the nonprogramming web designer may be a rare bird. Even if they exist, they don't exist long. I have always believed that someone can pick up the rudiments of programming in a couple of weeks. Someone who starts out writing HTML and CSS will eventually rub up against JavaScript. In time they will incorporate a snippet of JavaScript here and there. First it will be mindlessly pasted from the Internet. But after reading enough blogs, they will be bundling React and adhering to the functional programming paradigm to load their own blogs. Come to think of it, I wish there were more people who knew just HTML and CSS.

More seriously, I myself know HTML, CSS, and a few programming languages, but unless the page is very simple I still like to separate things into template files. I prefer Handlebars, but often I just use PHP's alternative syntax.

  > apparently suffer from a nervous breakdown if they have to look at
  > an if-block or understand a for-loop
Well, if-blocks and for-loops are the two main pieces of logic I think every template syntax must have. Mustache said it wrong. Templates should not be "logicless." Templates should be "processingless": they should not have side effects or further manipulate the data. This is okay:

  {{#if items}}
      {{#each items}}
          <li><a href="{{url}}">{{name}}</a>: {{description}}</li>
This is less nice:

  <p>Any items you have will be listed below:</p>
  <? $q = pg_query('select * from items') ?>
  <? if (0 !== pg_num_rows($q): ?>
      <? while ($item = pg_fetch_assoc($q)): ?>
          <? if (userCanSeeItem($_SESSION['username'], $item['id'])): ?>
              <a href="<?= h($item['url']) ?>"><?= h($item['name']) ?></a>:
              <?= h(ucfirst($item['description'])) ?>
          <? endif ?>
      <? endwhile ?>
  <? else: ?>
  <? endif ?>
The problem is not ifs and loops nor the use of raw PHP, with its alternative syntax. The problem is the database calls (pg_query), controller-esque function calls (userCanSeeItem) and text clean-up (ucfirst). This kind of stuff should be hidden inside a model-esque function (getItemsOfUser($username)) which returns a ready-to-print associative array.

I use templates not because I'm scared of all that. Instead it's sort of like the recently re-loved functional programming paradigm. Template files should have no side effects. I know that once I stuff the data into a template, then nothing else will happen besides output to the user's screen.

> I know that once I stuff the data into a template, then nothing else will happen besides output to the user's screen.

Exactly. It's that WTF moment of having database and HTTP queries spring from unexpected locations that you are trying to avoid.

Vue's single-file components (html, js, and scoped css) are super-appealing to me.

The message is something like: "These concepts you understand and use all the time? We aren't going to make you abstract them away. We're going to use them as the foundation for a new way to build apps."

You're not the only one who finds JS and its ecosystem disgusting.

> Maybe these people exist. Maybe there are teams where optimizing technical decisions for these people results in a net benefit.

I've seen this reflected strongly in large companies on the east coast. Design staff is expected to know HTML/CSS, but aren't exepected to have more than a cursory understanding of javascript.

Design will often start with HTMl prototypes, then do a handoff to engineering who will using a JS framework to wire it into the real app.

Lately, though companies are swithcing to React, because JSX seems similar enough to HTML that people presume that design staff will be able to understand it.

I'm in a startup using Angular for some of our stuff and we get the same benefit. Our primary design guy is able to create pages before devs wire them up, and make a lot of the UI changes directly himself without our help.

I hear you. JSX sounds like the wrong thing to me, as well.

(but I'm also working on a long Angular 1 project at my job, so I "may" be biased)

I REALLY like that Angular 1 allows you to simply make a mockup, then add the "programming stuff" behind the scenes. WITHOUT an enormous build chain (I have enough of that on the server side already, and the server is not Node for historical reasons - I'm not sure about node yet, and even if I wanted it, that just won't fly in my group)

I'm not done yet, but I'm doing a presentation on this in December at one of the local user groups: https://github.com/roboprog/ang-prog-enh

I've had the misfortune to work with a Java developer who insisted he didn't know JavaScript and therefore wouldn't ever touch JavaScript code even if it would have saved everyone a ton of time. Yet at the same time the Java code would often generate HTML or even JS code directly.

There are companies with stupid silos like this, but for the reasons I laid out I doubt they actually benefit from the "toy-language templates" approach -- even in the aforementioned company the non-developer designers would implement the entire layout as a mockup in HTML and then toss it over to a frontend dev who would cut it up and add the actual template logic (because although the template language was "easy" non-programmers couldn't be "trusted" to get the logic right).

How do you mean, "templates for non-programmers"?

I see Angular's directives as a pure convenience compared to most every templating engine I've used across languages, never considered it something that makes it accessible to non-programmers. I'd actually think someone who only knows html/css would be more thrown off from a page with random, unsanctioned (by W3C), tags and attributes that may or may not reveal what they actually do.

As a programmer I don't want to write long templates, I seriously prefer Jade/Pug for that reason. When I can't use them for a client I typically use them to do all initial work, compile them to HTML, then make whatever minor changes from there.

Consider ng-for:

  <div data-ng-for="y in x">
The ASP.Net solution is a pain, a function with HTML string template to dynamically add elements to a "runat" div.

This PHP example seems more idiomatic, at least to me, yet takes more to write

  <?php foreach($x as $y){ ?>
    <h1> <? echo $y->title; ?> </h1>
  <? } ?>
The JSP style is kinda similar to Angular, again maybe more idiomatic at first glance but still not as quick/simple to write

  <c:forEach items="${x}" var="y">

The jQuery/plain JS solution, especially before ES6 is not preferable by any means, especially beyond this simple example.

  var body = document.getElementsByTagName("body")[0];

  body.innerHTML += 

Unlike all the other solutions, angular has 2 way data binding so when you programmatically add elements to the array in ng-for, they are added to the DOM without a reload.

So, is the goal of a programmer to simply write more code? If so, then Angular is definitely not for programmers.

Is the goal of a programmer to solve problems? If so, Angular is definitely a tool for programmers.


    {x.map((y) => (
      <div key={y.id}>
Aside from the HTML-like syntax this is vanilla JS. And "y.title" is already auto-sanitized so you don't have the XSS vulnerability as in your jQuery solution.

Need to output trusted HTML?

    <h1 dangerouslySetInnerHTML={{__html: y.titleHtml}} />
Yes, that's intentionally verbose, making you aware that this is a potentially dangerous. But to paraphrase the old saying: make the safe things easy and the unsafe things possible.

Angular and friends require context switching. Good luck if you're using non-standard data structures or need slightly more complex filter or iteration logic. And especially in Angular (1 more than 2) you also need to keep in mind the variable scope within the DOM tree and which variables, directives and components you can use where.

With JSX it's just JavaScript and the scope is just your local JavaScript scope. Instead of having to remember all the idiosyncracies of the framework's own implementation of a for-loop[0] you just have to know JS.

I'm not saying Angular is not for programmers. I'm saying the design goal of Angular1 was to make it easier for non-programmers to write views/templates. It's even in the name: as much fun as controllers, components, directives and two-way bindings may be, the raison d'etre of AngularJS resides between the angle brackets.

[0]: https://angular.io/docs/ts/latest/api/common/index/NgFor-dir...

    <h1> <? echo $y->title; ?> </h1>
You forgot htmlspecialchars and now you have XSS. Which is why facebook built XHP originally:


Could've sanatized the input before saving it to the database :p

PHP also offers a nice way to write templates without even having to use echo and without braces:

  <?php foreach($x as $y): ?>
  <h1><?= $y->title ?></h1>
  <?php endforeach; ?>

Yes, that's what I do. I also think it's fine to use omit trailing semicolons and to use short-open tags (I already labelled the file .php --- why do I have to keep saying "php" all over it? And I'm not usually outputting XML.)

  <? foreach($x as $y): ?>
      <h1><?= h($y->title) ?></h1>
  <? endforeach ?>
You just want to make sure to escape all output with htmlspecialchars, or define a shorter function like I did ("h").

I agree!

PHP can only be used serverside, no? Can't write single page apps.

You can't do SPAs with ajax calls?

Huh? I'm asking how with PHP. You would write a 100% client side app.

You can't use JSP to make a SPA, either. I was replying to the statement "Angular is for n00bz"

Unrelated question: was there a reason you swapped the iterator and container (x and y) in your angular example compared to the others? Just to keep 'x' before 'y'? It confused me a bit.

No, I wrote it on my phone and didn't double check the angular example. I noticed another little mistake so I'll edit it

I didn't use vue, but https://vuejs.org/guide/syntax.html did not look so complicated.

But you are right, i am not sure to use a template system again. But the advantage is cleaner code, many people change quickly to spaghetti code in jsx (mix all together, ifs, loops, ...).

Spaghetti code refers to poor coupling not cohesive encapsulation or being able to build complex smart views which can easily be refactored using native programming language constructs. I'd much prefer having a single powerful language for everything instead of forced artificial friction on having to spread your component over multiple DSLs.

> being able to build complex smart views which can easily be refactored using native programming language constructs

For the record, JavaScript can not be easily refactored, since it's a scripting language with no strong types and no compilation phase, so to conduct a complex refactoring you will have to load all code base in you head and that's far from being easily. TypeScript for example is another matter.

That's what regression tests are for.

Also, no amount of compiling or strong typing is a sufficient alternative to regression testing when it comes to refactoring.

> That's what regression tests are for.

Don't loose the point, I was written about another thing, not about tests. Every time when fanboys of functional programming (and scripting) are trying to argue that functional programming is a silver bullet they do write about tests, it's not an argument, tests are exists for any kind code no matter the code nature. Tests won't help you a lot with code analyzing, automatic refactoring and tracking down from where things came (coupling). In case of scripting (and functional programming) you will have to load all the code base in you head and only then you will be able to make some architectural decisions or perform a complex refactoring. Tests just help you to not break the system logic doing refactoring, that's it.

> Also, no amount of compiling or strong typing is a sufficient alternative to regression testing when it comes to refactoring.

No one was saying that compiling or strong typing is alternative to regression testing, don't know where you have got that idea.

Regression tests can automate refactoring steps???

"But after using JSX I'm never going back to a templating system"

It looks like you can use JSX with Vue: checkout the code for the benchmark mentioned in the article:


> I consider Ecosystem, community, dev resources / backing, encapsulation and reuse integral

Yes. No doubt.

> which React wins easily

I disagree. The old react docs were shite compared to Vue's. Not once did I feel the need to ask google. (Have yet to go through the ones released yesterday)

The tools that the team provides (router, vuex, resource, cli, ..) work perfectly.

Where react clearly wins is with 3rd party libraries and learning resources. Egghead is a perfect example.

Depending on what you prefer one might win over the other, but it's not _clear_ by any means.

It's totally fine to pick one, learn it, and never think about the other. One way is the old way, one way is new. Simple as that. There's never a case where you should use both.

Of course they think the design decisions are superior, since they made them after looking at all the existing options. It seems reasonably balanced to me.

In React, everything is Just JavaScript, which sounds very simple and elegant - until you dig deeper. The unfortunate reality is that reinventing HTML and CSS within JavaScript can cause a lot of pain.

So what's the pain for me, as a user of React? It's just embedded HTML for me. They never go on to explain why.


Instead, we offer templates as a simpler alternative:

<template> <div class="list-container"> <ul v-if="items.length"> <li v-for="item in items"> {{ item.name }} </li> </ul> <p v-else>No items found.</p> </div> </template>

Notice how the templates are code in strings. I don't find that simpler at all. I find code in strings to be an anti-pattern. I already have a nice real language (TypeScript in my case) to do "templates".

I fiddled with VueJS some weeks back and didn't use the .vue files because I wanted to understand what I was doing and not have a build chain.

After a while it felt like I was writing strings in strings in strings. And that was exactly was I was doing. I think JSX is a very sane way of coding after all. I think writing things like

        {childItems.map(x => RenderChild(x)}
is wonderfully clear.

no need for lambda


Maybe, but be aware those are not equivalent (your method will pass extra arguments to RenderChild)

If you're the one designing the map function transformer, then you know about the extra args thing... but otherwise you're right that you have to be careful!

As far html vs jsx goes, i would say its a matter of taste.

But when it comes to css, vue's css are way better than React's alternative by a longshot.

Typescript is fully supported by vuejs, I use both and they don't contradict each other.

> So what's the pain for me, as a user of React? It's just embedded HTML for me. They never go on to explain why.

The build requirement, and all of the tooling and complexity that is required to make that work.

As another reply mentions, its a matter of taste, but for me its the clean seperation between data and presentation. Presentation is generally HTML+CSS. Data and plumbing is JS. This is similar to traditional MVC and works well with mixed dev/designer teams. Dev in JS, design with HTML+CSS. You can liken it to a data API returning data with HTML in it, you now have data and presentation together. Do you want the 2 roles in 1 convenient language? Great, JSX gives you that power. Do you want data and presentation separate, then go with templates.

Your component's logic is all presentation logic. You may want to break it even further but it's not a real separation (you still have logic in your templates via `v-if` and `v-for`, don't you?). Data, in both React and Vue, lives outside the component.

'For' and 'if' are very basic operations which have equivalent CSS constructs and play extremely well with HTML presentation. I'm not saying your wrong, I'm just saying its a total non issue for designing presentations. Without it, you cannot present modern data (JSON).

So whose preventing you from only using the same basic structures when embedding it like JSX, with Javascript? I don't see why learning a different syntax for the templates improves anything you say. The for loop does not look any better/easier just because you slightly change the way you write it, but you now depend on yet another language.

What's preventing me? My preference for a different kind of separation between data and presentation. No one right or wrong here, just a matter of taste :)

  > separation between data and presentation
That makes no sense. Reminder: We were talking about Javascript vs. custom template language - both are programming languages. One more limited than the other, but that is when I asked why you don't just use the same subset of Javascript. Just variables and basic loops, for example. You have the exact same things in the template language!

String templates (angular, vue, riot, aurelia, ember, etc) try to be close to the WEB component standard. I find them horrible, because I too use typescript and 1) you have to learn a template sub-language (angular is the worst in that regard) and all your component wiring can't be typed.

Well, I know Vue and Ember are no longer using string based template. Most front end nowadays are DOM based templates.

Even angular 2 uses some sort of virtual dom under the hood. My point remains though, as all the developer manipulates are strings. I think manipulating objects (virtual dom nodes) is a more powerful and versatile way to do it.

Handlebars is not valid HTML, so I find it hard to believe it is DOM based. I believe the new version of Glimmer compiles its strings to bytecode.

I think the way vue components are composed is perfectly suited for everyone that comes into the frontend story right now.

There is no syntax to learn, except that you can have v-if and v-for in your html elements. A style block contains your CSS like you're used to, plus it can be scoped to a component. A script block contains a bit of local logic and event handlers.

Component = <template> + <script> + <style>. Give it a name with the .vue extension. Now you can use it like a custom HTML tag.

(If you really want JSX you can use it, too. Personally I'm migrating back from JSX to the above way of composing things)

Once you reach a certain complexity threshold in your app, you'll read how others solve this with a "flux architecture", include vuex in a few hours, and have these issues sorted out without hassle or nitpicking dozens of tiny libraries.

Need more "pages"? vue-router is there. Ajax-stuff? vue-resource just works.

Basically there are just 3 common issues left for Vue to become the ideal frontend solution IMO:

1) "official" bootstrap components that play well with vuex

2) a polished "react native" that just works, maybe soon solved by weex

3) SSR without hassle, ideally with a express.js middleware or something like this.

We use knockout at work but

    <p data-bind="if: foo">foo!</p>
quickly turns into

    <!-- ko if: foo -->
          because this also depends on foo and I should
          keep it DRY and adding a parent element just
          to contain that "if" is silly.
    <!-- /ko -->
Then you start to get comments everywhere and sometimes they don't match and you write server-side helpers to contain them then it becomes a soup of html, your server side templating language and knockout annotations.

JSX is way cleaner.

We are still probably going to migrate to Vue.js though because it will be easier. (We love Knockout but having performance problems on edge cases.)

You should consider using React with MobX. Similar concepts, but more powerful and mature.

> 1) "official" bootstrap components that play well with vuex

Doesn't vue-strap work well with vue? https://github.com/yuche/vue-strap

Yes, but not with vuex (model.sync is not an option)

What does vue resource do that can't be done with fetch?

I don't think the person/people who wrote these comparisons has much experience working with the frameworks and libraries they are comparing with. The comparison with Polymer sounds very strange to me as a Polymer developer.

They start off saying Polymer is based on web standards, where Vue implements it's own system. They consider this favorable for Vue, because on -some- older browsers Polymer needs a polyfill to work. This makes no sense. The idea is that in modern browsers Polymer leverages the browser implementation of custom elements so it needs to do way less work. They completely ignore the fact that the Vue implementation needs to do work to implement encapsulation on every browser, even modern ones.

One of their points is that Polymer is stuck with plain CSS and JS, which is clearly not true, considering TypeScript and ES6 are the most common JS flavors in the Polymer ecosystem. You can use any CSS and JS framework or preprocessor you want with Polymer, you just have to tweak your build pipeline a bit.

And then at the end they claim 'It is also totally feasible to offer deeper integration between Vue with Web Component specs', except that it hasn't been implemented yet and they are waiting for the spec to mature (even though all major browser vendors have committed to the Web Component v1 spec).

So if something is technically (remotely) possible to do with Vue, it's worth mentioning as an advantage of Vue, but if something doesn't come out of the box with Polymer it's clearly worth mentioning as a negative?

I don't have any experience with the other frameworks in this comparison, but after reading the Polymer snippet I don't believe in the objectivity of any of these comparisons.

Is that so? Well, feel free to raise an issue at github repo (https://github.com/vuejs/vuejs.org/issues). That will prompt them to update the comparison.

What happened with Backbone? Did I read you will try to avoid bias? I completely understand that you'd want to benchmark against the trendiest frameworks: after all this is Javascript and what matters is what happened in the last 12 months. Yet, as a Backbone user, and after playing around with the other popular frameworks, I still do not see a compelling reason to move dozens of well running projects to a new framework. Here's my bias:

Shaving milliseconds in rendering, repaints, scripting, etc? For what? Modern devices make it almost irrelevant. If you'd be selling seconds to milliseconds I'd say ok let's have a look.

Complex dependencies vs zero dependencies. So now I need some library to bind/transpile/build many other libraries that in the end will...shave some milliseconds. You just added unnecessary complexity to solve the same problem, not to mention more KB to download.

JSX??? Don't get me started here.

Backbone core library is all I need. It packs routing, binding, event handling, rendering. Yours is useless out of the box, to be used on a real complex app it needs...more dependencies.

Fork Backbone, add a virtual dom to shave them milliseconds, and I'd argue that we've made progress.

> Modern devices make it almost irrelevant.

A todo list on an mbp, yes. A complex app on a tablet, not so much.

> Yours is useless out of the box, to be used on a real complex app it needs...more dependencies.

All Vue requires is vue.min.js and you're set. Adding routing and clean data flow out of the box is trivial. _But_ it is easy to end up with a massively over engined babel-webpack-flow-npm-flux meme stack, given the excellent vue cli. I am, of course, guilty of that myself.

I'm not saying Vue is better or worse, having never used it. And you bring up some good points. But I had to chuckle a little internally because your post could almost be a case study of pg's blub paradox article.

True...yet I am still not convinced about the clear advantages ;)

Vuejs is adding it's own tags to html like if and for. Which requires another DSL to learn when i use simple js(not advanced js) in react. Which leads me question if they are other tags to be learn to simply display components.

I also like my components to be tightly coupled. Having a template just for a single component is not useful I learnt that from my backbone js experience.

Declarative syntax is very good win for reactjs. Most can eaily understand the component code. It requires few basic life cycle to be learnt rest is just JavaScript.

You can drop down to JSX or plain JS render functions with Vue if you like, but JSX (which brings with it all the potential complexity of JS) is harder for many people to understand. The constraints of a (very!) simple templating DSL make things easier to read in the long run.

For me it's easier to understand the lifecycle then to learn methods to simply do a boolean check or loops. In that way vuejs is more complex.

>Vuejs is adding it's own tags to html like if and for. Which requires another DSL to learn when i use simple js(not advanced js) in react.

I'm not familiar with the concept of simple js vs advanced js in react. But your statement about Vue's tags being its own dsl holds true for jsx as well.

JSX doesn't have control flow. Therein lies all the difference.

Javascript's void-typed statements are a problem, though.

JSX has do expressions, which don't exist in JavaScript, so it's a DSL.

As far as I'm concerned, a language doesn't need control flow, much less Turing completeness, to be a DSL. I don't deny that JSX is a DSL.

But when an embedded template language grows control flow, it creates two different ways to do things. The outer language has control flow, and the DSL. The choices increase complexity. TMTOWTDI is not actually a great idea.

(AFAIK JSX only has 'do' by way of Babel. But it's just syntax sugar for creating a function and calling it. So you can get your control flow that way; but it'll be Javascript control flow.)

No, it doesn't have do expressions.

This might be a viable alternative for companies who don't want to agree to React's licensing terms[1]. They also claim significant performance improvements over React.

On the flip side Native rendering will require learning yet another framework[2].

EDIT: You are not limited to using the templates, JSX is also an option[3].

[1] https://news.ycombinator.com/item?id=11270213

[2] https://alibaba.github.io/weex/

[3] https://youtu.be/pBBSp_iIiVM?t=721

> This might be a viable alternative for companies who don't want to agree to React's licensing terms[1].

The concern over React's licensing terms is that:

1) Facebook might have a patent on some aspect of React (such as the virtual DOM).

2) You might get into an unrelated patent dispute with Facebook.

3) This would allow Facebook to terminate the patent grant.

4) A court might hold that the implicit patent grant usually assumed to be in the BSD license was superceded by the explicit patent grant.

5) Facebook can now sue you over your violation of their virtual DOM patent.

That's a fairly tenuous chain of events, but sure, it's possible. So let's say instead you pick Vue. Assuming Facebook does have that virtual DOM patent:

1) Facebook can sue you over your violation of their virtual DOM patent (since Vue also uses a virtual DOM).

That doesn't really seem better? Actually, it seems much much worse! Of course, I have no reason to think Facebook has any such patents, and if they don't, then the entire discussion is hypothetical. But still, it is interesting to try and figure out what patent they might hypothetically have which applies to React but clearly not to Vue or other similar framework...

> I also like my components to be tightly coupled.

It makes project not maintainable. So using plain JS is not an option for the large long term projects.

I am working on a multiple large reactjs project for more then a year. You need to think in terms of components.

> You need to think in terms of components. reply

Why do you think I need to think in terms of components? I'd say you need to see a bigger picture not limiting yourself by only components approach. Components/modules is an essential thing of any complex project in general, ie not specifically related to the web development, but that's not enough. Try to realize that for example using praised by hipsters mixins for inheritance makes it very complicated to track down from where things came into the final object.

Think in terms of components. Design small components which would be used by larger components. As I said I am already using the approach. If you could not then maybe you need a better architecture. Components are just one part. State management is another.

I also like my components to be tightly coupled.

Ah Javascript programmers, you are a source of constant entertainment:


When a component only ever has one template that defines its markup, and the template is only ever used by a single component, and the template needs to change when the component changes, and the component needs to change when the template changes: if these are all true (and they often are for UI components), then there's little to no upside to separating them physically or linguistically.

While I saw that comment coming a mile off, "tight coupling" of your components to their templates is not quite the same thing as tightly coupling completely seperate classes with completely different datasets and responsibilities.

Not familiar with reactjs? You need to have loosely coupled tight components.

mixed with something looking like HTML that is NOT HTML. I love React it's the first js framework that doesn't make me wanna puke, but Jsx it's just the iPhone of template languages. It's fine and eveeybody understand it but it's far from great

OP did not mean "tightly coupled" in the traditional OO sense. They meant that they prefer their presentation to be coupled with their logic, which is how React components work.

Problem me with Vue is it's template language. Why invent a new one and not use JSX? Main selling point for me with JSX is it's the most type-safe templating language I've seen when used together with TypeScript.

People have pointed out here that it's easy to use JSX with Vue, and that could be something I might look at.

You talk about JSX as if it is some sort of standard. A significant number of people aren't interested in compiling to JS or language extensions for a number of reasons.

I appreciate what Facebook were trying to achieve with JSX, but libraries like Mithril serve as an example that native templates can be done without a syntax extension.

React can be used without JSX like Mithril is doing. In fact, pretty much all the JSX compiler does is convert those to React.createElement()..

FWIW my understanding is the vuejs template language is based on an early version of the web component template specification (which might predate the jsx specification). You may therefore notice a good amount of overlap between vuejs templates and polymer, for example.

> Why invent a new one and not use JSX?

JSX is a new templating language too. It not standard; it not JavaScript.

I feel it's probably been said before, but why are people investing time in a Javascript server side framework? It just seems ridiculous.

Edit: I can understand shipping logic from the server to client, for validation perhaps. But... meh.

From personal experience developing at all levels of the stack, I think my job breaks down into something like

  * 40% UI (visualising states, handling user input, feedback, etc), 
  * 55% moving data around (read an XML file, translate it, push it into db over there)
  * 5% algorithmic work (given input of x million records, figure y out)
The UI stuff I already did in Javascript, however it turns out that one single threaded process can shuffle a lot of data around (resource efficiently), if I adopt an async programming style. I know NodeJS is not the only language that does async stuff nicely, but it's rather convenient to have the same language everywhere (though I recognise Javascript is not the most elegant).

If your success relies on search engine listings, it is still better to render the contents on the server to that the crawlers can index it (some still penalise JS only sites). You can then "hydrate" the SPA on the client for a better user experience.

Because they believe that a single language should be enough for developing web applications.

What became of "the best tool for the job"? I doubt the benefits of having a single language outweigh the effort put in just to replicate solid server-side environments existing today.

I know what you mean, but at some point in history you could say that for every programming language that wasn't the first one to dominate that specific domain.

Absolutely and I'm not against innovation at all. The exercise of making JavaScript a valid server-side alternative often seems pointless, though. What's the benefit of JavaScript on the server side other than "one language"?

Perl, Java, Spring, Ruby on Rails each offered significant benefits over what existed before. What does JavaScript on the server side do better than other solutions? There's the event loop and non-blocking behaviour but is that enough for most applications to justify using JavaScript on the server side?

For me it is not just about being comfortable in writing the same language for aerver and client. It has also a technical aspect to it:

I can directly run my application code, which is a single page application in js, also on the server. I have complex datamodels in my js application. It would be very much work if I need to use some of these datamodel functions on the server if I wouldn't use js there.

I think you may be underestimating the "language barrier" for more junior devs. What I see around me is that it takes a few years of programming before you start "seeing through" the syntax and realise it's all the same.

With Javascript everywhere, I experience we have less resistance for people to work all over the stack.

Also there's something to be said for JSON. There is a big win in having it all the way from the DB, untranslated up to the UI.

> I think you may be underestimating the "language barrier" for more junior devs.

I know people like that. Once junior devs, too back in the heyday of Enterprise Java in the late 90s they couldn't be bothered to learn this ugly upstart language known as JavaScript because "serious developers don't use a toy language like that". In part, who can blame them? CS professors at that time floated ideas like object-orientation and code generation being the be-all and end-all.

These developers sometimes went at great lengths to avoid writing the tiniest bit of JavaScript at all (when it 'finally' became obvious that this newfangled web thing wasn't a passing fad ...) and invented convoluted frameworks that generated JavaScript from Java code. These frameworks inevitably couldn't keep up with the pace of change in the web development community at large, which is why nowadays they often are a huge technical debt to the projects they're used in.

The developers themselves, now not so junior anymore, often have a hard time finding a job today because learning something besides Enterprise Java was too much of a hassle.

So, while the idea of "easing in" junior developers by having a consistent language in all layers might have some merit, in the long run it might very well be doing them a disservice and also leave behind a huge pile of technical debt in the end.

Yes. Despite writing both straight assembler (68k processors) and C back in the 90s, I also fell into the Enterprise Java-trap for a long while. GWT was my go-to front end framework, and it worked I suppose.

It's a bit hard to compare these days, since browser quirks were much more pronounced back then. I remember tackling differences in IE4/5 vs Netscape 6/7 and all those hacks and workarounds seem absurd now. When GWT entered, it at least unified these platforms and worked around many differences for me.

And don't get me started on server side enterprise stuff. I still run screaming when someone proposes "IoC containers" or "workflow engines" in NodeJS. Never again!

Wonder whether "Virtual DOM" and "Transpilers" is what I run screaming from in 10 years?

(i already decided against transpilers, ES6 syntax isn't worth the overhead imho)

They still offer benefits. And some also offer an event loop and non-blicking behaviour. However there is a huge number of libraries around Node which enable you to solve problems both in the browser and on the server. For example Highcharts rendering graphs in the browser and rendering them as a png or pdf on the server, enabling the user to save them.

Too bad it doesn't have a standard library, too bad js is an ugly language compared to Ruby or even Perl. Too bad npm duplicates dependencies and pulls tons of packages.

Probably a fair enough perspective. I guess I just hate it. With a passion.

The consequence is that you can share code between client and server which is a large benefit.

But Javascript fans often also say the server should only be a REST API, consumed by the client side, and not bound to it. What that means is :

1) It makes no difference at all if is the server is implemented using a different language than the client.

2) You shouldn't share any logic/code between the server and the client, even if they are using the same language.

I realize you are critical of that viewpoint, but point 2 seems really wacky to me.

Current big project at work has a back end that is not in JS, but we still have a way to run the same validation code on both sides, which is run in an embedded JS interpreter on the server.

I'm not sure I would want to write a complete back end in JS or not (even if I'm not in love with Java, lately), but reusing this part makes a lot of sense.


We currently serialize (sync block) validation requests on the server through Nashorn, rather than having multiple instances (per thread or a pool). But, it's not like the requests wouldn't be serialized through Node, though. The rest of the request processing happens on independant threads normally. Not overly fond of threads, but I don't think I could get my team to by into Erlang or Elixir :-)

For that matter, my primary partner on this project is a big Scala fan, and we couldn't even get the rest of the group to go for that :-(

> 1) It makes no difference at all if is the server is implemented using a different language than the client.

Makes a difference: Same people can maintain it without too much friction.

> 2) You shouldn't share any logic/code between the server and the client, even if they are using the same language.

Why not? It's nice, for example, to export your validation logic to a separate library and consume it from both sides.

> Makes a difference: Same people can maintain it without too much friction.

For a very small team, I guess it makes sense. I would still prefere to be able to use Java/Kotlin/C# on the server and on the client then. Or even Dart. Not Javascript...

> Why not? It's nice, for example, to export your validation logic to a separate library and consume it from both sides.

Then they are couple together. And then you will tend to design your API in a way this particular application is well deserved. But if one day you have to consum the same service from another application, a native iOS application for instance, then you may start to realized that your API is too bound to your first consumer.

But I guess it's not that important if your backend will only be consumed by this particular application, ever.

> Then they are couple together. And then you will tend to design your API in a way this particular application is well deserved.

We have a server which exposes validation logic as a generated JS library (no server-side JS yet but we plan switching to Typescript) and that is used across many (more than 10) clients. I don't see any coupling. Changes in your models break the API regardless of you sharing anything.

Also, JS is built to handle concurrency. Other languages have event loop libraries, but in JS it comes with the language and every web dev uses it.

"Async all the things" concurrency doesn't matter.

Javascript is not going to be faster than Go or Rust, which are increasingly taking over as web backends. (I'm writing stuff in Rust's Iron framework lately.) Or Java, for that matter.

I can serve more requests from these languages than "concurrent" Javascript.

I don't doubt that you can. But in a lot of situations, as long as the slow stuff like db queries and api calls don't block, it's good enough. And that's easier to accomplish in JS.

What does it mean that it "comes with the language"? In what way is Javascript the language any more asynch than Python, PHP, or Ruby? The browser and Node environment are not JS the language. They are the environments JS predominantly runs in, and they provide async events, which could be done with any language running in similar environments.

Would your objection be appeased if he said "comes with the environment"?

IDK of any Python, Ruby, or PHP runtime that has Node's paradigm of single threaded + concurrent I/O.

Would Python handle async well with the GIL?

This has only been the case for a few years, since the ECMAScript Xs, which is why I think you're being downvoted. To be fair, it's a relatively new feature in Python too.

To me, it's the event-driven problems JS tries to solve that seems to overlap with typical server functionality. That has been true since the beginning.

What, that you clicked a button and JS did something back in 95 when Netscape introduced it? The same could be said for Visual Basic for any language that had callback code attached to a button click. You do realize that Python, Perl, etc could be written to handle GUI code back then as well.

JS has been focused on event handling types of problems while python and perl were used for many other types of problems. You can build a GUI with R, but it wasn't made for it.

>You can build a GUI with R

Why would anybody do that to themselves?

1. If you really hate templates, maybe it's time to go full bore and make the switch to Elm.

2. If you are working on page/site that may or may not evolve into an SPA, choosing Vue.js over Angular or React seems like a no-brainer.

3. If you are working on an SPA from the the get-go, then the choice becomes more difficult. However, if the SPA is only one part of your site Vue.js offers you the opportunity to use it site-wide, whereas using React or Angular site-wide would quickly become quite cumbersome and I'd guess is most cases folks actually use React/Angular for the SPA pages and jQuery for all others.

I strongly disagree on your 3rd point: In my experience React gives you full control over rendering which includes where you want to use it and if you want to use it with non-React stuff. Regardless of site being a SPA or not.

As an anecdote, I rewrote a large site from jQuery to React without precompiling my JSX and using ES6 via Babel. It took 3 script includes and then I could do a gradual transition and replace elements with React instead of jQuery. jQuery components lived happily alongside React just fine. Even though I did nothing to optimize page loads, I made massive gains for performance, even with React in dev/debug mode.

If anyone is interested in more indepth Vue examples and back and forth, check out the VueJS subreddit here: https://www.reddit.com/r/vuejs/

Why do they say their template system is simpler than JSX? You have to learn a whole lot of new stuff and syntax is barely readable. Whereas JSX is clear and you can use already familiar JavaScript.

JSX using JS for logic is both a boon and a curse. It is just as easy to shoot yourself in the foot and write some ugly imperative construction as writing an elegant template.

I wonder if we will ever have a satisfactory solution to the template problem of conditional rendering. All I've seen so far solved one problem only to bring another. To some degree, this is really a dogmatic problem, which is why it'd be nice if we could solve this and move on with more important things.

In fairness that's the main point of contention with PHP templates, leading us to 4 big templating languages including PHP itself.

It's the same old balance problem: more flexibility and less constraints opens up potentially dangerous misuse.

We see it with languages too I.e C memory management vs garbage collection.

We also see it socially too. There are particular problems with both 0% regulation and 100% regulation, with the ideal that nobody can agree on lying somewhere in between. In fact, some situations call for more or less, compounding the confusion.

Perhaps the solution is a template system that can fit current needs, in that a programmer can choose to remove a restriction but the removal of the restriction gives the seconds required to think if removing a restriction is necessary.

That then means we can collaborate as an industry. We may find that there exists one or a handful of "ideal general restrictions". We may also find that actually for certain types of problem would do well with a handful of specific restrictions that work well there.

I just don't think there is a one size template solution and our attempts at a fixed ideal haven't seemed to work. After all, if we had the true ideal, we wouldn't keep making new ones.

It seems like a huge waste of time to create a new language so that people will not do "stupid" things in their templates. The case of PHP is especially amusing. How about using common sense? I mean if a programmer intends to do "dangerous misuses" in the templates, maybe he shouldn't work on it in the first place. Having a person not being able to tell whether something is dangerous or not, working on the project and then creating a template language to forgive the lack of knowledge is just asking for trouble in the long run.

JSX is "new stuff" if you've come from Jade et al. Vue templating is much more like what pre-React frameworks use.

You can use JSX if you like with Vue. The templating language, should you choose to use it, really is very simple though. It doesn't take more than an hour or so to get the hang of.

Well, display a list of things in JSX and Angular or Vue - I found the latter versions way more elegant. But YMMV.

> Why do they say their template system is simpler than JSX?

JSX doesn't run in browsers.

"Polymer custom elements are authored in HTML files, which limits you to plain JavaScript/CSS (and language features supported by today’s browsers). In comparison, Vue’s single file components allows you to easily use ES2015+ and any CSS preprocessors you want."

This is incorrect. It's easy to use ES2015+, TypeScript and CSS preprocessors in Polymer.

Reading the comments here makes me realize it is probably better to come back in 12 months and observe what is still left standing.

I've used Vue since before v1 and for my use cases it's fine - especially v2 combined with Vuex. I was suspicious towards React from the get go because to me it looked over-engineered. As for Angular 2, yeah, it's a major improvement over its predecessor, but that's about it.

> By embracing HTML rather than trying to reinvent it within JavaScript, [...]

I am sorry, but that looks totally wrong with the previous code example. Vue in that instance seems to be reinventing Javascript in HTML (while the critique is true that React reinvents HTML in JS).

I am new to Vue.js. What is the use case? Is it like react in that you can use it to target web,android and ios with one codebase?

It's a "Competitor" to Angular.js, focusing on the web but with plans to go on android/ios like React Native eventually.

Is Vue fractal?

Personally, what I love about React is how simple the model is. There are no Directives or Filter or whatever else. It's just a Component with a state, a render and some life cycle methods. That's it. The full power of Javascript in a render function. The second you try to move away from the "full power of javacript to render your view", the more you need to add special cases in your template engine.

Just randomly going through the Vue docs, we see stuff like:

>> Note that you should not use an arrow function with the data property (e.g. data: () => { return { a: this.myProp }}). The reason is arrow functions bind the parent context, so this will not be the Vue instance as you expect and this.myProp will be undefined.

I don't want to deal with this crap anymore. I'm still making nightmares about $scope.$apply. (Yes I know Vue doesn't have the $apply problem, that was just an example).

Where I think Vue.js really shine is for teams that want a standard, industry proven solution, to build web apps. Similar to Angular, you don't have to re-invent the wheel. You just look in the documentation and use whatever is built for you. I think this is great for many projects. Personally I've been burned by the limitations of those frameworks and I'd rather keep my freedom to build things the way I want.

In the Vue comparison, they say this is how you build components with React:

  render () {
    let { items } = this.props
    let children
    if (items.length > 0) {
      children = (
          {items.map(item =>
            <li key={item.id}>{item.name}</li>
    } else {
      children = <p>No items found.</p>
    return (
      <div className='list-container'>
If you're the kind of person who keep repeating that kind of code everywhere in your app, then yes, maybe Vue.js is better for you. But such if/else pattern is easily abstracted away with a simple function which makes it as concise as the Vue snippet without relying on directives in templates. Also, keep in mind that this is only one use case. What if it needs to be slightly more complex? WIth Vue/Angular, you're forced to add directives or whatnot. With React, same render function. I like that cognitive simplicity. Yeah, maybe the render function is slightly more complex, but at least there's only that to be aware of. Not hundreds of directive/filters/whatnot spread everywhere.

In a way, I feel like React is more lower level. I use it to build my own framework on top of it. Where I feel like Vuejs, similar to Angular, is the framework.

So they left our the one platform more popular than them, Meteor?

- Meteor is promoting react for view layer.

- Blaze, meteor's original view layer, lacks components and has very slow development.

So, comparison with meteor quite useless.

Whose has used mithril and how does it compare to vue?

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