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.
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.
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.
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.
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. :)
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. :)
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.
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.
//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.
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).
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.
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.
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.
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:
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.
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.)
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.
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.
> 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.
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).
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.
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.
>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'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.
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.
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?
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.
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
<ul>
<li v-for="num in listItems">{{num}}</li>
</ul>
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.
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.
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
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.
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>
```
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.
Seriously.
```
$ mkdir foo && cd foo
$ marko create xyz
$ cd xyz
$ npm start
$ open http://127.0.0.1:8080/
```
Follow along with the docs / tutorial and then humor me and run the following:
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.
> 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.
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.
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:
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 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%:
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.
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).
:P
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.
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.
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.
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.
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 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.
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.
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"
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.
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.
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
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.
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.
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.
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?
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.
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.
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.
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*
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".
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.
* 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.
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.
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.
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.
> 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.
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.
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.
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?
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.
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.
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).
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.
> 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 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. :)
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.
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.
In a way VueJS is "React for those who liked Angular1".
I've done many Angular apps. I've done a bit of React (with Reflux & Browserify).
I tried moving to React/Redux/Webpack but it's not an easy task to grasp the whole thing. Webpack itself was close to make me throw the towel on side projects.
I tried VueJS because of a job interview and quite liked it and got productive really fast thanks to good documentation and my previous experience in angular & React.
Professionally I wouldn't mind any of those but for side projects it will be VueJS from now on.
As a side note I don't get why all the boilerplates always mix backend and frontend code and dependencies. If you're not interested in a node backend and learning it's overwhelming.
The worst thing is that boilerplates you find are always outdated (router, hot-reloading etc) and worst of all mingling server and client deps so if you're not interested in a node backend you have to
If I was reading your post 3 months ago, I would completely agree with you.
But learning React/Redux and Webpack is not that hard at all, just focus on one and move on to the next. WebPack is dead easy IMO, Redux is just an design concept, but it's easy to implement as well. I think sometimes developers over hype technology and make it sound incredibly hard, when in fact is just isn't.
React itself is simple but having a whole project with React/Redux and a full fledged Webpack/Babel config managing dev and prod build is really not simple IMHO.
And, once you have all that working, staying up to date without bugs due to version mismatches can be a real pain.
I feel like a broken record, but definitely take a look at create-react-app if you haven't already. Its extremely well documented and takes care of managing the 20+ dev dependencies that are typically associated with a project.
I've built applications with it using polyfills and things worked just fine with legacy applications on IE10 + jquery interacting with web components.
Performance is nice, there is more and more adoption from giant enterprises like Netflix, IBM, GE, Gannett, Electronics Arts, CocaCola, ING, BBVA.
Webcomponents.org has over 1k components to choose from and is growing.
Now with `lit-html` arriving soon we might see alternative to JSX if someone wants that, polymer-redux or polymer-uniflow is available as an option too.
https://hnpwa.com/ - one of fastest Hacker News implementations is based on Polymer - and that is even without SSR.
SvelteJS also seems nice, although it seems one-man project for now :( On Polymer end I hope that on the summit next week they will announce proper NPM support finally and I miss that.
I used Polymer 2 to build a couple of highly used internal web components recently. And I'm currently in the process of ripping it all out. Why? It's not technically Polymer's fault, but the performance and stability on iOS and Safari are complete crap. Often crashes the browser on both desktop and mobile.
Also, the Shadow DOM is one concept that I liked in theory and hated in practice. Made it very difficult to do very simple styling tasks that were accomplished easily with plain css and proper naming (e.g. having parent components provide default styles for child components).
The polymer bundler in 2.0 is a buggy mess (it's still in beta) and I couldn't find any decent way to use Webpack with Polymer.
Many other complaints about Polymer that I won't go into. It's way too green in my opinion and I'd recommend avoiding it for at least the near future.
I got into same problem you had - the trick is to have view/parent components not use Shadow DOM - then you can use normal css styling, or alternatively prepare a `shared-styles` file that will contain styles shared across elements.
IMO having everything inside Shadow DOM is an anti-pattern.
I use my own pipeline based on gulp so I don't know much about polymer bundler, webpack support was recently added though, I haven't used it yet.
I can vouch for SvelteJS. It's simple & has near vanillaJS performance.
I use SvelteJS on both the client & server side. SvelteJS also has a rehydrate feature, which allows you to render html on the server & then bind the Component on the client.
Having 1k components sort of seems like a bug rather than a feature. How does that avoid becoming left-pad hell again and how would you expect any sort of quality control out of that?
Not really (I'm not even sure of a feature of "what" would it be?)- it is not like you have to use any of that - you could make same criticism for NPM, pypi etc.
Webcomponents.org is just a repository, nothing more.
If you want quality then you just use components backed by reputable authors - I guess that is the universal rule for development in general.
That's sort of my point. Having ten different implementations of, for example, a data table, each using its own variant of what button template it prefers seems like exactly the kind of hole npm dug itself into. That doesn't seem very desirable for a UI framework that is shipped to clients and demands polish.
Sure, you don't have to use it, but it's the main selling point of polymer. It seems nice in theory but npm also seemed nice in theory.
Polymer is NOT UI framework - its "jquery for webcomponents". Companies like Google, General Electric or Vaadin release their own component catalogs with elements - if you want consistency you use that.
But I do agree that too much fragmentation can be a problem.
For anybody looking into vue.js for the first time, I highly recommend starting with Laracasts series of screencasts which I found much more helpful than the information on the vue.js site itself when I was getting to grips to with it:
These are the things I find to be killer features of React and it's ecosystem:
- React Native (I know there's Weex but it's not production ready, nor as feature rich)
- Streaming server side rendering
- React Relay (GraphQL integration)
- JSX by default. VueJS pushes an Angular-esque template language where I have to learn new syntax, binding concepts, directives and conditional statements.
- Corporate backing
I've used React in very large projects, where these features have been fairly critical. React's licensing is odd but not odd enough for me to ditch it. I'd really hate to see the community churn once again on frontend libraries, but that's JavaScript for you I guess.
I wasn't aware VueJS had streaming server rendering (and I still can't find anything about it), but React has had it long before v16 via a library (https://github.com/aickin/react-dom-stream)
yea, Vue had it in its core along time ago. Hence another downfall of react... you end up downloading tons of 3rd party packages that Vue gives you by default.
i was in the same boat as you regards to syntax but in 10 mins you will grasp everything about vuejs.
of all the frameworks, vuejs has the simplest syntax to learn. its no where as complex as angular and way more elegant. also beats jsx in terms of making your code more cleaner and prettier. im never going back to jsx.
2) : is just a shorthand for v-bind (ie; v-bind:disabled="is_disabled()" is aliased by :disabled="is_disabled()"). and this basically allows you to run pure javascript code inside of it.
3) the only other syntax to know is, v-for and v-if, but thats pretty self explanatory i believe.
<h3 v-if="user.name">{{name}}</h3>
<h3 v-if="!user.name">What is your name?</h3>
<h3 v-if="user.role == 'admin" && user.name == 'james'>hello super user {{name}}</h3>
i like this approach more than JSX where you have several if else clauses mixed into your HTML. it's kind of like pattern matching if you like that sort of thing.
or you can simply do <h3>{{some_message()}}</h3> and just handle the logic inside the some_message() method.
1) v-if is not html. In html if you see <h3 ...> you immediately think, "there's a level-3 header element here". The thought "there's a level-3 header element here if..." is something new you have to learn for Vue.
2) Shorter is not always easier. For example, using quotes to delimit logical expressions makes it easy to make errors. See the misplaced quote here?
<h3 v-if="user.role == 'admin" && user.name == 'james'>hello super user {{name}}</h3>
> i was in the same boat as you regards to syntax but in 10 mins you will grasp everything about vuejs.
Not sure about the original poster, but I prefer react/jsx not because it's simpler, but it's more powerful - it's a simple extension to a full programming language. You can do whatever you want with it.
perhaps you might be thinking that you can't run raw js with vue? well you get js and more.
it's just less coding and boilerplate if anything.
vue also optimizes your reactive codes and is faster in many cases. react can get pretty slow and heavy if you don't know what you are doing and trying to debug those situations can get pretty hairy. otoh, i've not seen any similar issues with vue. what vue does with the bindings is really neat.
What's with the hate for JSX? I think handling HTML as data makes much more sense and is much more convenient than dealing with dumb templates or weird DSLs like Vue's or Angular's.
as you'd expect - instead, the whitespace after the pipe character is eaten by JSX. This is because HTML is whitespace sensitive, but JS is not, and so to allow indentation, JSX trims whitespace.
This does not work - instead, you need to return an array, but the result is ugly - the commas are part of JS, not HTML, and don't appear in the output, but reading this quickly it's hard to see that (the difference is the braces surrounding the block).
Vue's 'weird DSL' is HTML (the same is not quite true for Angular's). What you see is exactly what you get. Having a DSL also means you can define your own syntax. Things that are verbose (due to historical reasons in JS), such as iterating over an object, can be made simple -
<dl>
<template v-for="(definition, term) in definitions">
<dt>{{ term }}</dt>
<dd>{{ definition }}</dd>
</template>
</dl>
I disagree on your first example: I've historically found the extra whitespace a huge PITA for years. It causes extra "unpredictable" spacing in your design which is usually unwanted. It's only an issue for multi-line prose. React is opinionated here but I've found it's the most useful option.
On the 2nd point, you are partially correct. In general it's a code smell - strongly consider making it a component (in part for optimization). But definition lists are specifically strange: Unlike other repeating elements in HTML they don't have a container element like tr, li, fieldset, etc.
Good point about the whitespace, but I'd still rather have the templates inside my code than separate the two, mentally parsing two separate languages with different syntax and stitching them together is a lot more mental overhead IMO.
It's a matter of personal opinion, but I guess I'm more used to server-side templating languages, which Vue's looks much more similar to. I have the same problem as you for JSX - I keep trying to read it as HTML, except it's not, and mentally translating it is annoying.
i assure you, you will get over that phase real quickly. you will come to appreciate how nicer it is to write your code this way. because the same thing happened to me.
Surely the huge win for JSX is that you can type check it?
I have a Typescript + Angular 1 project. The app logic feels robust as Typescript makes sure I'm using the right identifiers, variables aren't null/undefined etc. The Angular templates are a constant source of annoyance: they aren't type checked and aren't part of automatic variable renaming refactorings.
This is ultimately what makes React the right choice for me. A big part of the whole code=data thing is that code can be typed, which means now your data (markup) can be typed as well.
Of course this only really matters if you use Typescript/Flow.
One of the biggest things React has going for it, other than being maintained by Facebook and having a much larger community, is React Native. You can learn one web framework and now also make compelling, real native apps. To me those are both deal makers.
Surprised I haven't seen this mentioned more in the thread.
Or you can just compile any HTML5 mobile app using Cordova and in 99% of the cases your users won't notice any performance difference between native-app and HTML5 app.
Maybe for extremely simple webapps that might be true, but for any non-trivial Cordova+React based app you can't come anywhere close to the UX you can get with React Native without some extreme engineering effort. I'd much rather eat the cost to port the HTML5 app to React Native instead. Yes, the users DO notice.
Inability to have the same level of control over soft keyboard behavior is one of the top problems with Cordova, IMO.
Source: wrote & maintained a Cordova+React app on iOS/Android for 3 yrs.
Yeah, you are right, I was mostly referring to the performance part. If you need native UI elements or native UI interaction it's harder to do that in a HTML5 app.
I mostly worked on games, where the UI is custom and there are very few similarities to the UI of the OS, so it worked pretty good.
I agree, there are many competitors to React for targeting the DOM, but there is much less competition for targeting Native. I hope to see more JSX-to-Native engines pop up soon to solve that problem.
Exactly this. In fact (as someone who only knows Swift for mobile dev) learning React was my first step to get into React-Native, so I can make iOS and Android apps.
You can't write JSX without a template compiler (how ergonomic is it to hand write a render function?). It's painful to write React components with just a script embed (this might not be important to you, but it's important for newbies coming from jQuery), while Vue lets you get away with HTML attributes and Vue.extend(). Lastly, Vue's style scoping is superior to anything React has to offer.
What kind of webapp are you writing where adding a compilation step adds too much complexity? I get if you're writing an application that's 95% static with a few moving pieces, but otherwise that argument doesn't hold much weight for me.
..How? You'd just get a syntax error. Embedding a runtime babel compiler isn't mentioned in the docs at all (though I guess it would work albeit killing load performance, but it's not something that you would expect newbies to know, especially if it's not in the docs).
In vue you have forma free reactive data without using shouldcomponentupate. Components are updated when data change and only for the data they binding.
You have also local context while react have a global context.
Props are reactive ... And many others feature
This actually scares me because I have extensive experience in knockoutjs. It also used a reactive system. The problem was once the UI became sufficiently complicated performance would suffer greatly. If you had a lot of computed properties changing a piece of data could result in a lot of UI thrashing as each of these are recomputed. I'm not sure how Vue solves this problem, or even if it does but overall the architecture was inadequate.
That usually only works well for really small components. Once you're serious about your web app, you'll end up using the whole developmnet Webpack environment in short time anyway.
I happily used Angular 1 for a few things. When it became clear that Angular 2 was the party line, I looked at it and unfortunately found an overengineered framework chasing what React was.
I looked at React, but without a cohesive framework, that ecosystem is just a bit too much of a mess. A gazillion starter app templates that can't quite agree and always seem a little out of date with the fast moving components. JSX is just ugly. At least to me. I regularly use Django templates, so the clean leap to Handlebars-style templates feels very natural to me. Redux is straight up unapproachable to someone new to the concepts, but at the same time it feels like it simply reinvents events and event handlers.
Vue was a revelation. It is simple, cohesive and I feel productive.
I know this is about Vue vs React, but a lot of the things people are saying they like about Vue can be found in Google's Polymer. It's very simple to comprehend and you can make single file components. And it's based on W3C standard web components so you won't be building yourself into future obsolescence. With Polymer 2 components are now built using classes, so your code is clear and 100% native JS. Lastly, the goal of the Polymer team is to get rid of Polymer by advancing web standards, and with 2.0 you can see they are definitely following this approach as Polymer doesn't add much to web components other than ease of use functionality such as template binding and cross browser shims.
I used both react and Vue, and I would always choose Vue.js over react. beside all the features Vue has, its the documentation that I really like. it makes you want to read more and more.
I'm using react and like its functional approaches. I started implementing libraries such as immutablejs, recompose and ramda. I also make use of pure functional components exclusively. Then I had a look at Elm and I realized that, with all the libraries I have put together, I created my own crippled frankenstein'ish version of Elm. I think I really should give Elm a try!
Agree that Elm is a good all-in-one solution for SPAs.
You should also give ClojureScript with the simple React-wrapper Reagent a spin. All the functional stuff is built into the language, like Elm, albeit without the types, which both has its pros and cons.
I don't know why inferno isn't more popular, I use a lot of html5 apis so for what I'm working on inferno is more useful to me than react or Vue. I'm doing webaudio so react native doesn't help me. Also inferno doesn't require me to enter into a patent agreement with Facebook and yet I get all the benefits of react from using inferno. Now if I were needing to use native APIs then I might need react native but then you have to balance that need with the potential license issues
I'm currently investigating Vue to see how it compares to the current React code I have. So far I'm liking it.
The main things that I like so far;
* Single file components - I actually really like this, I find it much easier on my brain to have everything related to a component in the same file.
* The router and data modules - having the router and Vuex as "official" parts of the ecosystem (as opposed to in React where they are "adopted") means that everything just clicks.
* Styling - when I first started out with React, it was a pain to find a nice way to do CSS - do you use modules? Just have files that you import? Inline? Having it automatically scope the styling to the component if wanted, or using modules if thats your thing - is so much nicer than having to think about it. I just add <style lang="scss" scoped> and I don't have to worry.
The only downside I have at the moment, is having to learn the "v-" bindings (which is what put me off Angular when it first came out) but I think that it is something I can live with. Although you can use JSX and have a render method so I might try that and see how that flows for me.
For me, the best thing about jsx is the fact that it's so easy to create different implementations of `React.createElement` to solve different problems outside of the scope of React itself. Want a render function that uses jsx but returns a string, a DOM tree, or something entirely different? Totally possible! I didn't like jsx at first, but the fact that it's so decoupled from React itself counts extremely in its favor, in my view.
For example, for one of my libraries I wanted a really simple way to allow people to include custom templates. I started with string-based templates, but quickly realized that this was inflexible for any kind of event binding or later dom mutations. Achieving that was super easy with jsx -- I just implemented a custom jsx function which directly outputs DOM elements.
This even allowed some cool hacks like including iframes directly in the jsx, to sandbox sections of the page (since the library is geared towards creating components to be embedded on 3rd party sites):
containerTemplate({ jsxDom }) {
return (
<iframe>
<style>
p {
margin-top: 40px;
}
</style>
<p>I can be sure the styles in this iframe won't affect the parent page</p>
</iframe>
)
}
If you use something like Kea (https://kea.js.org), the amount of boilerplate for Redux goes down dramatically. The syntax is actually pretty simiar to Vuex, perhaps with even less boilerplate.
You've done a nice job with kea. The examples are pretty clear. Somehow the selection of verbs and structure is more readable for me in the vuex example but I'm not sure you could do much about that.
I won't be using this as it definitely sets off my library-depth spidey sense.
The multiple libraries it abstracts would all change versions over time and lead my applications to be even more brittle.
Vuex being mainline with Vuejs is a major plus as I look at its long term stability, though whether it insists on vuejs I need to look into.
For the library-depth spidey sense, there's really no getting around that. In a way, as React itself is just the view library, you're forced to add new pieces to your app until it all clicks together. Kea is just one more of these pieces... And I wrote it so the other ones would click together. The alternative to abstracting libs like that is to write and bundle everything yourself, but that is a hard and, in this case, unnecessary path to take.
Two of the libraries it abstracts (redux and reselect) are as stable as a rock. There have been no breaking changes for many major releases. The third one, redux-saga, is a bit more brittle, but as it gets passed direct control over its domain, I don't see how kea would break anything there, at least not in the near future.
Of course I'll do my best to keep up with new releases of all dependencies. I do have a few apps with Kea that I actively maintain.
There's still the chance that Kea itself will change drastically. I hope not. I'm actually trying to stabilise the API for a 1.0 release.
I was a huge Ember evangelist until I started trying to onboard other devs into my project. It took months for people to figure out which way was up. In comparison, other devs picked up Vue in a week or so.
Interesting, because my company chosen Ember precisely because it would start a hiring wave of new developers, often junior ones. Mostly because of Ember's "convention over configuration".
I dont see much of this problem, including myself as one of these just hired jr devs.
The projects I work typically have very fast turn around times (2-4 months), so I don't have the time to teach a dev use a framework, and I definitely don't have the time to onboard junior developers.
I need a framework where any experienced JavaScript developer can pick up the project and deliver working product in a week. With Ember/Angular/React+Redux, I have to hunt for a developer that specializes in that particular framework. With Vue, the hiring pool is vastly larger.
Exact same problem here. I've written ~20k LOC non trivial web app in Ember and getting someone into the project that didn't had prior experience in Ember was really tough. Then we were thinking about Vue too and like in your example, that person picked up Vue in around a week also.
Same here. Going back to some large ember projects I built just 2-3yrs ago, it's almost impossible to comprehend. Also, it's impossible to upgrade to the latest version of Ember due to the amount of churn they went through from 1.x to 2.x
Vue.js is going to win because simplicity and easier bootstrapping matter. In the same time Vue.js is powerful enough for building the complex and scalable apps.
Couldn't disagree more. Or perhaps, more accurately, I think the scenario you are referring to isn't the one that matters.
It's not about taking a massively existing complex application written using one of VueJS or React and onboarding someone completely green into it. Adoption is about "how easily can I incrementally adopt this technology into my legacy app". And the problem is that React is nearly unusable without switching entirely over to a Webpack / transpiler system and learning JSX, which makes it almost a non-starter for someone who isn't planning a major rewrite of their legacy app front end. By contrast VueJS "just works" after dropping a simple JS bundle into a page and the first templates you write are barely distinguishable from regular HTML. You can start by just enhancing the odd page element here and there, and slowly build up to a fully based VueJS app.
Not just learning, JSX/React.createElement approach is the hell itself, it increases the technical debt every time you use it, but some people prefer to make a blind eye to this. When juniors come to work with React I guess it makes them think that React way is the only way, but it's more like the 10 years old PHP code.
Let's imagine that for some reason in 2-3 years there will be a silver bullet like framework. So most likely hipsters will be going to switch to it and I'd like to see how they will be cherry-picking all the template's parts from the JS/JSX code to the single holistic template (I don't think the sliver bullet like framework will follow the mixing template with code ideas).
The single best argument for vue is that we should not support large internet monopolies. vue is so awesome even more so once you realize that it is basically driven by a single person
Actually my major complaint of React is the state of state. There seems to be no common knowledge about how to do this right. I just joined a team that has two React projects that development started about two months ago (I just joined like a week ago). There is a a large component that I am working on that is completely bound to Redux. There are major state update issues and the team had opted to assign IDs and data to the DOM elements and use those to look up state in the redux store before modifying it. On top of all that, the application is completely unable to handle 2 instances of any component they wrote. I am trying to re-write some of it to encapsulate the state in at the component level. It's pretty awful compared to the Angular (not AngularJS) app I recently rolled off of.
Edit : Also wanted to add, while I think a lot of people really don't like JSX, I actually do like it but I think someone could take that aspect and come up with a better state management system outside of redux and friends. I think something along the lines of Angular (not AngularJS) with JSX would be great.
> There are major state update issues and the team had opted to assign IDs and data to the DOM elements and use those to look up state in the redux store before modifying it.
This sounds awful and seems like an anti-pattern. I don't think this anything to do with React (other than perhapps that React gives you the freedom to do things wrong). Your devs don't have a proper understanding how React (or Vue) works. Define state model, define view, modify/interact with state, let React modify view. That way you'll never need dirty hacks like fetching state from Redux by using the DOM ID.
Everyone talks about react, angular and vue.js. How about Polymer?
What are your experiences with it, if any? I'm no expert in either technology, but Polymer seems much more lean, needs no build process as far as I know, and is quite flexible.
Why wouldn't it be an option to replace react/angular/vue? Any thoughts?
It is an option to replace other frameworks - I've built an SPA with it, it was very clean and natural feeling to me.
Building Polymer components is very similar to building Angualar 1.5 `component()`s or react components (or actually any component system for that matter).
New elements are true DOM nodes which is quite an advantage in my opinion.
You can add redux/uniflow on top of that or some vdom lib like preact too if you need that - I wonder what will come out of `lit-html` that is supposed to be vdom alternative.
One interesting thing one should understand that applications view components that are not meant to reusable should NOT use Shadow DOM (just regular DOM)- this way you can use bootstrap or whatever else to provide "traditional" styling of your application.
BTW I think right now Polymer also requires a build process - because 2.0 is written in ES6 so that means building to support older browsers like IE10/11.
I experimented a little bit with Vue. I was a little bit disappointed about two points:
1. I couldn't CSS style a Vue component. I find components very important and they should behave like HTML elements. It should be possible to write a <video> element in Vue if that element didn't exist.
2. I find the state management Vuex somewhat an afterthought. Some people say you will know when you need state management, but I think if the integration of state management is really seamless there is no need to avoid state management even for the most simple apps. So don't listen to these people and start with Vuex straight away, even if it takes a little bit more effort.
I'm sure that there are more points for an even better solution. However for the moment Vue seems to me the simplest, the most elegant and most intuitive framework. So I will use it for my future projects.
In React, everything is just JavaScript. Not only are HTML structures expressed via JSX, the recent trends also tend to put CSS management inside JavaScript as well.
for me this is the deal breaker, just JS should be enough.
The conciliatory tone is refreshing - as a community it doesn't have to be a "Vue vs. React" death match. Both are reasonable approaches that incorporate some pretty dope technology in slightly different ways.
For what it's worth, I tried Vue first and ended up moving to React and it just seems to click better with me. More/better libraries too. Nothing on the Vue side of things is as good as Material UI.
I don't know how I missed this one, but it actually looks great. A lot of others I've looked at either has performance issues or doesn't really conform to MD very well. At least from the demo site, that doesn't appear to be an issue here.
Vue is heavily dominated by Chinese, there is a ton of MD implementations, but hard to judge. One solid MD implementation in vue is https://vuetifyjs.com/ which is not Chinese.
Vue is good for simple things. But it do not shines for complex apps and sometime makes it even harder than it should be.
React can appears complicated when beginning, but it pays off on complex apps.
People keep on saying this, but I've written complex apps with both Vue and React (using state stores) and there don't to be any apparent scaling differences. They even use the same component model (virtual DOM, props down, events up).
There are some claims that Vue uses two-way-binding which is unmaintainable, but v-model isn't true two way binding and is just syntax sugar for builtin tags: https://v1.vuejs.org/guide/forms.html
With React, you would have to explicitly write the event handler/setter out, and some may prefer explicitness (but again, there's nothing stopping you from doing the same with Vue).
Vue just has some nice features (computed properties, better style scoping, etc) and different methods for inheritance/templating (but you can use ES6 classes and JSX if you want to), and like somebody else mentioned, is plug and play (yes, you can technically write React render functions without a transpiler, but do you want to?) while Vue (with the template compiler bundled) lets you write templates with HTML attributes using just a script embed.
There are a bunch of other arguments that are more nuanced (ecosystem, bus factor, etc..) but from what I've experienced, Vue is no worse at scaling than React simply because they share the same conceptual model.
Sounds like I'll have to try it out! Definitely don't want to put all my eggs in the React basket with all the patent stuff right now so would like some experience of the alternatives.
If you use single file components, there are some common compile time checks by default for the render function, but I'd argue that type checks are not as necessary as in JSX (which you can use with full type checking in Vue) due to separation being encouraged.
If you are using uncompiled components (newbies using script embeds) with no build step at all, there are clearly no compile time checks. IMO this is why Vue is significantly more newbie friendly.
This is totally not true. It depends on how you structure your project. Vue is good for simple things but it scales way better for large complex apps than React.
Why? Less boilerplate. And less boilerplate = less code to maintain. Vue HTML template functions are really well designed with just enough functionality to make your life easier but also encouraging you to build custom components when you need something custom :)
My only suggestion for people starting with Vue is to not be afraid of directives (Vue directives are nice and have nothing to do with Angular directives), group your .vue components into directories and don't jump into Vuex right away (same goes for React beginners, don't force yourself to learn Redux for your 1 page app).
you should try mobx + react for 'local' state management. mobx provides something similar to vue (MVVM), and the amount boilerplate becomes somewhat like vue's
Sorry but that's not true. We have a pretty heavy VueJS application in production with like 500 components and it's a pleasure to work with, and is still quite performant.
This is the impression I get, but I've not got any Vue experience to back it up so it's literally just based on first impressions.
I completely agree that React can feel like overkill for simple stuff, but really shines as the apps get more complex - complexity feels a lot more manageable.
For example, I built this in-browser Illustrator-inspired site/app using React and couldn't have imagined doing it without (in terms of making managing state and reasoning about things easy as the app grows more complex): http://f37foundry.com (the type tester on the desktop homepage, apologies for limited browser support!). Curious if you could do that sort of complex app with Vue.
> please visit this site using some recent version of [browser that sends all your data to Google]
slowclap
If using a JS framework means you don't have time to test your website in more than one browser, I'll happily continue writing plain JS (or better yet, no JS).
It's just the type tester element which is not accessible with browsers other than Safari or Chrome, because there's quite a lot of CSS trickery/hacks to make it work which didn't work in Firefox.
As mentioned in my other comment, due to the target audience it was decided that it wasn't worth the investment to get it working on other browsers right now, but the rest of the site should still work.
Not React's fault, just a lack of time/budget and a lack of native browser support for advanced typography.
Managing the state and rendering of all the text items as the user manipulates them (this is on the desktop "type tester" homepage, not mobile) - essentially trying to build a "desktop-class" (to some degree!) experience à la Adobe Illustrator.
The rest of the site is pretty basic granted. Maybe it's not a great example, but it's the sort of thing that could have easily become unmaintainable in the old days as features were added quickly, but React and the component model (and MobX) made it much more manageable even as I hacked things in last minute ;)
Cheers, I intend to try it out. Curious to see how their React Native equivalent works, huge selling point for React IMO but I should try the alternatives!
I mean for the simple use cases like adding some validation to a form or a simple widget on a site. But in my experience, these projects usually grow to the point where you are glad you went with React. Personally I'm a huge fan and build things with it I couldn't have imagined doing a few years ago, so I hope all this patent stuff gets resolved/blows over.
I’m curious, how did you manage to build a website that claims to work in Chrome, but not in Chromium? In Safari, but not in Firefox?
And worst of all, it actually obviously works in Chromium and Firefox, but you just check the UA.
Works:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36
Doesn’t work:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/60.0.3112.90 Chrome/60.0.3112.90 Safari/537.36
I mean, sure, if you want to build a site that relies on ridiculous UA testing, and breaks everywhere, sure.
But not even in the "works best in Netscape" era did people actually intentionally break their pages in browsers where it actually worked. This is a new low. This is completely ridiculous.
Proof: http://i.imgur.com/YlPE77b.jpg Oh, and as you can see, if I spoof the UA in FF; it actually works fine. This is completely bullshit, and I’m sure I’ll never do business with you. This is completely ridiculous, leaving out major browsers (and, for example, over 40% of the desktop browsing market in Germany) intentionally and unnecessarily.
Ultimately this was a client project with a fixed budget and timeline so a decision had to be made between extending browser support and adding more features.
Given the target audience (graphic designers, the vast majority of whom are on Mac and will use Safari or Chrome, as I validated from stats on other sites I've built), the decision was made to focus work on the type tester on those browsers.
The rest of the site should still be accessible with any browser, but we decided it was better to not show the type tester at all than have a broken experience (which was the situation with Firefox).
Anyway, hopefully that justifies it somewhat - I think it was the right decision all things factored in. There's a lot of CSS trickery/hackery to make the type tester work (native support for advanced typography stuff is poor) so making it x-browser wasn't easy. The messaging to users of other browsers could probably be improved though :)
> Anyway, hopefully that justifies it somewhat - I think it was the right decision all things factored in. There's a lot of CSS trickery/hackery to make the type tester work (native support for advanced typography stuff is poor) so making it x-browser wasn't easy. The messaging to users of other browsers could probably be improved though :)
It doesn’t even work on Chromium, in the same version as Chrome. There is literally no excuse for that, it’s literally the same browser engine.
On top of that, even back in the "best viewed on netscape navigator 4.0" era there was a solution for this: Show a message that it was only tested with browser X, and that your client was too cheap to pay for anything else, but at least allow the user to bypass that.
As said, the excuses convinced me even more to never do business with you.
This is behaviour that's harmful to the web as a whole.
The loop of "everyone only uses chrome" → "I only need to support chrome with my website" → "nothing works on firefox, I'll switch ti Chrome" is harmful to the entire internet industry, and the startuo economy.
It is harmful to all of us, and hurts all of our future.
I am getting more aggressive because the other person completely ignores the effects on the surrounding ecosystem, and does not even consider a solution that would provide a compromise, as the "optimized for chrome and safari, ignore and use anyway" button would provide.
I see their situation, and their limits, but this is a very egocentric opinion that completely ignores the effects on the rest of society, which is an issue that's just all too common (see also monopolistic effects, or environmental effects, etc).
Good point about Chromium, I'll change that - it wasn't deliberately excluded. But disagree about the messaging, in this case it was more important to the client that the feature worked as smoothly as possible than that everyone could see it. In some cases I'd disagree, but given the narrow target demographic (and their browser choices) here, I think it was a reasonable choice.
Not knowing much about either one, I find 'scaling down' very appealing. I recently did some work with Angular 2, and found it very distasteful because of the big learning curve.
Dunno if it's just me, but I read these Vue articles and all I see is a bunch of hypocrites with an identity crisis, criticizing React for fragmentation, Angular for having 'one Right Way'. So they're better than React for offering one Right Way, then they're better than Angular for offering fragmentation? I mean, jeez, pick one stance and stick with it.
I checked React, didn't like JSX, then I find out about vue, and after an hour or two into its guide, I am completely hooked. Especially love the fact that you don't need a compiler, or a node installation. Although single file component looks very nice, I don't want to "bring in a whole jungle just to have a banana".
It's because of the recent decision by Apache Software Foundation to prohibit using Facebook's "BSD+patent" license in their projects. Many people are now on the hunt for alternatives because of the licensing issue.
If anyone is interested in more Vue talk and some back and forth, check out the VueJS subreddit here: https://www.reddit.com/r/vuejs. It's probably the most active VueJS community online.
This part of the documentation is pretty unchanged for the last 6 months I think, how come it gained so much attention today?
We've been using Vue instead of Angular 2 and we are pretty happy with our everyday work. So +1 for the VueJS team.
So Vue is based on the same Virtual DOM as Elm, or its own implementation? Do non-react tools in this arena still have react-like lifecycle hooks, or different ways of handling "on mount" behavior, for example?
I would say that experience-defining tools are webpack-dev-server with hot reload, ability to use modern ES features and type definitions via TypeScript or Babel+Flow.
These are available for both Vue and React. Is there something on top of that available for Vue?
As someone who has been maintaining a growing React/Redux app for a while now, this one has kept me up at night.
The main arguments in favor of Vue.js revolve around the idea that it is easier for new developers to understand; that people can pick it up and immediately be productive, with React/Redux being much harder to understand. As someone who wants to onboard new developers onto my project, it makes me wonder if I need to look into a switch, if not for my current project then for the next one.
A lot of the commonly touted differences are either a wash, or are only benefits for very small applications with perhaps a single developer. These would be Templates vs. JSX (This is a wash, they're the same thing, but this maybe even favors JSX for large applications), running Vue.js without a build system (you will want a build system regardless for any production application), "Two-way data binding" (Fools gold, will cause horrors if you ever use watches, you will end up hoisting almost all of your data to Vuex anyway in a production application) and "Single-file components" (Really skeptical that this will make a difference in development vs. any other organizational strategy). I can expand on any of these, but they've already been discussed to death.
+ Where I think Vue.js is actually superior to React:
Vue.js is quite opinionated and clear on where to put both data and computed properties. That's basically it, but it's a huge difference.
React itself is very hand-wavy about where to put data and how to interact with it; it basically leaves the problem for someone else to solve. Even Redux, which is designed specifically to store application data, has a weird interface to connect your data to the React application and has no opinion on where to put computed properties. React-router suffers from this same problem as well; you basically end up looking for blog posts on Medium to figure out how to construct an actual SPA out of these components.
This is a gigantic failing of the React ecosystem, and I think this represents almost 100% of the perception (or perhaps even reality) that developers understand Vue.js better than React.
+ Where I think React/Redux is still better
The React ecosystem takes a lot of inspiration from functional programming; it prefers "immutability" and pure functions whenever possible, and I think this becomes increasingly valuable as your application grows; not just for enormous applications, but even for medium-sized applications.
Even if you're exercising maximum discipline with Vue by hoisting your state to Vuex, you've still got many opportunities to create difficult bugs based on the mutable state. Are you sure you're not referencing mutated state in one your actions? Does one of your components hold onto mutable state in order to do a custom transition or animation? If you're using watchers, you're really risking some dangerous bugs here. Now, I know you probably won't do something silly like this, but as your development team grows and you can't code review everything going in anymore; can you vouch for everyone on your team not to make a subtle mistake with a mutable reference?
React/Redux also enables a few very useful patterns that Vue/Vuex doesn't offer at all. For example, the famous optimistic application is nearly a first-class use case for Redux, but would be quite difficult to implement in Vue. This doesn't matter for small applications; it does matter for large applications. Will it matter for your medium application? The same thing about Isomorphic rendering; Redux was built with this squarely in mind. It won't matter for your small app; are you planning for your app to be small forever?
Finally, because it is all Javascript, I think React/Redux has a much better ecosystem of tooling. That includes both linters and transpilers; for example, writing Vue in typescript isn't especially natural, but it works great with React/Redux. When considering my own purposes, effectiveness with Typescript is one of React/Redux's greatest advantages.
In summary, I would still maintain that React/Redux is better for medium to large applications than Vue, due to its commitment to pure JS and the inspiration it takes from functional programming. However, I definitely see the appeal of Vue.js, and I wish that the React ecosystem would take a note on how to provide clear opinions for developers.
Oh if only mentioning mithrils name would be enough to explain it's benefit I think a lot more people would be using it, but we need to do a bit better than that. Mithril is one of the few libraries that really embraces JavaScript and the beauty of a clean abstraction and lean API. There's no heavy learning curve, just learn a couple of method signatures, and you're ready to go. Once you need to do something advanced or use a third party library mithril won't be in your way! I still haven't seen anyone happily go back to react or vue for that matter after experiencing mithril.
For anybody looking into vue.js for the first time, I highly recommend starting with Laracasts series of screencasts which I found much more helpful than the information on the vue.js site itself when I was getting to grips to with it:
I would go with react just because it is more popular. Unless you are someone with free hand picking a technology that is more widespread (hence more in demand) is in this era the wise choice to make.
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.
http://markojs.com/
> 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
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.
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.
https://msdn.microsoft.com/en-us/library/system.windows.cont...
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.
http://objectivism101.com/Glossary/Idealism_Pragmatism.shtml
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.
https://facebook.github.io/react/docs/lists-and-keys.html
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:
What's wrong with looping this way?:> What's wrong with looping this way?
The problem IMO is that it's harder to read and write than:
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
is less readable than 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:
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.
https://github.com/marko-js/templating-benchmarks
Check this presentation about Marko, I found it illuminating.
https://www.youtube.com/watch?v=i6eZA8Y_GgA
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.
Seriously.
``` $ mkdir foo && cd foo $ marko create xyz $ cd xyz $ npm start $ open http://127.0.0.1:8080/ ```
Follow along with the docs / tutorial and then humor me and run the following:
``` $ npm start $ curl -s http://127.0.0.1:8080 | wc -c 5388
$ NODE_ENV=production npm start $ curl -s http://127.0.0.1:8080 | 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.
https://npm-stat.com/charts.html?package=react&package=vue&p...
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.
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:
It's surprisingly common, and it's listed not too far down on the React installation page:https://facebook.github.io/react/docs/installation.html
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%:
https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#W3...
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).
:P
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.
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...
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.
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 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.
Yikes
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
Or YUI
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 would also check this
https://insights.stackoverflow.com/trends?tags=angular%2Crea...
Another chart worth viewing:
https://www.hntrends.com/2017/july.html?compare1=React&compa...
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.
you couldn't expect that article to be entirely partial
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.
https://github.com/vuejs/vueify/issues/35
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:
https://jsfiddle.net/j2sxgat2/2/
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.
https://codepen.io/Kradek/pen/JyLPaL?editors=1010
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:
Then in the template the option line becomes 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.
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:
For a single expression some of it can be omitted:
But I gues thats not really better.I'm hoping jsx will eventually default to `do` expressions though, and then it becomes
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.
https://vuejs.org/images/vue-component.png
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
In a way VueJS is "React for those who liked Angular1".
I've done many Angular apps. I've done a bit of React (with Reflux & Browserify).
I tried moving to React/Redux/Webpack but it's not an easy task to grasp the whole thing. Webpack itself was close to make me throw the towel on side projects.
I tried VueJS because of a job interview and quite liked it and got productive really fast thanks to good documentation and my previous experience in angular & React.
Professionally I wouldn't mind any of those but for side projects it will be VueJS from now on.
As a side note I don't get why all the boilerplates always mix backend and frontend code and dependencies. If you're not interested in a node backend and learning it's overwhelming.
The worst thing is that boilerplates you find are always outdated (router, hot-reloading etc) and worst of all mingling server and client deps so if you're not interested in a node backend you have to
If I was reading your post 3 months ago, I would completely agree with you. But learning React/Redux and Webpack is not that hard at all, just focus on one and move on to the next. WebPack is dead easy IMO, Redux is just an design concept, but it's easy to implement as well. I think sometimes developers over hype technology and make it sound incredibly hard, when in fact is just isn't.
React itself is simple but having a whole project with React/Redux and a full fledged Webpack/Babel config managing dev and prod build is really not simple IMHO.
And, once you have all that working, staying up to date without bugs due to version mismatches can be a real pain.
I feel like a broken record, but definitely take a look at create-react-app if you haven't already. Its extremely well documented and takes care of managing the 20+ dev dependencies that are typically associated with a project.
It's useful but doesn't take care of state management AFAIK which can be a big part.
And likewise I feel like a broken record, but try MobX instead of Redux. Much quicker to get started.
Another option that is interesting right now is Polymer 2.x if you haven't tried it recently, give it a shot.
https://vuejs.org/v2/guide/comparison.html#Polymer There are some similarities shared between polymer and react/vue (personally only used react and angular 1.x before).
I've built applications with it using polyfills and things worked just fine with legacy applications on IE10 + jquery interacting with web components.
Performance is nice, there is more and more adoption from giant enterprises like Netflix, IBM, GE, Gannett, Electronics Arts, CocaCola, ING, BBVA.
Webcomponents.org has over 1k components to choose from and is growing.
Now with `lit-html` arriving soon we might see alternative to JSX if someone wants that, polymer-redux or polymer-uniflow is available as an option too.
https://hnpwa.com/ - one of fastest Hacker News implementations is based on Polymer - and that is even without SSR.
SvelteJS also seems nice, although it seems one-man project for now :( On Polymer end I hope that on the summit next week they will announce proper NPM support finally and I miss that.
I used Polymer 2 to build a couple of highly used internal web components recently. And I'm currently in the process of ripping it all out. Why? It's not technically Polymer's fault, but the performance and stability on iOS and Safari are complete crap. Often crashes the browser on both desktop and mobile.
Also, the Shadow DOM is one concept that I liked in theory and hated in practice. Made it very difficult to do very simple styling tasks that were accomplished easily with plain css and proper naming (e.g. having parent components provide default styles for child components).
The polymer bundler in 2.0 is a buggy mess (it's still in beta) and I couldn't find any decent way to use Webpack with Polymer.
Many other complaints about Polymer that I won't go into. It's way too green in my opinion and I'd recommend avoiding it for at least the near future.
I got into same problem you had - the trick is to have view/parent components not use Shadow DOM - then you can use normal css styling, or alternatively prepare a `shared-styles` file that will contain styles shared across elements.
IMO having everything inside Shadow DOM is an anti-pattern.
I use my own pipeline based on gulp so I don't know much about polymer bundler, webpack support was recently added though, I haven't used it yet.
I can vouch for SvelteJS. It's simple & has near vanillaJS performance.
I use SvelteJS on both the client & server side. SvelteJS also has a rehydrate feature, which allows you to render html on the server & then bind the Component on the client.
There will be talks about SSR with web components on https://summit.polymer-project.org/speakers. There is talk by author of SkateJS.
Having 1k components sort of seems like a bug rather than a feature. How does that avoid becoming left-pad hell again and how would you expect any sort of quality control out of that?
Not really (I'm not even sure of a feature of "what" would it be?)- it is not like you have to use any of that - you could make same criticism for NPM, pypi etc. Webcomponents.org is just a repository, nothing more. If you want quality then you just use components backed by reputable authors - I guess that is the universal rule for development in general.
That's sort of my point. Having ten different implementations of, for example, a data table, each using its own variant of what button template it prefers seems like exactly the kind of hole npm dug itself into. That doesn't seem very desirable for a UI framework that is shipped to clients and demands polish.
Sure, you don't have to use it, but it's the main selling point of polymer. It seems nice in theory but npm also seemed nice in theory.
Polymer is NOT UI framework - its "jquery for webcomponents". Companies like Google, General Electric or Vaadin release their own component catalogs with elements - if you want consistency you use that.
But I do agree that too much fragmentation can be a problem.
For anybody looking into vue.js for the first time, I highly recommend starting with Laracasts series of screencasts which I found much more helpful than the information on the vue.js site itself when I was getting to grips to with it:
https://laracasts.com/series/learn-vue-2-step-by-step
These are the things I find to be killer features of React and it's ecosystem:
- React Native (I know there's Weex but it's not production ready, nor as feature rich)
- Streaming server side rendering
- React Relay (GraphQL integration)
- JSX by default. VueJS pushes an Angular-esque template language where I have to learn new syntax, binding concepts, directives and conditional statements.
- Corporate backing
I've used React in very large projects, where these features have been fairly critical. React's licensing is odd but not odd enough for me to ditch it. I'd really hate to see the community churn once again on frontend libraries, but that's JavaScript for you I guess.
> - Streaming server side rendering
This feature appeared in React v16 (which is still in beta). Vue had it long before.
I wasn't aware VueJS had streaming server rendering (and I still can't find anything about it), but React has had it long before v16 via a library (https://github.com/aickin/react-dom-stream)
Apparently my google-fu was failing me. Found the docs on streaming rendering for Vue here:
https://ssr.vuejs.org/en/streaming.html
Thanks for pointing out that it has it.
yea, Vue had it in its core along time ago. Hence another downfall of react... you end up downloading tons of 3rd party packages that Vue gives you by default.
There's also some early/limited support of vue using nativescript, which is more mature than weex.
https://www.nativescript.org/blog/a-new-vue-for-nativescript
On the corporate backing note- Vue has Monterail, Laravel, JSFiddle, STDLib, UpYun, Deepstream Hub, and others to fund a small team.
i was in the same boat as you regards to syntax but in 10 mins you will grasp everything about vuejs.
of all the frameworks, vuejs has the simplest syntax to learn. its no where as complex as angular and way more elegant. also beats jsx in terms of making your code more cleaner and prettier. im never going back to jsx.
Which part of this is clean or pretty?
There are some redeeming qualities compared to say, Polymer. But it's neither clean nor prettyYou can make it cleaner:
Vue allows you to use Pug syntax in your templates, so this can be even simpler:
I'm sorry but that is hideous.
JSX is incredibly simple. Why would you do that to yourself and other devs?
Eloquently put.
And Pug amkes this... cleaner and prettier than JSX? I'm afraid not.
And it's far from being simpler
Doesn't make it either clean or pretty
1) @ is just a shorthand for v-on:*, like onclick,onmouseover,on submit, etc. (ie; v-on:submit is alias ed by @submit)
@click="say_something('hello')"
new Vue({ methods: { say_something (str) { ... } } })
2) : is just a shorthand for v-bind (ie; v-bind:disabled="is_disabled()" is aliased by :disabled="is_disabled()"). and this basically allows you to run pure javascript code inside of it.
3) the only other syntax to know is, v-for and v-if, but thats pretty self explanatory i believe.
<h3 v-if="user.name">{{name}}</h3>
<h3 v-if="!user.name">What is your name?</h3>
<h3 v-if="user.role == 'admin" && user.name == 'james'>hello super user {{name}}</h3>
i like this approach more than JSX where you have several if else clauses mixed into your HTML. it's kind of like pattern matching if you like that sort of thing.
or you can simply do <h3>{{some_message()}}</h3> and just handle the logic inside the some_message() method.
It looks way more complicated then jsx. Why invent v-if etc when JavaScript has those built in.
1) separation of html and js
2) shorter to write and simpler to read
1) v-if is not html. In html if you see <h3 ...> you immediately think, "there's a level-3 header element here". The thought "there's a level-3 header element here if..." is something new you have to learn for Vue.
2) Shorter is not always easier. For example, using quotes to delimit logical expressions makes it easy to make errors. See the misplaced quote here?
> separation of html and js
That's the thing. You do not really separate js and HTML.
There's a weird extension to HTML. There-are JS-like expressions, JS expressions and bindings to outside JS code
It's also neither shoryer to write nor easier to read.
> i was in the same boat as you regards to syntax but in 10 mins you will grasp everything about vuejs.
Not sure about the original poster, but I prefer react/jsx not because it's simpler, but it's more powerful - it's a simple extension to a full programming language. You can do whatever you want with it.
perhaps you might be thinking that you can't run raw js with vue? well you get js and more.
it's just less coding and boilerplate if anything.
vue also optimizes your reactive codes and is faster in many cases. react can get pretty slow and heavy if you don't know what you are doing and trying to debug those situations can get pretty hairy. otoh, i've not seen any similar issues with vue. what vue does with the bindings is really neat.
What's with the hate for JSX? I think handling HTML as data makes much more sense and is much more convenient than dealing with dumb templates or weird DSLs like Vue's or Angular's.
JSX is closer to JS than HTML, which means it annoying to write in some cases. Quick, what does this render as?
It's not as you'd expect - instead, the whitespace after the pipe character is eaten by JSX. This is because HTML is whitespace sensitive, but JS is not, and so to allow indentation, JSX trims whitespace.Here's another -
This does not work - instead, you need to return an array, but the result is ugly - the commas are part of JS, not HTML, and don't appear in the output, but reading this quickly it's hard to see that (the difference is the braces surrounding the block). Vue's 'weird DSL' is HTML (the same is not quite true for Angular's). What you see is exactly what you get. Having a DSL also means you can define your own syntax. Things that are verbose (due to historical reasons in JS), such as iterating over an object, can be made simple -I disagree on your first example: I've historically found the extra whitespace a huge PITA for years. It causes extra "unpredictable" spacing in your design which is usually unwanted. It's only an issue for multi-line prose. React is opinionated here but I've found it's the most useful option.
On the 2nd point, you are partially correct. In general it's a code smell - strongly consider making it a component (in part for optimization). But definition lists are specifically strange: Unlike other repeating elements in HTML they don't have a container element like tr, li, fieldset, etc.
It's funny you bash JSX, which is a very thin XML-like DSL on top of JS, and then turn around and claim that Vue's DSL is HTML
Something tells me JSX is the better DSL.When you make it so that (which is how everyone is writing Vue anyway)
It gets really, really clear that anything not in {{ }}, or attribute not prefixed by @ or : is HTML.What's the difference between :disabled and the regular HTML disabled? Same for ID, etc. How do strings differ from variable names?
The only way I see that as being more "intuitive" is if you're familiar with other templating languages.
JSX is far clearer:
All you really need to know is everything between braces is plain JavaScript, and property names are camelCased....and property names are Javascript property names. Because, well, JSX is a very thin layer on top of Javascript
Good point about the whitespace, but I'd still rather have the templates inside my code than separate the two, mentally parsing two separate languages with different syntax and stitching them together is a lot more mental overhead IMO.
It's a matter of personal opinion, but I guess I'm more used to server-side templating languages, which Vue's looks much more similar to. I have the same problem as you for JSX - I keep trying to read it as HTML, except it's not, and mentally translating it is annoying.
i assure you, you will get over that phase real quickly. you will come to appreciate how nicer it is to write your code this way. because the same thing happened to me.
Your not mentally parsing two languages. Your parsing business logic in js and templating in regular html.
You still have to understand html inside weird jsx code...
If you want whitespace, the proper thing to do is to use HTML entity.
No, that has other implications.
Surely the huge win for JSX is that you can type check it?
I have a Typescript + Angular 1 project. The app logic feels robust as Typescript makes sure I'm using the right identifiers, variables aren't null/undefined etc. The Angular templates are a constant source of annoyance: they aren't type checked and aren't part of automatic variable renaming refactorings.
This is ultimately what makes React the right choice for me. A big part of the whole code=data thing is that code can be typed, which means now your data (markup) can be typed as well.
Of course this only really matters if you use Typescript/Flow.
Wow that is a good point! I have the same experience with Angular.js 1 and TypeScript.
Can someone confirm that you cannot type check Vue.js templates (without using Vue.js JSX support of course)?
I'm not a Vue user but I can't see how they would be type checkable without using JSX.
For the Angular 1 project, I'm thinking as a stepping stone we could introduce JSX templates before migrating to Vue or React later.
Especially that Vue support JSX and can be used without templates.
One of the biggest things React has going for it, other than being maintained by Facebook and having a much larger community, is React Native. You can learn one web framework and now also make compelling, real native apps. To me those are both deal makers.
Surprised I haven't seen this mentioned more in the thread.
Or you can just compile any HTML5 mobile app using Cordova and in 99% of the cases your users won't notice any performance difference between native-app and HTML5 app.
Maybe for extremely simple webapps that might be true, but for any non-trivial Cordova+React based app you can't come anywhere close to the UX you can get with React Native without some extreme engineering effort. I'd much rather eat the cost to port the HTML5 app to React Native instead. Yes, the users DO notice.
Inability to have the same level of control over soft keyboard behavior is one of the top problems with Cordova, IMO.
Source: wrote & maintained a Cordova+React app on iOS/Android for 3 yrs.
Yeah, you are right, I was mostly referring to the performance part. If you need native UI elements or native UI interaction it's harder to do that in a HTML5 app.
I mostly worked on games, where the UI is custom and there are very few similarities to the UI of the OS, so it worked pretty good.
Yup, the marginal convenience advantages to web apps are so minimal compared to the ability to write legitimate native mobile apps.
Vue.js and Angular are complete non-starters for me since they don't have native counterparts.
I agree, there are many competitors to React for targeting the DOM, but there is much less competition for targeting Native. I hope to see more JSX-to-Native engines pop up soon to solve that problem.
Exactly this. In fact (as someone who only knows Swift for mobile dev) learning React was my first step to get into React-Native, so I can make iOS and Android apps.
My #1: download vue(.min).js and you are ready to go. No packagemanager, bundler and what not needed.
You can do the same with react. Unfortunately with either library you are going to want it for any serious project.
This whole "React is complicated" is a strawman.
How is JSX more complicated than any template language?
How are Vue components any simpler than React components?
You can't write JSX without a template compiler (how ergonomic is it to hand write a render function?). It's painful to write React components with just a script embed (this might not be important to you, but it's important for newbies coming from jQuery), while Vue lets you get away with HTML attributes and Vue.extend(). Lastly, Vue's style scoping is superior to anything React has to offer.
What kind of webapp are you writing where adding a compilation step adds too much complexity? I get if you're writing an application that's 95% static with a few moving pieces, but otherwise that argument doesn't hold much weight for me.
Hu?
You can write JSX with just script embed.
..How? You'd just get a syntax error. Embedding a runtime babel compiler isn't mentioned in the docs at all (though I guess it would work albeit killing load performance, but it's not something that you would expect newbies to know, especially if it's not in the docs).
In vue you have forma free reactive data without using shouldcomponentupate. Components are updated when data change and only for the data they binding. You have also local context while react have a global context. Props are reactive ... And many others feature
This actually scares me because I have extensive experience in knockoutjs. It also used a reactive system. The problem was once the UI became sufficiently complicated performance would suffer greatly. If you had a lot of computed properties changing a piece of data could result in a lot of UI thrashing as each of these are recomputed. I'm not sure how Vue solves this problem, or even if it does but overall the architecture was inadequate.
Exactly. I would rather see the community focusing on a standard workflow like ember-cli and angular-cli.
create-react-app and vue-cli are both good tools.
That usually only works well for really small components. Once you're serious about your web app, you'll end up using the whole developmnet Webpack environment in short time anyway.
I happily used Angular 1 for a few things. When it became clear that Angular 2 was the party line, I looked at it and unfortunately found an overengineered framework chasing what React was.
I looked at React, but without a cohesive framework, that ecosystem is just a bit too much of a mess. A gazillion starter app templates that can't quite agree and always seem a little out of date with the fast moving components. JSX is just ugly. At least to me. I regularly use Django templates, so the clean leap to Handlebars-style templates feels very natural to me. Redux is straight up unapproachable to someone new to the concepts, but at the same time it feels like it simply reinvents events and event handlers.
Vue was a revelation. It is simple, cohesive and I feel productive.
I know this is about Vue vs React, but a lot of the things people are saying they like about Vue can be found in Google's Polymer. It's very simple to comprehend and you can make single file components. And it's based on W3C standard web components so you won't be building yourself into future obsolescence. With Polymer 2 components are now built using classes, so your code is clear and 100% native JS. Lastly, the goal of the Polymer team is to get rid of Polymer by advancing web standards, and with 2.0 you can see they are definitely following this approach as Polymer doesn't add much to web components other than ease of use functionality such as template binding and cross browser shims.
I've used polymer and I wasn't impressed. I found it was much slower than Vue and the docs left a lot to be desired.
What was slow about it? Depending on how you use template binding, it should be as fast as anything else.
It's possible he was using Polymer v1, which was pretty slow.
Polymer v2 in a web browser that supports Web Components v1 should be pretty fast, though. But that was only released last May.
It was very slow to first paint around 1.0 which made me use something else. But it's become so much faster since then.
This discussion might just get a lot of light just cause of Facebook rejecting the licensing issue.
Absolutely. I just checked and vue.js uses the MIT license which would seem to be much more startup (and investor) friendly than the React license.
I used both react and Vue, and I would always choose Vue.js over react. beside all the features Vue has, its the documentation that I really like. it makes you want to read more and more.
Elm is also promising: http://www.oreilly.com/web-platform/free/files/why-elm.pdf
I'm using react and like its functional approaches. I started implementing libraries such as immutablejs, recompose and ramda. I also make use of pure functional components exclusively. Then I had a look at Elm and I realized that, with all the libraries I have put together, I created my own crippled frankenstein'ish version of Elm. I think I really should give Elm a try!
Agree that Elm is a good all-in-one solution for SPAs.
You should also give ClojureScript with the simple React-wrapper Reagent a spin. All the functional stuff is built into the language, like Elm, albeit without the types, which both has its pros and cons.
I don't know why inferno isn't more popular, I use a lot of html5 apis so for what I'm working on inferno is more useful to me than react or Vue. I'm doing webaudio so react native doesn't help me. Also inferno doesn't require me to enter into a patent agreement with Facebook and yet I get all the benefits of react from using inferno. Now if I were needing to use native APIs then I might need react native but then you have to balance that need with the potential license issues
I'm currently investigating Vue to see how it compares to the current React code I have. So far I'm liking it.
The main things that I like so far;
* Single file components - I actually really like this, I find it much easier on my brain to have everything related to a component in the same file.
* The router and data modules - having the router and Vuex as "official" parts of the ecosystem (as opposed to in React where they are "adopted") means that everything just clicks.
* Styling - when I first started out with React, it was a pain to find a nice way to do CSS - do you use modules? Just have files that you import? Inline? Having it automatically scope the styling to the component if wanted, or using modules if thats your thing - is so much nicer than having to think about it. I just add <style lang="scss" scoped> and I don't have to worry.
The only downside I have at the moment, is having to learn the "v-" bindings (which is what put me off Angular when it first came out) but I think that it is something I can live with. Although you can use JSX and have a render method so I might try that and see how that flows for me.
For me, the best thing about jsx is the fact that it's so easy to create different implementations of `React.createElement` to solve different problems outside of the scope of React itself. Want a render function that uses jsx but returns a string, a DOM tree, or something entirely different? Totally possible! I didn't like jsx at first, but the fact that it's so decoupled from React itself counts extremely in its favor, in my view.
For example, for one of my libraries I wanted a really simple way to allow people to include custom templates. I started with string-based templates, but quickly realized that this was inflexible for any kind of event binding or later dom mutations. Achieving that was super easy with jsx -- I just implemented a custom jsx function which directly outputs DOM elements.
Step 1: implement a jsxDom function [^1] which takes (name, props, children) (e.g. https://github.com/krakenjs/xcomponent/blob/master/.babelrc#...)
Step 2: point babel to my jsxDom function (e.g. https://github.com/krakenjs/xcomponent/blob/master/src/lib/d...)
This even allowed some cool hacks like including iframes directly in the jsx, to sandbox sections of the page (since the library is geared towards creating components to be embedded on 3rd party sites):
How are people getting along with Vuex vs Redux?
It looks pretty clean and grokable in the examples and deals with async out of the gate -
https://github.com/vuejs/vuex/tree/dev/examples/counter
Using Vuex has a lot less overhead than Redux and async is super! It's fairly easy to keep modular.
Here's a medium size store for a project I worked on: https://github.com/tmm/notational/tree/master/src/store
Thanks, that looks pretty reasonable.
If you use something like Kea (https://kea.js.org), the amount of boilerplate for Redux goes down dramatically. The syntax is actually pretty simiar to Vuex, perhaps with even less boilerplate.
You've done a nice job with kea. The examples are pretty clear. Somehow the selection of verbs and structure is more readable for me in the vuex example but I'm not sure you could do much about that.
I won't be using this as it definitely sets off my library-depth spidey sense.
The multiple libraries it abstracts would all change versions over time and lead my applications to be even more brittle.
Vuex being mainline with Vuejs is a major plus as I look at its long term stability, though whether it insists on vuejs I need to look into.
Hey, thanks for the comments/feedback!
For the library-depth spidey sense, there's really no getting around that. In a way, as React itself is just the view library, you're forced to add new pieces to your app until it all clicks together. Kea is just one more of these pieces... And I wrote it so the other ones would click together. The alternative to abstracting libs like that is to write and bundle everything yourself, but that is a hard and, in this case, unnecessary path to take.
Two of the libraries it abstracts (redux and reselect) are as stable as a rock. There have been no breaking changes for many major releases. The third one, redux-saga, is a bit more brittle, but as it gets passed direct control over its domain, I don't see how kea would break anything there, at least not in the near future.
Of course I'll do my best to keep up with new releases of all dependencies. I do have a few apps with Kea that I actively maintain.
There's still the chance that Kea itself will change drastically. I hope not. I'm actually trying to stabilise the API for a 1.0 release.
Did not known about Kea, seems nice! However, there are no unit tests??
They are in src/__tests__
Thx, didn't see them at first. Since i like to complain: continuous integration and code coverage with nice badges are missing ^^
Do you happen to know whether there's an equivalent for NgRx?
Go for Ember: - Proven tech - No licensing issues - Solid community - Community driven, no company calling the shots
I was a huge Ember evangelist until I started trying to onboard other devs into my project. It took months for people to figure out which way was up. In comparison, other devs picked up Vue in a week or so.
Interesting, because my company chosen Ember precisely because it would start a hiring wave of new developers, often junior ones. Mostly because of Ember's "convention over configuration".
I dont see much of this problem, including myself as one of these just hired jr devs.
The projects I work typically have very fast turn around times (2-4 months), so I don't have the time to teach a dev use a framework, and I definitely don't have the time to onboard junior developers.
I need a framework where any experienced JavaScript developer can pick up the project and deliver working product in a week. With Ember/Angular/React+Redux, I have to hunt for a developer that specializes in that particular framework. With Vue, the hiring pool is vastly larger.
Exact same problem here. I've written ~20k LOC non trivial web app in Ember and getting someone into the project that didn't had prior experience in Ember was really tough. Then we were thinking about Vue too and like in your example, that person picked up Vue in around a week also.
Same here. Going back to some large ember projects I built just 2-3yrs ago, it's almost impossible to comprehend. Also, it's impossible to upgrade to the latest version of Ember due to the amount of churn they went through from 1.x to 2.x
Vue.js is going to win because simplicity and easier bootstrapping matter. In the same time Vue.js is powerful enough for building the complex and scalable apps.
Onboarding green devs into anything more than a simple Vue app is a lot more complex than a React app of similar complexity, from my experience.
The simplicity of the nested, inception style architecture of React makes it super easy to onboard and up-ramp.
Couldn't disagree more. Or perhaps, more accurately, I think the scenario you are referring to isn't the one that matters.
It's not about taking a massively existing complex application written using one of VueJS or React and onboarding someone completely green into it. Adoption is about "how easily can I incrementally adopt this technology into my legacy app". And the problem is that React is nearly unusable without switching entirely over to a Webpack / transpiler system and learning JSX, which makes it almost a non-starter for someone who isn't planning a major rewrite of their legacy app front end. By contrast VueJS "just works" after dropping a simple JS bundle into a page and the first templates you write are barely distinguishable from regular HTML. You can start by just enhancing the odd page element here and there, and slowly build up to a fully based VueJS app.
> learning JSX
Not just learning, JSX/React.createElement approach is the hell itself, it increases the technical debt every time you use it, but some people prefer to make a blind eye to this. When juniors come to work with React I guess it makes them think that React way is the only way, but it's more like the 10 years old PHP code.
Let's imagine that for some reason in 2-3 years there will be a silver bullet like framework. So most likely hipsters will be going to switch to it and I'd like to see how they will be cherry-picking all the template's parts from the JS/JSX code to the single holistic template (I don't think the sliver bullet like framework will follow the mixing template with code ideas).
CRA or Next.js make bootstrapping incredibly simple, and they're production ready.
Bootstrapping matters more for the сurious and not very experienced individuals, think like Vue is a new jQuery.
It's not uncommon to have Node installed, and it's to easy install if you don't.
But if you find value in dropping in a CDN link, you can use React and Babel that way too.
I'm not writing about my personal preferences, this was the key point:
> think like Vue is a new jQuery
The single best argument for vue is that we should not support large internet monopolies. vue is so awesome even more so once you realize that it is basically driven by a single person
Actually my major complaint of React is the state of state. There seems to be no common knowledge about how to do this right. I just joined a team that has two React projects that development started about two months ago (I just joined like a week ago). There is a a large component that I am working on that is completely bound to Redux. There are major state update issues and the team had opted to assign IDs and data to the DOM elements and use those to look up state in the redux store before modifying it. On top of all that, the application is completely unable to handle 2 instances of any component they wrote. I am trying to re-write some of it to encapsulate the state in at the component level. It's pretty awful compared to the Angular (not AngularJS) app I recently rolled off of.
Edit : Also wanted to add, while I think a lot of people really don't like JSX, I actually do like it but I think someone could take that aspect and come up with a better state management system outside of redux and friends. I think something along the lines of Angular (not AngularJS) with JSX would be great.
> There are major state update issues and the team had opted to assign IDs and data to the DOM elements and use those to look up state in the redux store before modifying it.
This sounds awful and seems like an anti-pattern. I don't think this anything to do with React (other than perhapps that React gives you the freedom to do things wrong). Your devs don't have a proper understanding how React (or Vue) works. Define state model, define view, modify/interact with state, let React modify view. That way you'll never need dirty hacks like fetching state from Redux by using the DOM ID.
Maybe a bit off-topic, but not so much IMO.
Everyone talks about react, angular and vue.js. How about Polymer?
What are your experiences with it, if any? I'm no expert in either technology, but Polymer seems much more lean, needs no build process as far as I know, and is quite flexible.
Why wouldn't it be an option to replace react/angular/vue? Any thoughts?
It is an option to replace other frameworks - I've built an SPA with it, it was very clean and natural feeling to me.
Building Polymer components is very similar to building Angualar 1.5 `component()`s or react components (or actually any component system for that matter).
New elements are true DOM nodes which is quite an advantage in my opinion.
You can add redux/uniflow on top of that or some vdom lib like preact too if you need that - I wonder what will come out of `lit-html` that is supposed to be vdom alternative.
One interesting thing one should understand that applications view components that are not meant to reusable should NOT use Shadow DOM (just regular DOM)- this way you can use bootstrap or whatever else to provide "traditional" styling of your application.
BTW I think right now Polymer also requires a build process - because 2.0 is written in ES6 so that means building to support older browsers like IE10/11.
I experimented a little bit with Vue. I was a little bit disappointed about two points:
1. I couldn't CSS style a Vue component. I find components very important and they should behave like HTML elements. It should be possible to write a <video> element in Vue if that element didn't exist.
2. I find the state management Vuex somewhat an afterthought. Some people say you will know when you need state management, but I think if the integration of state management is really seamless there is no need to avoid state management even for the most simple apps. So don't listen to these people and start with Vuex straight away, even if it takes a little bit more effort.
I'm sure that there are more points for an even better solution. However for the moment Vue seems to me the simplest, the most elegant and most intuitive framework. So I will use it for my future projects.
One of the biggest selling points for single file components is styling (with optional scoping): https://vue-loader.vuejs.org/en/features/scoped-css.html
If you need to override child component styles from a parent (bad idea in 99.999% of cases), /deep/ would work.
Vue components are second class citizens compared to HTML elements, because you don't style them, you pass them props.
This idea with stylable components is for a different framework, perhaps.
what? vue does all that. i don't think the op tried vue at all, lol.
Vue.js is like perl. Too many ways to do a single thing
Out of curiousity, examples?
They bait newbies with their easy data-binding and switch them to components later.
This is exactly my concern with Vue, the API is huge! One of React's strongest points is the tiny API.
That's a good thing.
The conciliatory tone is refreshing - as a community it doesn't have to be a "Vue vs. React" death match. Both are reasonable approaches that incorporate some pretty dope technology in slightly different ways.
For what it's worth, I tried Vue first and ended up moving to React and it just seems to click better with me. More/better libraries too. Nothing on the Vue side of things is as good as Material UI.
There's also http://vuematerial.io
Vuetify is better IMO: http://vuetifyjs.com
http://www.muse-ui.org/
I don't know how I missed this one, but it actually looks great. A lot of others I've looked at either has performance issues or doesn't really conform to MD very well. At least from the demo site, that doesn't appear to be an issue here.
Vue is heavily dominated by Chinese, there is a ton of MD implementations, but hard to judge. One solid MD implementation in vue is https://vuetifyjs.com/ which is not Chinese.
I've used this one a bit actually. Seems alright, but the performance isn't great. It's a bit laggy even relative to Angular material 1
Vue is good for simple things. But it do not shines for complex apps and sometime makes it even harder than it should be. React can appears complicated when beginning, but it pays off on complex apps.
People keep on saying this, but I've written complex apps with both Vue and React (using state stores) and there don't to be any apparent scaling differences. They even use the same component model (virtual DOM, props down, events up).
There are some claims that Vue uses two-way-binding which is unmaintainable, but v-model isn't true two way binding and is just syntax sugar for builtin tags: https://v1.vuejs.org/guide/forms.html With React, you would have to explicitly write the event handler/setter out, and some may prefer explicitness (but again, there's nothing stopping you from doing the same with Vue).
Vue just has some nice features (computed properties, better style scoping, etc) and different methods for inheritance/templating (but you can use ES6 classes and JSX if you want to), and like somebody else mentioned, is plug and play (yes, you can technically write React render functions without a transpiler, but do you want to?) while Vue (with the template compiler bundled) lets you write templates with HTML attributes using just a script embed.
There are a bunch of other arguments that are more nuanced (ecosystem, bus factor, etc..) but from what I've experienced, Vue is no worse at scaling than React simply because they share the same conceptual model.
Sounds like I'll have to try it out! Definitely don't want to put all my eggs in the React basket with all the patent stuff right now so would like some experience of the alternatives.
> lets you write templates with HTML attributes
that's somewhat bothersome... does it typecheck on compile time? hope vue works on typescript-language-specs compliant plugin...
As for react, there's TSX (typescript-jsx) that works great (typechecks on props, state, etc.), but I haven't tried it with vue.
If you use single file components, there are some common compile time checks by default for the render function, but I'd argue that type checks are not as necessary as in JSX (which you can use with full type checking in Vue) due to separation being encouraged.
Type checking for props and state inside the <script> tags is fully supported: https://vuejs.org/v2/guide/typescript.html
If you want type checks for inline <template> code (which isn't suitable for anything non-trivial, you should use computed properties or methods instead), see https://github.com/DanielRosenwasser/typescript-vue-tutorial
If you are using uncompiled components (newbies using script embeds) with no build step at all, there are clearly no compile time checks. IMO this is why Vue is significantly more newbie friendly.
This is totally not true. It depends on how you structure your project. Vue is good for simple things but it scales way better for large complex apps than React. Why? Less boilerplate. And less boilerplate = less code to maintain. Vue HTML template functions are really well designed with just enough functionality to make your life easier but also encouraging you to build custom components when you need something custom :)
My only suggestion for people starting with Vue is to not be afraid of directives (Vue directives are nice and have nothing to do with Angular directives), group your .vue components into directories and don't jump into Vuex right away (same goes for React beginners, don't force yourself to learn Redux for your 1 page app).
you should try mobx + react for 'local' state management. mobx provides something similar to vue (MVVM), and the amount boilerplate becomes somewhat like vue's
Sorry but that's not true. We have a pretty heavy VueJS application in production with like 500 components and it's a pleasure to work with, and is still quite performant.
This is the impression I get, but I've not got any Vue experience to back it up so it's literally just based on first impressions.
I completely agree that React can feel like overkill for simple stuff, but really shines as the apps get more complex - complexity feels a lot more manageable.
For example, I built this in-browser Illustrator-inspired site/app using React and couldn't have imagined doing it without (in terms of making managing state and reasoning about things easy as the app grows more complex): http://f37foundry.com (the type tester on the desktop homepage, apologies for limited browser support!). Curious if you could do that sort of complex app with Vue.
> please visit this site using some recent version of [browser that sends all your data to Google]
slowclap
If using a JS framework means you don't have time to test your website in more than one browser, I'll happily continue writing plain JS (or better yet, no JS).
It's just the type tester element which is not accessible with browsers other than Safari or Chrome, because there's quite a lot of CSS trickery/hacks to make it work which didn't work in Firefox.
As mentioned in my other comment, due to the target audience it was decided that it wasn't worth the investment to get it working on other browsers right now, but the rest of the site should still work.
Not React's fault, just a lack of time/budget and a lack of native browser support for advanced typography.
False dichotomy. OP could have tested for FF if he wanted to, irrespective of the framework he has chosen.
Personally, I develop Firefox-first and then work on compatibility for lesser browsers like Chrome and Safari.
Of course things have been complicated a bit now that Firefox Focus is out and uses Webkit...
What is complex about the site?
I didn't think it was complex until I clicked on Jagger on the first page. It gave no indication of being editable, or I just missed the clues.
Once you do click it, I'd say the complexity of the site becomes more clear.
Or maybe my reference point for "complexity" is just low.
Regardless, very cool site. Nice work!
Ah yes, I was referring to the type tester specifically :) Thanks, was a lot of work but a good fun project!
Managing the state and rendering of all the text items as the user manipulates them (this is on the desktop "type tester" homepage, not mobile) - essentially trying to build a "desktop-class" (to some degree!) experience à la Adobe Illustrator.
The rest of the site is pretty basic granted. Maybe it's not a great example, but it's the sort of thing that could have easily become unmaintainable in the old days as features were added quickly, but React and the component model (and MobX) made it much more manageable even as I hacked things in last minute ;)
There's a plugin for Vue named Vuex which serves as a single state store just like Redux. It's simple to use and makes things a lot more manageable.
Cheers, I intend to try it out. Curious to see how their React Native equivalent works, huge selling point for React IMO but I should try the alternatives!
what seems overkill in reactjs?
I mean for the simple use cases like adding some validation to a form or a simple widget on a site. But in my experience, these projects usually grow to the point where you are glad you went with React. Personally I'm a huge fan and build things with it I couldn't have imagined doing a few years ago, so I hope all this patent stuff gets resolved/blows over.
I’m curious, how did you manage to build a website that claims to work in Chrome, but not in Chromium? In Safari, but not in Firefox?
And worst of all, it actually obviously works in Chromium and Firefox, but you just check the UA.
Works:
Doesn’t work: I mean, sure, if you want to build a site that relies on ridiculous UA testing, and breaks everywhere, sure.But not even in the "works best in Netscape" era did people actually intentionally break their pages in browsers where it actually worked. This is a new low. This is completely ridiculous.
Proof: http://i.imgur.com/YlPE77b.jpg Oh, and as you can see, if I spoof the UA in FF; it actually works fine. This is completely bullshit, and I’m sure I’ll never do business with you. This is completely ridiculous, leaving out major browsers (and, for example, over 40% of the desktop browsing market in Germany) intentionally and unnecessarily.
Ultimately this was a client project with a fixed budget and timeline so a decision had to be made between extending browser support and adding more features.
Given the target audience (graphic designers, the vast majority of whom are on Mac and will use Safari or Chrome, as I validated from stats on other sites I've built), the decision was made to focus work on the type tester on those browsers.
The rest of the site should still be accessible with any browser, but we decided it was better to not show the type tester at all than have a broken experience (which was the situation with Firefox).
Anyway, hopefully that justifies it somewhat - I think it was the right decision all things factored in. There's a lot of CSS trickery/hackery to make the type tester work (native support for advanced typography stuff is poor) so making it x-browser wasn't easy. The messaging to users of other browsers could probably be improved though :)
> Anyway, hopefully that justifies it somewhat - I think it was the right decision all things factored in. There's a lot of CSS trickery/hackery to make the type tester work (native support for advanced typography stuff is poor) so making it x-browser wasn't easy. The messaging to users of other browsers could probably be improved though :)
It doesn’t even work on Chromium, in the same version as Chrome. There is literally no excuse for that, it’s literally the same browser engine.
On top of that, even back in the "best viewed on netscape navigator 4.0" era there was a solution for this: Show a message that it was only tested with browser X, and that your client was too cheap to pay for anything else, but at least allow the user to bypass that.
As said, the excuses convinced me even more to never do business with you.
Go grind your axe somewhere else... Why would you go off on some random person on the internet when obviously didn't have the relevant context?
Moreover, you failed to acknowledge the points they made in response!
This is behaviour that's harmful to the web as a whole.
The loop of "everyone only uses chrome" → "I only need to support chrome with my website" → "nothing works on firefox, I'll switch ti Chrome" is harmful to the entire internet industry, and the startuo economy.
It is harmful to all of us, and hurts all of our future.
I agree with with you that this is an important issue. However, your aggressive comments that ignore what the other person said may not be helping.
I am getting more aggressive because the other person completely ignores the effects on the surrounding ecosystem, and does not even consider a solution that would provide a compromise, as the "optimized for chrome and safari, ignore and use anyway" button would provide.
I see their situation, and their limits, but this is a very egocentric opinion that completely ignores the effects on the rest of society, which is an issue that's just all too common (see also monopolistic effects, or environmental effects, etc).
Fair enough. I will say, from a strategic standpoint, my hunch is that presenting your case in a less hostile manner will bring you more success.
Good point about Chromium, I'll change that - it wasn't deliberately excluded. But disagree about the messaging, in this case it was more important to the client that the feature worked as smoothly as possible than that everyone could see it. In some cases I'd disagree, but given the narrow target demographic (and their browser choices) here, I think it was a reasonable choice.
How you scale your apps is related to how you architecture your project, not what library you use.
i'd say it's quite the opposite. vue makes complex apps easy to write, where react makes it look complex all the time.
Agreed, the learning curve to build more complex, larger applications in vuejs was considerably less than with react.
> but it pays off on complex apps.
so does Angular
This.
How much simpler than functions as components, that get their props as parameters could it get?
Every example of Vue components I have seen was more complicated...
Not knowing much about either one, I find 'scaling down' very appealing. I recently did some work with Angular 2, and found it very distasteful because of the big learning curve.
Angular - has appeal for "corporate apps," well, because of Angular 1.*
React - has influence wherever Facebook has influence
Vue - took off in China as FB did not bother to proselytize developers there
Dunno if it's just me, but I read these Vue articles and all I see is a bunch of hypocrites with an identity crisis, criticizing React for fragmentation, Angular for having 'one Right Way'. So they're better than React for offering one Right Way, then they're better than Angular for offering fragmentation? I mean, jeez, pick one stance and stick with it.
I checked React, didn't like JSX, then I find out about vue, and after an hour or two into its guide, I am completely hooked. Especially love the fact that you don't need a compiler, or a node installation. Although single file component looks very nice, I don't want to "bring in a whole jungle just to have a banana".
I prefer React. I do like a lot of the ideas in Vue.js, but when it comes down to it I prefer the lower abstraction level of React.
Where React wins for me:
- Higher order components - Stateless functional components - React 16, especially the scheduler
Also I really like building the virtual DOM directly (JSX) but that doesn't seem to be very popular reading the other comments.
It surprises me how this "vue vs react" gets to the first line for the 10th time in one or another form
It's because of the recent decision by Apache Software Foundation to prohibit using Facebook's "BSD+patent" license in their projects. Many people are now on the hunt for alternatives because of the licensing issue.
Let me guess-- you're going to argue that "shills" are behind the quick rise?
Tell why should I?
If anyone is interested in more Vue talk and some back and forth, check out the VueJS subreddit here: https://www.reddit.com/r/vuejs. It's probably the most active VueJS community online.
This part of the documentation is pretty unchanged for the last 6 months I think, how come it gained so much attention today? We've been using Vue instead of Angular 2 and we are pretty happy with our everyday work. So +1 for the VueJS team.
So Vue is based on the same Virtual DOM as Elm, or its own implementation? Do non-react tools in this arena still have react-like lifecycle hooks, or different ways of handling "on mount" behavior, for example?
I'm not very familiar with React, but Vue does have lifecycle hooks that work well: https://vuejs.org/v2/guide/instance.html#Instance-Lifecycle-...
I'm curious Vue.js has always had this comparison guide. Why re-post it now?
I use material design. Angular and React have the best MD libs as of a month ago.
I also make mobile apps. Angular and React have the best native apps as of a month ago.
I use old devices. React and Vue are the most responsive.
Large companies use React on desktop and mobile.
React it is.
i sense there may be a flood of react devs switching to vuejs. once their react projects are finished.
honestly react devs are missing out on how great the vue experience is. it didnt take me too long to see how much better vue is.
I would say that experience-defining tools are webpack-dev-server with hot reload, ability to use modern ES features and type definitions via TypeScript or Babel+Flow.
These are available for both Vue and React. Is there something on top of that available for Vue?
https://nuxtjs.org/. here you get all of that out of the box
A lot of people don't know about RactiveJS https://ractive.js.org/. Which I think is better and easier to use then most.
Vue feels like a framework written by AngularJs developers. It's not "better React", it's more like better angularjs.
Html templates are a major turn off for me there, and using JSX is not optimal.
As someone who has been maintaining a growing React/Redux app for a while now, this one has kept me up at night.
The main arguments in favor of Vue.js revolve around the idea that it is easier for new developers to understand; that people can pick it up and immediately be productive, with React/Redux being much harder to understand. As someone who wants to onboard new developers onto my project, it makes me wonder if I need to look into a switch, if not for my current project then for the next one.
A lot of the commonly touted differences are either a wash, or are only benefits for very small applications with perhaps a single developer. These would be Templates vs. JSX (This is a wash, they're the same thing, but this maybe even favors JSX for large applications), running Vue.js without a build system (you will want a build system regardless for any production application), "Two-way data binding" (Fools gold, will cause horrors if you ever use watches, you will end up hoisting almost all of your data to Vuex anyway in a production application) and "Single-file components" (Really skeptical that this will make a difference in development vs. any other organizational strategy). I can expand on any of these, but they've already been discussed to death.
+ Where I think Vue.js is actually superior to React:
Vue.js is quite opinionated and clear on where to put both data and computed properties. That's basically it, but it's a huge difference.
React itself is very hand-wavy about where to put data and how to interact with it; it basically leaves the problem for someone else to solve. Even Redux, which is designed specifically to store application data, has a weird interface to connect your data to the React application and has no opinion on where to put computed properties. React-router suffers from this same problem as well; you basically end up looking for blog posts on Medium to figure out how to construct an actual SPA out of these components.
This is a gigantic failing of the React ecosystem, and I think this represents almost 100% of the perception (or perhaps even reality) that developers understand Vue.js better than React.
+ Where I think React/Redux is still better
The React ecosystem takes a lot of inspiration from functional programming; it prefers "immutability" and pure functions whenever possible, and I think this becomes increasingly valuable as your application grows; not just for enormous applications, but even for medium-sized applications.
Even if you're exercising maximum discipline with Vue by hoisting your state to Vuex, you've still got many opportunities to create difficult bugs based on the mutable state. Are you sure you're not referencing mutated state in one your actions? Does one of your components hold onto mutable state in order to do a custom transition or animation? If you're using watchers, you're really risking some dangerous bugs here. Now, I know you probably won't do something silly like this, but as your development team grows and you can't code review everything going in anymore; can you vouch for everyone on your team not to make a subtle mistake with a mutable reference?
React/Redux also enables a few very useful patterns that Vue/Vuex doesn't offer at all. For example, the famous optimistic application is nearly a first-class use case for Redux, but would be quite difficult to implement in Vue. This doesn't matter for small applications; it does matter for large applications. Will it matter for your medium application? The same thing about Isomorphic rendering; Redux was built with this squarely in mind. It won't matter for your small app; are you planning for your app to be small forever?
Finally, because it is all Javascript, I think React/Redux has a much better ecosystem of tooling. That includes both linters and transpilers; for example, writing Vue in typescript isn't especially natural, but it works great with React/Redux. When considering my own purposes, effectiveness with Typescript is one of React/Redux's greatest advantages.
In summary, I would still maintain that React/Redux is better for medium to large applications than Vue, due to its commitment to pure JS and the inspiration it takes from functional programming. However, I definitely see the appeal of Vue.js, and I wish that the React ecosystem would take a note on how to provide clear opinions for developers.
MithrilJS
Oh if only mentioning mithrils name would be enough to explain it's benefit I think a lot more people would be using it, but we need to do a bit better than that. Mithril is one of the few libraries that really embraces JavaScript and the beauty of a clean abstraction and lean API. There's no heavy learning curve, just learn a couple of method signatures, and you're ready to go. Once you need to do something advanced or use a third party library mithril won't be in your way! I still haven't seen anyone happily go back to react or vue for that matter after experiencing mithril.
https://mithril.js.org
I left mithril for domvm. It has a smaller focus and less magic.
https://github.com/leeoniya/domvm
Is there a compiler for Vue components to web components?
I'm worried about forward compability of all this React components I'm building
it seems odd that vuex is part of core but there isn't a default way to do get/post requests. http://jrmeyer.github.io/tutorial/2016/02/01/TensorFlow-Tuto...
These are the threads that are often to the most frustrating to picking anything...
If the licensing is an issue with React, then what about Preact?
Ugh. Vue.js is just Angular 1.
I have to many points associated with this handle. I'd like a 100 or so shaved off
React is for CS-savvy programmers. Vue is for those who like to think of themselves as programmers.
For anybody looking into vue.js for the first time, I highly recommend starting with Laracasts series of screencasts which I found much more helpful than the information on the vue.js site itself when I was getting to grips to with it:
https://laracasts.com/series/learn-vue-2-step-by-step
I would go with react just because it is more popular. Unless you are someone with free hand picking a technology that is more widespread (hence more in demand) is in this era the wise choice to make.
The demand for both React and Vue.js is growing tremendously. There isn't really a wrong choice to make here.
(I would also say the same goes for picking programming languages, as long as it's one of the top ~15, and you stay somewhat flexible.)
There is way more demand for Angular and react than there is for Vue