I do very little web these days, mostly working on backend data processing, network I/O and distributed comms.
A bit over a year ago, I wanted a real-time web UI to visualize some of the data I had on server-side, which I was trying to do using SignalR. I went back through some of the popular frameworks, with a pretty simple mindset of "Can I read the 'getting started', and get something basic working in about 15 minutes?".
I ended up choosing Vue, mainly because it used simple objects for models and I could literally just pass stuff I got from SignalR directly into it and have it show up. Almost everything else I tried had some type of wrapper/proxy around the data, which meant you had to run through some mapping exercise to get models working. I was close to deciding on Mithril, but when I found vue it just clicked with me way more. I actually really wanted to do React, but Vue was just so much more approachable that I couldn't justify spending the extra time learning React.
The real test however came months later, when I went to modify and add more functionality to my simple debug UI. I was able to pick it up nearly instantly, and even made some fairly substantial changes.
Contrast to my experience with say, Ember. We have a big app written in Ember, and every time I try to do even what I think should be a simple change (after not touching it for months), it takes me 5 times longer than I thought, and I end up spending most of the time fighting with it before realizing I forgot one of the 5 places you have to modify to reference an additional dependency, or some other equally trivial but infuriating detail.
You can learn the basics of Vue in minutes, and be quite adept within hours of it. That's something not a lot of frameworks can claim, and it's a seriously underrated benefit.
I have almost the same experience as you. I am maintaining big Ember app and have exactly the same problems as you described with it.I am interested in Vue lately also because it's so lightweight, easy, well structured, documentation is excellent, ecosystem around it is excellent and i have so much more freedom than in Ember. Author really cares about it, issues on github shows that, only 50 open and 3000 closed.
Holy cow this is impressive. How do you think he came to this achievement? Was he marketing himself really well? I honestly would love to know what it takes!
Context: I'm currently developing a new web-based remote desktop tool in Rust and I'm still on the fence as to whether or not to release it open source.
It's a port of some work I did on Gate One that ultimately couldn't be released due to the limitations of X11 permissions in multi-user environments (too insecure).
What's funny is that I'm looking at using Vue for the client!
It is not without a cost, the cost being an lack of standard ways to accomplish things. For long running projects where devs may come and go, having a standard way to do things is an incredible advantage, and will result in a much more consistent code base.
For real world front end project, this is a much more important concern, imho, than ease of picking up. For your particular use case, I agree something like Vue is a better fit.
Long running projects in JavaScript may not be that long really. If you leave any codebase for a couple years, things would have changed so drastically, new devs may not even recognize the code. An year old JS project may be using React, a 2-year-old project could be using Angular, a 4-year old project might be using Backbone, a 6-year-old could have $("#el").bind() all over while 8 year-old project could have been in Prototype.js.
Since I've gone through the same experience like this, I'd like to know if this is a norm :D.
I've seen people do write-up of how they re-write the front-end from jQuery to Angular|Ember|React so it's not like there are many long-running JS projects that require solid structure. 3 years old (small-medium size) projects tend to get re-written.
Here's another one that I've seen and experienced before: 10 years old product where some section of the products are written in pure JS, some section in jQuery, some section in BackboneJS + Marionnete, some section using EmberJS.
I've heard this argument before and I find it fascinating. Why can't we have something that is both standardized and easy to pick up? Is there something inherent to one that blocks the other? Any ideas?
Disclaimer? I don't use Vue, but I've seen this argument made for Ember (against Angular 1.x) and Angular 2 (against React).
>Why can't we have something that is both standardized and easy to pick up?
Simply because one has to learn the standards in the former case. In the latter, it is mostly left to the users imagination and their own sensibilities, which differ from person to person.
But does being "easy to pick up" intrinsically mean things are left to the user's imagination? Can't we make something that is standardized AND easy to learn?
Thanks for sharing your experience. As someone at a place with both ember and Mithril it's relevant to me. Can I trouble you for a couple more details?
Did you use MSX with Mithril? We found Mithril to be usable without MSX but clicked more for people with MSX.
What thoughts do you hear from people who work on the ember app regularly?
No, because it was green-field and I was trying to keep it as simple as possible; having to have a build step to run the MSX tooling was not really worth the complexity.
> What thoughts do you hear from people who work on the ember app regularly?
Mostly frustration, honestly. The main developer (who spends most of his time in Ember, though wasn't part of the team when it was originally built) has more background in Angular, and a number of times has lamented how much easier things are there. Although he's still reasonably productive now, it took months to get to that stage. Everyone else comes and goes, depending on what we're working on, and the general feelings seem to be somewhere in the spectrum between mild frustration and hate.
Maybe another interesting point.. We used to get new hires to start with fixing small UI bugs to help them learn the systems and do something with immediate highly-visible impact. We really can't do that with Ember.
I think if your style/mindset perfectly meshes with that of Ember, and you specifically decide to devote a considerable amount of time (months) to becoming an Ember expert then you can certainly master it and make good use. I'm not sure you'd produce anything better than someone who had the same time and level of mastery of React or Angular or Vue, however.
This is simply my highly subjective opinion, so take it for that, but it was really a number of factors.
Template format.
I actually really like Mithril's view format: it's an API built exactly as it should be -- to make using it very intuitive and natural. I also think it's a great solution technically, since it fluently combines a shorthand for generating HTML with data binding and lets you use native javascript (making it easy to build parts with functions or loops or whatever).
What I didn't like was actually working with it, as a lazy and mainly non-web developer. I like to copy and paste chunks of markup from bootstrap's documentation or other places. Recreating is fine for small things, but then I started porting pieces of another internal app that involved at least a couple hundred lines of HTML. There is(/was) a tool to convert, but it didn't work well enough to be usable for me.
I also realize there's MSX now, but I don't remember it at the time: I'm not sure if the documentation was lacking, or I was just tryin to avoid the complexity of a build tool for this (or both).
For my purposes, the only really fundamental difference between the two was the template format, and being able to stick HTML into Vue, add a couple attributes and have it work just worked better for me.
Community/Growth Potential
I felt the Vue community was bigger and growing more. The Mithril documentation was and continues to be great, but at least at the time there didn't seem to be much writing about it beyond the Mithril site.
Contrast to Vue, where it was easy to find many blog posts, StackOverflow questions/answers, etc.
I've used my share of frameworks/libraries that were later abandoned, and I really try to avoid that.
I write Ember for external apps at A-Big-Tech-Co. but use vue.js for the internal stuff. The difference in readability, code size, and customizability is really starkly in favor of vue.js to me, though ymmv
Agreed. I've been loitering on their github trying to get a read on whether they're planning to do that. I get the impression they'll revamp everything when the 3.0 final release is ready.
Riot is really very poorly advertised and Vue is generally drinking its milkshake in that regard. It's a shame really, not that Vue isn't really neat (because it is), but because Riot is just really lean and productive but nobody knows about it. The vast majority of front-end library comparisons don't even include it.
> I wanted a real-time web UI to visualize some of the data
Got the same problem, but we already went for React/Redux and it wasn't really nice.
I would go for Cycle.js in my future projects. Because everything is modeled as a Observable (no differentiation between data and UI) and it allows to handle real-time data really well (backpressure, etc.)
I want to learn Angular2, but am struggling to find a good source, I want to also build real-time web UI, albeit not for visualization. The problem of documentation is very real. Thank you for the feedback on Vue! I will look at it now.
I found the docs hard to understand. Maybe it is just that the component based concept is difficult to understand for me as a newbie. Anyways, between vue.js and angular, which one do you think is recommended for a newbie to the front-end world?
Angular is more for the entrprise/large apps, if I were you I'd start from the vue.js, it's a relatively small tool, but powerful, not so complex and has a great docs. I've an extensive Angular v1 dev experience and I don't recommend it. Angular v2 is a complex thing, it has many dependencies (it fetches many npm packages) and dev env is more complicated.
hmm I used signalR with angular 1.x and can't speak for your 15 min requirement but I definitely didn't have any need for proxies or model mapping. I suppose if you're using knockout you'd need that (at least call a utility function to translate plain objects into KO objects) but did you find that with Angular?
I actually didn't get to Angular. I put it down on the list because it was while Angular 2 was in alpha, and there was a lot of controversy and uncertainty around it at the time, and it was very unclear from my perspective of which version I should even look at.
Angular 2 was alpha, still changing, and had the potential the community would fork and I'd be stuck on the wrong side. At the same time, Angular 1 was of course 'old', and there wasn't any real migration path yet, so I didn't want to be stuck on the old version and have to re-do everything anyway.
I was happy enough with Vue before I got to actually building anything in Angular, and from reading docs I didn't see anything compelling enough over Vue (in either 1 or 2) to warrant going further with it.
As someone who went through the complete frontend hype-trains (jquery, backbone, angular, ember, react, all in production): Vue.js 2.0 with single file components is exactly what everyone looks for desperately.
- performance: faster than react now
- learning curve: a few hours from scratch
- getting started: cli-tool for initial scaffold & configuration
- components: simple .vue files with a <template/>, <script/> and <style/>. Super easy to get going, no need for JSX
- "official" packages for routing, ajax and state management. No wasting of days for choosing every tiny package for days
- vuex 2.0 is one of the cleanest flux implementation i've seen in the last year
... and much more. Give it a try with the full webpack template of the cli tool!
I went digging through tons of frameworks for a new company project early this year and chose Aurelia. Vue was a pretty good possibility in my mind, but Aurelia gives me a little more bang for the buck. I also think it's much easier to get going with Aurelia than React or Angular. Since then Aurelia has released a new CLI tool and some other significant updates. It's already fast and the code is predominantly straight JS and web standards so it seems easy to pick up again after not looking at it for a while.
I've used both Knockout and Vue for frontends that needed to render reasonably large amounts of disparate elements with near real-time updates, so I think I can answer this. Knockout is nice but feels closer to jQuery in that it requires a lot more discipline on the behalf of the developer to organise and maintain code. Things like ObservableArrays means dealing with another layer of abstraction; the wonderful thing with Vue is that it's just native JS objects all the way down. It also has a better structured child/parent component model with event flow, not to mention being much faster for rendering. I would also recommend Vue over Knockout.
Exactly my thought when I tried Vue.js: on the surface, it's knockout with some react-inspired additions that make it faster. I loved being able to pick up Vue.js and make something that just worked in 30 minutes.
React with MobX, Vue and Knockout all seem very similar. I am wondering if TypeScript is a first class citizen in either MobX or Vue - in my experience seeing TypeScript everywhere in Angular 2 has been one of that platform's biggest wins.
When I first started looking at Vue last year this was my initial thought too. Overall, I think Vue has more to offer, has a cleaner syntax, and is more enjoyable. Some specific things I like:
- With Vue, you don't have to specify which pieces of your data are 'observable'. The entire data object for each component is reactive.
- Vue's getters/setters mean you can interact with your data really easily, no need to invoke properties as methods
- Directives are more readable. Knockout makes you cram everything into the `data-bind` attribute, whereas Vue splits these out into individual attributes( @click, :class, v-if, etc)
I don't think it is. I've been closely keeping an eye on Vue since its first release, and it has really matured quite well and steadily since then. I like to reference Vue with the Crystal[1] programming language, which has looked closely on mainstream programming languages and adopted the good parts of them, like Go's concurrency model, Node's asynchronous I/O, Ruby's clean & straight-forward syntax and object-orientation model and the performance and interoperability with C.
Similar to Crystal, Vue has looked at the other frameworks and adopted the good parts from them. I personally don't think the hype is anything but a result of hard work and a genuinely good framework.
You probably want to give it a bit more time. It takes 1 or 2 years after a js framework goes mainstream for the disillusionment and disappointment to set in. We are still in the Vue.js honeymoon phase.
This is because it takes about one or two years before all the hordes of idiots to abandon the last ship they sank and come swimming full speed towards a new ship to sink.
The unfortunate part is that it's moments like this (when a framework makes it into the spotlight in a big way like this) that those hordes begin their swim.
Evan is an excellent developer, and it won't by through his volition that Vue gets ruined.
No, what happens is a new framework comes out that fixes the complexity problems of the previous popular framework, but ignores why that complexity existed in the first place.
Once the new framework gains popularity the limitations caused by ignoring complexity start to surface and so the framework has to add features to handle them, creating complexity of its own.
See my explanation below my OP. Your comment is correct, but these complexities should not be solved in the framework, lest we forget the vision that drove the creation of this framework in the first place, providing an obstruction layer that doesn't solve all problems at all layers.
Could you expand more on how these hordes of idiots sinks framework by using it? I've never come across a theory about this that's quite so tantalizingly bad before and I'd love you to expound further.
It's easier to illustrate by walking through an example timeline:
1. Framework X is created based on the vision of its founder
2. Lots of people begin to use it
3. X gets better and better (user feedback + excitement of the project's success)
4. X becomes super popular and attracts people from other frameworks
5. More and more contributors begin committing code (helpful, but hard to manage beyond a certain volume), and entropy increases - more bugs start getting through (think Rails, where there were loads of security and data loss bugs in the span of single years)
6. People bring their ideas with them, which is helpful at times, but which also begins to dilute the X creator's vision and replace it with a democratic vision (sometimes good, sometimes bad)
7. Social pressure causes the creator of X to begin changing his vision to accommodate the community
The apex of quality is at # 4, and that's the point we're approaching now. Also worth noting is that this timeline isn't always followed exactly. Take Django, for instance. It was able to keep up with community demands without caving in to too many wild requests, and it managed entropy by keeping the number of core committers to a minimum for many years.
Can't speak for the author of the post you're replying to, but I'd wager it refers to the bad actors you find on GitHub and such where they contribute significant negative equity to an ecosystem.
Keep in mind Vue isn't backed by Facebook or Google, so it'll take longer for hype to set in as Evan You can't market it heavily or organize large conferences by himself.
I read a writing about how SEO isn't an issue with SPAs. (can't find it at the moment)
As far as I know, all major search engines are evaluating JavaScript client-side and index the resulting html, only a chinese one had problems with SPAs.
There was even a site from Google, where you could enter a URL and see how Google sees the page.
I don't have an exact page count, but I was able to find 15 pages from browsing around.
Here's how many pages various search engines have indexed using the query "site:preactjs.com"
Google: 17
Bing: 6
Yahoo: 6
Baidu: 1
One of the Google results is an error page, but it presumably can't be de-indexed automatically due to there not yet being a way of declaring a 404-equivalent in SPAs.
I've also read (I can't recall where) that Google has a latency of a few days when it comes to indexing SPAs compared to server-rendered apps. This may not be a problem for you, but it's worth knowing about.
That seems like an example of a SPA that should really be a static site. Aside from it being the library's main page, why would you even need to implement this with any front end frameworks? I believe the parent post was referencing how companies usually have a static site for marketing/SEO, and the backend application is a SPA. This would effectively remove the need for SEO on an app that requires authentication anyways.
In that context, I agree. If your app doesn't need to be crawled or otherwise scraped, worrying about server-side rendering is just going to hold you back.
But there are public websites with a high degree of interactivity (such as social networks, or ecommerce sites) for which SEO is a huge concern.
Personally it's Angular 2.0 for me. I'm a big fan of Angular 1.0 but can't stand how complex it has become. I want to be able to start using a framework in a matter of hours, not weeks. Most of Angular 2 complexity is unecessary and I write large SPAs ,not toys, but I don't like the noise. I use Go and Python on the server, I don't want to have to manage a Java style application on the client, because that's what it is another version of GWT with Typescript in place of Java.
I highly recommend the angular cli tool. In 2 minutes you have a webpack setup with bootstrap that hot reloads your code . you can even proxy API calls to your real web server. Deploying consists of copying the dist folder . With tree shaking the footprint for angular 2 drops significantly
I actually interviewed with Jacob Schatz when he was trying to figure out which frontend framework to use for GitLab. I had been working in React for the last year or so which was apparent on my resume.
He prefaced our interview with something to the effect of "I know you do a lot of React but we are not going to ever use React at GitLab"
It was weird. I tried to ascertain his reasoning and pretty much all I got was "just because it's popular doesn't mean it's good".
Regardless I think GitLab is an awesome company, I just got the feeling Jacob wanted to use Vue.js because it wasn't the most popular choice. ¯\_(ツ)_/¯
Hi @49531. Sorry you felt that our conversation was weird. Regardless of my opinion of React, Vue or any Frontend Framework, I never want anyone to have a weird interview.
My main feeling with Vue vs. React (maybe this should be a different post, as this post was meant to explain why Vue, and focus on the positives):
1. Vue is minimal to add in with existing code. React, is also not bad, but Vue is much simpler to mix in when you can't do a complete refactor.
2. React has a higher learning curve for large scale. I did not want a DSL. That's more stuff to learn and more things to debug.
3. GitLab's modus operandi has always been to keep things as simple as possible, Vue fits that. React does not.
4. React isn't just React it's many other things that you probably want to include.
I've written very large Vue, Angular and React projects in the past. I never had to think twice about which was the easiest to write a large scale project with. Vue scales well. It's never confusing. That doesn't mean that React is bad, or Angular is bad, it just means that the next time I have a choice I'll just choose Vue.
1. i can't agree. it's possible to integrate React into your application one component at a time. how is Vue "much simpler to mix in"?
2. i think this depends on your background. if you've had the pleasures and displeasures of working through all the trials and errors of jQuery, then Backbone, then Ember, then Angular... React is painfully obvious to work with. because the problems it solves, the ways it solves them, and reasons for doing so are clear. if you're a new JS developer, maybe Vue probably has an easier learning curve. i'm also not sure why we are calling it a DSL when it's entirely plain JS. Vue templating- now that's a DSL.
3. valiant modus, but keep it contextual. simple can bite you in the ass. people don't introduce complexity for no reason (unless they don't know what they're doing, of course).
4. no... React is in fact just React. you can build a working UI without any supplemental React libraries. how is it "many other things" any more than Vue is?
> 4. no... React is in fact just React. you can build a working UI without any supplemental React libraries. how is it "many other things" any more than Vue is?
I don't know if this is what @jakecode's argument is, but the tooling surrounding react builds is pretty bonkers. I can't keep up with the flavor of the week tools, and every single time I say this to someone, they tell me that the holy grail of React build tools is finally out and I just need to check it out. Except that holy grail is different every time the conversation comes up.
I'm not willing to put the build process of my entire app on a tool that's likely going to lose support and maintenance in the near future. It's just too risky and it's a big upfront investment to learn something that's going to be outdated quickly. I don't have the time to integrate something new constantly.
i've been using webpack for like 3 years now. hasn't changed- besides my boilerplate getting smaller over time. it's a 5 line .rc file now. ignore the noise.
if we are making an apples to apples comparison, React does not need any external tooling to stand up to Vue.
Hi Jacob, the interview wasn't weird. Just that aspect of it :).
I get it that implementing a big build process in an existing project can be crazy and not worth the effort, especially since GitLab's frontend lives inside of its rails app.
I wouldn't be concerned about DSL issues with React though, the API is 90% vanilla JavaScript.
I also didn't want to implicate that the Vue.js / React stuff was the reason I didn't get the job at GitLab! The interview process was great and very open.
I recently interviewed with him and did a collab code thing and he personally admitted to being quite rusty as he doesn't write code much anymore and it was apparent by the errors he was making. I'm surprised he was the one leading the decision in what framework to use when the extent of skills seems to cut off around jQuery.
Is it normal in a large company for someone who is now doing managerial type work to be the decision maker in what the tech stack should be for the company? Or rather, shouldn't they make their decision based on a consensus of the developers opinions and research?
Not trying to be snarky, or anything, I work at a smaller/ medium sized company and this is how it's done, so maybe large companies operate different.
it's not uncommon. someone has to make a decision and it makes sense early managers are not best suited to make technical decisions.
as a company or application grows technical deficiencies resulting from bad choices will start to rear their heads and new hires with more experience will hopefully illuminate those issues.
the only reason they chose vue, the article suggests, is because it's "simple". even if I concede that to be true, it is not the most important factor when making technical decisions and you will ultimately end up paying for it.
Is there a name for this "feeling"? I feel this way about a lot of things that get "popular". I feel this way about React, in fact. React is "good" but I don't see it as our end-all be-all front-end savior. Vue.js is a lot more interesting to me because it's not popular...because it's the underdog.
Sure popularity ruins many things. Music, movies, books, software libraries.
However, you don't have to use React. React is a set of concepts. I personally really enjoy programming with those concepts (I just wish it wasn't JS). If you don't want to use Facebook's implementation, there are many other implementations.
I think most people who constantly got this feeling simply didn't outgrow puberty. They just HAVE TO use something different.
But it's okay to look into things and check if they fit you, don't just drink the kool aid. The problem is to have this feeling before testing these things.
Huh. That's disappointing. I was wondering if it had something to do with the license, considering that Gitlab's allure to certain parties is maintaining control, on-premises if need be.
After using React, I am firmly in the #nevertemplates camp. I don't ever want to learn a template DSL again when I could be using the full power of javascript.
JSX is just a way to render data, so think like it's a templater, you can integrate it with any tool. React istelf is also just an advanced templater actually, it has no built-in data reactivity despite the name. In my opinion React is not needed in general and JSX is a back to the old fashion PHP coding (Facebook returns to its roots).
React is not a templater, it's a differ. The only similarity between PHP and React is that you can have tags in ("around" in PHP's case) your code.
Edit: After reading my comment again, I feel I must mention; even that similarity is not coming from React directly. It's JSX. Although they go like fish & chips together (Not a great analogy but I guess I'm hungry).
You give React a state, it diffs that and passes the outcome to the ReactDOM, which can render it on the DOM. At its core React doesn't know what a <div/> is. It just diffs objects and generates instructions to reach the next state (very generally speaking here). The stuff you pass to it is an object and can't be malformed like a string can. Main function of React is maybe loosely related with templating.
For PHP (in its traditional form), everything around the code is just strings, which is also the case for most of the templating engines.
You can't shout "spaghetti code" every time you see XML tags in code. Think Scala or VB.
Haven't tried Vue yet but I like the idea of having a choice. It would seem to me that for most cases one would simply a template since it gets you there easily and without any boilerplate. For the cases where one does need the full power of Javascript, JSX is the solution. I'd imagine that most components would initially be written as templates, and some would be refactored into JSX along the way, which is probably not much of a pain.
You can think of it as sugar for `React.createElement()`, and some other stuff (like spread) but that's it. It's really easy to translate into javascript in your head.
Why is this good?
1. Let's say I want to stick a debugger in my template or render function. How would you do it in Vue? Angular? I don't know, gotta look it up, not even sure if possible. How would you do it in React? I don't have to look anything up, I just have to think (use an iife):
2. Let's say I want to use Immutable.JS instead of plain js arrays. How would I iterate over an immutable list in Vue. In Angular? I don't know, probably have to download some third party directive. React:
will give you formatted json output of the data object (i.e. state/props) In reality you can put anything that's in the Vue object's scope between curly braces, pipe it through the json filter.
>immutable list in Vue
<li class="for-example" v-repeat="item in list">{{item}}</li>
So neither debugger support nor printf-debugging, you just have to hope you'll be dumping garbage in a place where it can be seen and doesn't break the page entirely?
> <li class="for-example" v-repeat="item in list">{{item}}</li>
Ignoring that vue changed the name of the directive a while ago[0] that doesn't even remotely work, according to its documentation v-for (née v-repeat) works on native arrays, it's not going to work in any sensible manner on immutable.js structures.
The nice thing about JSX is that it is an embedded DSL. When you use JSX you can take advantage of all of Javascript: variables, loops, conditionals, subroutines, closures, etc.
The bad thing about most other template DSLs is that they recreate all of these features from scratch, often in buggy ways. For example, many template DSLs have dynamically scoped variables instead of lexically scoped ones.
Native (note this naive implementation lacks proper scoping):
var el = document.createElement('div');
el.className = 'classy';
el.onclick = handleClick;
This has been available on all major browsers for quite some time, React just provides some convenience around it and a sugar for those that prefer code that looks like HTML because people tend to (fairly, imo) associate their HTML with the state of the DOM.
JSX is a DSL for creating HTML, a "language" that has very little custom logic. Vue.js and Angular.js are DSL for creating custom logic, which will always pale in comparison of an actual language designed for custom logic like javascript
Technically it's a DSL, but the experience of learning and remembering it is not the same as your typical DSL because there's so little JSX-specific syntax.
jsx compiles to plain old function calls, which is how you write your templates in elm as well. there's very little difference besides developer ergonomics.
The thing I like about React is that I don't have to think about the DOM. As soon as I see "el: #id" it's basically over for me. I don't want to think about DOM elements, or at least minimize my exposure to them.
And it's not just that I don't like to think about the browser DOM. It's that I don't want my UI coupled to the DOM. Obviously your UI will be coupled to the DOM to some extent, but React minimizes that. What I love about React is not just `react-dom` but also, say, `react-canvas`, or that you can apply the same principles and work with React Native.
But hey, the more software libs to play with and choose from, the merrier! Cheers!
PS. What if you're the kind of person who likes coupling presentation and logic? I really like JSX and inline styles. From my skimming, it appears Vue separates templates and logic. Is that correct?
On the contrary, for most larger apps you'll want to use single file components + webpack. I'm also a big fan of keeping markup, styles, and logic close together and Vue's single file components are one of my favorite features compared to React components:
The only downside is that while .vue files do have editor support in most editors, it's still not 100%. For example there are two plugins for VS Code but neither of them are really usable at this time.
I am more and more of the opinion that you should NOT use a js framework for long term projects (that span more than a few years), but just use vanilla js with some libraries that you can easily switch when something better comes out.
Vue.js is here today, and it is nice, but tomorrow gintzx.js comes out, and the community will be flabbergasted and everyone will use it and vue.js will slowly die.
Making big complex webapps with just some libs is absolutely possible. Just choose them wisely and make a good directory structure.
I'd like to see more standardization efforts, easier way to separate your business logic from the UI layer. It should be possible already, but there's often still too much interference from the framework of the week.
One thing I've been working on lately is writing unit tests (and test runner) that have nothing to do with the underlying framework - no Angular references, no Angular DI, nothing of the sort. Much cleaner and faster, plus it's a more pure unit test because it doesn't test the framework or DI system.
We need the W3C to make a `node.replaceWithJsNode(obj)` or similar that takes a uniform vdom object style and updates the DOM accordingly. It would bring together all the different vdom implementations, reduce library size (given time), and would be much faster because of native implementation.
As a primarly backend dev, I'm very comfortable with React and I don't particularly want to switch to Vue.js. React says me : learn the HTML basics and then deal with abstractions (proof: React Native !). Vue.js says me : deal with HTML templates, everytime, everywhere.
Although we even end to deal with HTML in React, I think it's easier for a backend dev with no front experience at all to grasp it. I showed React to a old java dev and he said that React reminded him some java web frameworks like Wicket or JSF. I guess Vue.js would have scared him.
I am a Java developer who used to work with JSF 2 and I enjoyed it a lot. Now I'm writing a Vue2 app and I finally feel like JS frameworks have reached a stage where I'm nearly as productive with them as I was with JSF, while requiring probably just one tenth of the server resources.
JSF basically provides you with a server side component tree.
Ok, so I've built stuff in Vue.js, React and Angular and I need to understand all the rage. I mean, Vue.js is just like Angular but with less features? I like that it's slimmer, don't get me wrong, but I just don't understand the "woah, Vue.js is the shit!" when we've had Angular for so long.
I put this in contrast to React where it's a completely new concept.
It might be that productivity and maintainability of "more polished" and "simpler" beats "new concept".
It beats angular, because it is both more polished and simpler.
It beats React, at least in short term, because it is both simpler and you don't have to learn new concepts.
People betting on react are hoping that after they internalize those new concepts, it would make it simpler/more maintainable for them in the long run.
React is not a new concept, it is moving back to tried and true basics, honestly it's one of the few JS frameworks that has been built by people that learned from past mistakes, from former implementations:
Agreed, I feel like I'm missing something here. I had thought that react "won" over angular because people generally preferred one-way data flow vs. angular's two-way data bindings.
At least for me, that's one of the biggest reasons why I feel like I understand react better than angular. It's a little verbose at times, but it does make it pretty easy to follow.
And it looks like Vue.js is a two-way data binding framework? I won't write it off without trying it, but that's a point against it for me.
Whoa! Thank you for this. I think this is exactly what I am thinking. I have done exactly what you did and I'm trying to figure out what the rage is as well. I want to find a framework that works for me without all the intricacies and nuances of something so complicated... something that gives me the errors that I need to know to debug the issues I'm having.
Personally, it's the lack of pain when getting started.
React has an unfamiliar syntax and the cognitive load to "get it" while not huge, was going to take time.
Angular seemed fine but a little verbose and a new version was coming out that diverged from Angular 1 in a way that caused more than a few headaches, apparently.
With Vue.js I read through the excellently presented guide and started building my app, instantly.
I view building an app (or app based business) as lego. Join all the pieces together and yay, you have a product. Vue's component based approach matches that perfectly.
Then you look at the small number of open issues on Github, the large number of Vue.js components available (https://github.com/vuejs/awesome-vue), the well-thought-out error messages, documentation and chrome dev extension.
That adds up to a refreshingly pain-free dev experience. As I've mentioned here before, it's so simple it feels like cheating.
> React has an unfamiliar syntax and the cognitive load to "get it" while not huge, was going to take time.
Maybe because I have a background in functional programming, it only took me an hour or two to get React itself. The basic concept is dead simple declarative programming: declare a React component some state, and it renders it. The lifecycle adds a bit more to understand, but most of us have dealt with lifecycles somewhere, whether in WordPress, Android, etc. And then there's local component `state`. But that's it.
However, what's commonly accepted as the React ecosystem (meaning webpack, babel, flux/redux, eslint, sometimes flow etc.) takes a lot longer to understand. And can be quite (perhaps overly) complex.
Vue.js is multi-paradigm. It supports the MVC model of Angular/Ember/Etc. but with Vuex you can use the Flux model encouraged by React or the Elm Architecture, and it works great.
There's something that irks me about incorporating logic into templates. UI development is hard enough without having to bounce between js and templates to figure out how a component is actually going to behave. I haven't used Vue or React, so this is all just my gut speaking, but at least with React all the logic is there in front of you.
In my mind, if there's a loop or a conditional or whatever piece of logic that decides what will actually show up, that should happen where the underlying data/models is actually built, and whatever acts as the view just spits it into place.
I'm still a scrub when it comes to web and UI development, so I may be speaking out of inexperience.
I just don't like the bidirectional data binding that vue seems to bring with it... I've had enough experience with this in Angular at this point to know that it's painful... then the easiest way around those issues is to use classes, and computed property getters and setters. In the end, it's just painful.
React is much clearer here, but there is more of a cognitive load in getting used to it, there's less magic at the surface. Even combining with something like Redux, or even MobX has another layer of understanding... routing and server-side rendering more still.. but they are layers you learn and add, not everything in one neat package.
I'm also not a fan of the custom DSLs that tend to come with templating engines.
It's the exact way how it's implemented in Vue, with old fashion getters/setters and some "magic" for already defined object fields, see for details https://vuejs.org/guide/reactivity.html Vue has no digest cycle (no dirty checking), so you there is no Angular's performance issues.
Vue single file components behave very similar to React.
The main reason I chose React over Vue is that I found React components were much easier to compose than Vue. This mainly came from them using handlebars, a very suitable library for when Vue was first implemented.
From what I understand, soon you'll be able to use JSX in Vue components - which would negate this advantage. I would certainly consider Vue again for my next project.
The only logic in my views are related to the view. Things like rounding numbers, filtering and sorting lists, looping over a model to render the components. I think these parts have no place in the business logic and the view layer is the appropriate place for them.
Yes I think. If I follow your approach without thinking I would end up with quite a few almost similar templates where I now have one with an simple switch depending on how it is used.
I think it depends on how broadly the template is defined. If you can reasonably limit it to the portion of the UI that is impacted by the data then it isn't so bad to have logic in the template. If the model is built on the server-side, this approach ensures you don't have markup polluting your server-side code and making it less manageable in the long term.
If you're thinking about the difference between data and presentation, then you can usually limit the damage caused by "logic in templates"
Though you might want to precompute some values in your data to make the presentation code cleaner, of course.
It's also important to make things as "component"-y as possible. This is an instinct we don't have when doing HTML stuff by default, because the language itself isn't really used like that in "normal" development.
So you have your data, and then your template ends up being pretty minimal in logic, leaving just some core bits that are purely presentational.
For example:
<p> Your Transactions </p>
<div ng-if="userData.hasTransactions">
<TransactionList data="userData.transactions">
</div>
<div ng-if="userData.hasTransactions">
<p> Please configure your transactions <a>here</a></p>
</div>
Yes, v-for is not a for loop in the sense of looping and building up data. It's a pure repeater presenting already existing arrays of data.
Then you get into the gray zone with filters and v-if but somewhere you have to do switching and for many things, having the code where it is actually used makes most sense.
The data should decide what will show up and the template should decide how. Eg: if data.ok img.url=ok.png else img.url=error.png
The if there is totally okay to have in your template because it's deciding how the data should be presented. The data model should not need to know which images are being used, or even care that you are using images at all.
A long time ago (7-10 years ago) Web 2.0 was the craze. It was the beginning of making interactive web applications.
There were few major players that were even backed by companies: Dojo, Prototype, GWT, (and like 4 more that I can't remember).
These libraries were complicated and were generally component based with their own flair of inheritance. You could not iteratively enhance your existing web 1.0 app. You had to throw it out and start over again (the markup and all).
Then along came jQuery and I remember distinctly saying to myself this is the library because I can progressively/iteratively add it to our existing crap (circa 2006-10). I still pat myself on the back on being right about that library being successful (I actually forced a previous employer to use jQuery over GWT and Dojo).
Progressive enhancement is a great marketing point so maybe Vue.js will pull a jQuery :)
Personally I want Elm to take off but it doesn't really reuse existing knowledge.
To me Vue is a great tool for side projects. In React I found myself struggling to figure out what libs to use and keep myself up to date with them. I also hated configuring webpack. With Vue, I have officially supported libraries like vuex and vue-router which work great with Vue out of the box. vue-cli also allows me to scaffold projects with these libraries very easily.
But the thing I like most about Vue is it allows me, who identifies as a front-end dev or design-coding hybrid, to quickly iterate and build prototypes. Look at the single file component:
I can quickly edit the template to alter my component's DOM structure, style it with scoped css, and change its dynamic behavior in the script tag. Like the suite of Jade/Coffee/Stylus? Adding a lang attribute to each tag and you are good to go. Awesome stuff.
Primarily because we're gonna need webpack anyway (using it as build tool in the project) and started before create-react-app started. It's been quite a while but I still don't fully grasp webpack yet.
I know that Gitlab is written in pretty traditional Rails' style and takes advantage of turbolinks. Did you run into any difficulties adding a framework that likes to "own the page" like most single page app frameworks do? I've found these can often end up fighting with turbolinks and similar libraries.
@wadentandy, Yes that is still something we are figuring out the best way. For a major feature (like issue boards), because we won't use Vue for everything, we load those files on a per page basis.
The company I work for has an app built with Angular 1.x (the backend is .NET). We started sensing that Angular was not best choice, especially when working with 3rd party components. There are other factors to, but they have been already mentioned in other comments. Long story short, we had enough of wrapping everything in $timeout and started looking at alternatives.
After some consideration, we were left with choosing between Vue.js and React. Coming from Angular the biggest plus was two-way-binding, Vue.js had a slight advantage. We then converted a "module" (not in JS jargon) using both frameworks.
In our experience, when switching from Angular 1.x to Vue.js, there's a sense of not changing much (we were still "declaring" logic in the templates) but nonetheless doing things better, simpler and faster. The React version needed a bit more time investment (we had no prior experience in our team; a colleague from another project helped us a bit by showing us how he implemented a project using React). In the end we chose React due to the wonderful combination between it and TypeScript. We suddenly had no more string templates and refactoring was a breeze (there are, of course other benefits as well).
What I'm trying to say is that, if you have Angular 1.x experience it's easier to switch Vue. I had fun porting the "module" to Vue and would have happily worked with it if the team had not chosen React. I consider "mixins" to be one of its killer features (would have made a lot of things easier with our app). Having said that, I don't consider React that hard to grasp and don't regret that the team picket it over Vue. As long as you remember the lifecycle, programming with it can be fun and easy. The React/TypeScript combination compensates for the lack of mixins and two-way-binding (I know, MobX, but I'm talking about the "vanilla" versions).
We had a similar experience in our office. We chose Vue.js and we are all very pleased with the results.
Vue is simple enough to understand and be productive in in a reasonable amount of time.
Exactly how i feel. They maintain project perfectly as well. Issues are tackled with utmost urgency. This is what angularjs was supposed to be. VueJS is perfect (as much as software can be perfect).
> He pointed out that when a major software company releases a their secret sauce, there is going to be hype. Devs think to themselves,'That company writes JS differently than me, and they are prominent and successful. Is their way of writing JS better than mine? And therefore must I adopt it?'
Ahaha. No, believe me I'll not. That's ironic coming from GitLab. I mean I love that company but their front-end sucks big time and it's slow as a snail.
Slow to load and slow are 2 very different things. If you look at the payload timing when comparing 2 branches, you would come to the conclusion that the back end is slow.
We are constantly working on improving our frontend, and have big plans ahead, so I'd be really interested in hearing what "sucks big time" so we can fix it.
I as well gravitate toward Vue.js for its simplicity, but I wonder if React's mind share and community size "trump" simplicity. For example, if you're hiring for a front-end position, you'll probably get more candidates familiar and experts in React over Vue.js.
I think react has a steep initial learning curve but once you grasp the concepts it's not complicated. It is more verbose than vue though and requires more setup and boilerplate to get started.
I don't think it's more complicated so much as different from what people are used to. Once you think of JSX as functional expressions, it becomes easier... and there are far fewer gotchas at play, imho.
I think react combined with a unidirectional state management has a relatively difficult initial learning curve, but overall, I find it's not as steep as say Angular is.
I disagree as soon as you write more than a single nested child/parent component, that requires a different way of thinking (should I use state or props?). And that you can't "just uses react". You kind of have to use redux (or similar) as well as a bunch of other stuff.
People keep saying you 'have to use redux' but I think that's hugely misleading to a large section of potential React users who don't need the highly complex state management that redux facilitates, and could get by just fine with setState+props.
Amen to that. Seems like everybody is cargo culting Redux but really you can get pretty far with just React plus some wrapper components to hold state.
You don't need to use redux. But it's very useful to manage state. I went from using simple components to flux to redux all in same project. For me State management is a very part of client ui.
I spent weeks learning Angular, Ember, and other last-gen frameworks. The todo equivalent was simple, but once you got into their render cycles on a moderately complex project, the wall was very steep.
I started off with simple React apps and it was easy, but I expected to hit a wall. That wall simply never comes like it did last generation. I find it interesting that someone would consider it too complex only a couple years later.
React alone in itself is pretty small library but the pieces that you put together to it (redux, react-router, react-redux, webpack/browserify) might be a big hurdle for beginners.
Couldn't you just ask for JavaScript in the job description instead of React? Because if a dev knows JS s/he will handle Vue easily. Most React devs already write something else: JSX. Of course you can skip using that but won't it be like coding with your hands tied?
I tend to ask mostly JS questions in interviews, and very few "angular" or "React" questions when screening candidates... if you're good with JS and know at least 2 other languages, you'll be able to handle pretty much any modern JS framework without much difficulty.
I get that you can do some cool things with Redux but I'm not sure it really should be the go-to state management tool for React apps. It requires so much ceremony to even do simple things and the async story is pretty complex.
I haven't tried Mobx yet but it looks like a saner solution that don't need Redux's more advanced state management tricks.
Redux never really gelled with me and I couldn’t really understand why until I settled with MobX: all the boilerplate and some idiosyncratic names you need to know to really understand and use Redux was too much friction for me.
Could you expand on what you mean by ceremony and state management tricks ? From my use of Redux there is a bit of set up cost in making the types and actions and getting the store into the components that need it, is that what you're referring to ?
Abstractions should be chosen carefully. Too little and devs step all over each other. Too much and the cognitive load and ceremony get in the way of progress. When your team will never be more than 2-3 people, redux may be a little too much ceremony (especially for applications smaller than 10-20K lines of code). When there are more people, it seems like the perfect amount of boilerplate to keep people out of each others way while its opinionated flow makes it easy to find bugs in code you've never even seen before (another large team problem).
It's been my experience that learning redux without a teacher takes some time if you aren't familiar with the one-way data flow mindset. If you have someone to pair with for a couple days, you'll be off to the races very quickly.
That said, I think redux itself is too barebones. EVERY redux app uses the thunk middleware (even the official docs spend a long time on it) and most find themselves recreating a multiple dispatch one too. If 95+% of your users need the same extension, then it's not really an extension (and in this case, both together are less than 15 lines of code).
' I talk to a lot of JavaScript devs and I find it really interesting that the ones who spend the most time in Angular tend to not know JavaScript nearly as well. I don't want that to be me or our devs. Why should we write "not JavaScript?" '
Vue is inspired and similar to polymer - this is what I like about it.
If i wouldn't be able to pick polymer i would probably go with Vue, but I picked web standards + bigger ecosystem over vue.
Just pick something, internet and build a good structure on top of it. All this jquery-level bikeshedding is nice for your ad widgets and minimalistic web apps, but it won't help me replace proper GUI toolkits. And sadly, that seems to be in demand...
I'll cope with your ill-designed template language (heck, if I can cope with HTML, I can cope with anything) or your JS async abstraction du jour (promises, async await, that * crap), just give me something on the level of Tk or Swing. I feel like all we got in the last decade beyond e.g. Seaside is a bit less flicker and some more useless animations (looking at you, Material Design buttons).
HTML's horrors are highly context sensitive. One of its most generic sins is the poor support for hypertext. Various predecessors did a better job at this (Hyper-G, HyTime). Anchor- and URI-based hyperlinks are a rather insufficient solution, and I think the web would've benefitted from a more extensive and extensible architecture.
Speaking of extensible, HTML has the "class" attribute. Awesome. Something better would've spared us a lot of template languages in the first place. Not looking at you, XSLT.
And when we deviate too much from both HTML's and its ancestor SGML's original purposes, the syntax gets really ugly. Explicit end tags make sense if the beginning of your document's <chapter> is more than a terminal's length out of sight, but when used in something you build UI elements out of (or where content isn't immediately there), the verbosity hurts. Never mind the general XML problem of sub-tags vs. attributes.
At least the amount of different standards is getting better. Parsing still is way more complicated than it needs be.
And let's not even start with the lateness and insufficiency of CSS.
As bad as it was as a hypertext markup language, it's even worse as core structure for this weird NeWs-like quasi-PostScript we're squeezing HTML/CSS/JS into, for lack of a better alternative.
Vue.js seems like a great fit between the DOM manipulation of jQuery and the opinionated approach of AngularJS. Thanks for sharing. Going to experiment with Vue.js right away.
I'm in the process of learning React, so I don't have any strong opinions of my own yet. I've read through the Vue.js "Getting Started" docs and it does look very intuitive/simply. However, what motivates me to learn React is the fact that I can build an app once and then use React Native to create an iOS and Android app. I'm assuming this isn't a requirement for Jacob and the Gitlab team but I'm wondering if his decision would be the same if he had to support native apps as well?
Can anyone compare Vue with Knockout? In the early days of Angular etc I saw a lot of people saying they chose Knockout, and were much happier than with one of the heavier frameworks. I found its simplicity very appealing too, but it seems clear now that it's not a mainstream choice. It feels to me like a dead end. The last time I looked (a year ago?) the semi-official data mapping extension had lost its maintainer. So is Vue another shot at the same approach? What are the important differences?
Our company migrated to vue.js, 4 months ago. Our complex app is messy with JSX, router, and new dev can't keep up with code. Now we start every new app with Vue.js. The gap between junior dev and senior dev comes closer. They can collaborate with less bugs, less problems and less time to develop.
New React projects are today much simpler, thanks to new libraries to manage state like Mobx, or efficient starter kits.
So without denying the benefits you encounter with the migration to Vue.js, I think that a full rewrite of you React app in "modern React" would have been a good thing too.
Before, React projects evolved because they have to. They became too complex, to clumsy, etc. But now ? React is stable, the way to develop apps is well known, etc.
I'd probably like to spend dev time on meeting business demands rather than rewriting the whole project every time a new modern something pops up. Vue 2 breaks little in terms of compatibility with Vue 1.
Great to see here an engineering approach, based on analyzing the needs and the effects of the use the tool, it's different to the usual hipsters comments extolling React and JSX to the skies.
Same here, using Vuejs, glad more people are using it.
It's amazing that a one-person-project(well, it's more than one person now but the core part is really just one guy) can develop such a beautiful system that actually feel better than angular2 and reactjs and who knows how many are behind those two projects.
My experience started at work where we used it on an internal project. The ease of use was insane, we had something reactive and easy to work on in no more than 10 minutes. React has always had too big of a learning curve for us, so it'd have been a vanilla JS/jQuery mess if we hadn't found Vue.
We're now using it on almost any project we start (they're all very UI driven).
I met Evan You at Laracon earlier in the year, he's an awesome dude and has put a lot of thought into everything Vue. Thanks again for making Vue! :)
I had a look at Vue after a long time and then weex a react native alternative using Vue.js instead of Reactjs. Backed by Alibaba and actively developed it looked really good. But a look at issues made me a bit afraid to use it. The primary language used for discussion, suggestions etc is chinese. Documentation however is available in english.
I wish there were an equivalent to something like ember-fastboot for out-of-the-box server side rendering, though. (server-side rendering for those who care about progressive enhancement in the browser, not isomorphism).
it does, but that isn't my complaint: there isn't an official, opinionated way to do it - something that syncs vue-router to express and serves. it's a common enough problem that fastboot solved it for ember, and I wish vue had the same.
These discussions almost never mention cycle.js. I haven't done front end in a couple of years but whenever I read something from the author of the framework, I'm pretty impressed and the choices they made seem very promising.
Is there anyone that's used Vue and knockout that would like to share the strengths/weaknesses of each? The both seem quite similar so I'd like to know if I missing out on anything by not switching.
I tried Vue.js a few months ago and liked it a lot. But now, I need to rewrite my apps and I decided to go the Cordova road with Ionic 2, because Ionic 2 is, imho, unparalleled in its quality.
Ionic 2 uses Angular 2 and I wished there was some Ionic 2 + Vue.js bindings. However, after working with it for a bit, I found that Angular 2 is actually quite simple with the benefit of using TypeScript out of the box.
Before you dismiss Angular 2, give it a try. It's fundamentally different from Angular 1: easier to learn, less complex, faster results.
Have you looked at Weex[1]? It's what Ionic is to Angular, the only difference is that Weex and Vue has an official collaboration and Weex has been embraced by Vue's developers - something that Ionic hasn't yet been by the Angular team as far as I'm aware.
Note though that the collaboration is still very young between these two, but I believe we'll see some great things in 2017 from this collaboration!
Yes, I did and I don't like it very much. Docs are partially in Chinese, almost no examples. Compare this to Ionic 2, which is very close to native elements, including animations.
My team and I are considering switching from Knockout.js to Vue.js. Has anyone here made that (or a similar) transition and do you know of some pros / cons, battle stories, etc.?
you'll probably see less disconnect from Knockout to Vue than pretty much any other modern js ui approach... even ng1 to ng2 is a really big break. I happen to like React's approach more, as it's more pure to JS (even with JSX) than augmented DOM, or template engines are imho.
I'm guessing those 30 lines were for manipulating the DOM or getting the data from form elements. In Vue similarly like in Angular you don't need to write code for that, because the data is 2-way bound. You just do something like this.data = ... and you're done.
I like the ideas of the choo framework https://github.com/yoshuawuyts/choo it's very close to vanilla js, which makes it less of a lock-in, while still bringing lessons learned and practices from redux/elm-architecture.
I am currently using it (the 4.0 branch) in a project and enjoying it.
How does Vue.js handle high latency issues? With Angular 1.x I've always had issues where the GUI will "flash" while the HTML is loading and the angular.js has not yet finished loading on a slow connection (so you might briefly see all of these {{message1}} {{message2}} etc on the page). I'm curious how Vue.js handles that case or if it has the same problem.
I guess but it feels like such an anti pattern. I have to tag every thing that uses the template system with ng-cloak and that assumes the angular css loads before the HTML which can still not be guaranteed it's just more likely.
The worst part is many default values could be displayed but now we're hiding sometimes large junks when for the best UX you should show as much of the page as possible.
Ultimately just not a fan of any template engine that relies on being fast enough to hide and replace values in the raw HTML.
It is preferable to use ngBind instead of {{ expression }} if a template is momentarily displayed by the browser in its raw state before Angular compiles it. Since ngBind is an element attribute, it makes the bindings invisible to the user while the page is loading.
We _just_ started using React, primarily for it's server side rendering support in .NET with Reactjs.net. Works really well and the React mindset feels great.
Coming from Angular 1 though, Vue has a lot of appeal. Is there any support for SSR in .Net, or anything in the pipeline? I've not been able to find anything.
Is there a normalized performance suite that compares the popular front-end frameworks?
I understand if performance is of utter most importance, you may not want to use a framework layer. However there are tons of other benefits associated with using a framework.
However, as they say, "In terms of performance, both frameworks are exceptionally fast and there isn’t enough data from real world use cases to make a verdict."
And Angular 2 Hello World is easier than they make it seem in the comparison:
> starts out with an app that uses ES2015 JavaScript, NPM with 18 dependencies, 4 files, and over 3,000 words to explain it all - just to say Hello World.
It's just the following with a lot of documentation that could be simplified:
Also, it makes the case that Angular2 is "enterprise" because many use TypeScript with it. But, TypeScript is optional in both Vue and Angular2, so people could just as easily make the argument that Vue is "enterprise" because it supports TypeScript.
Finally, it's true that Google uses/develops Angular2, so that's some significant backing. If you want to see who's using Vue:
Why is it that the first instinct of some developers is to go out and 'choose' a framework? Even before you know the thing you're building is going to be around for awhile, people automatically think they need a framework to do anything these days.
Does it feel good to let someone else make critical decisions for you, instead of thinking for yourself? Can all projects really be distilled down into some javascript framework?
The benefits of using a framework these days are rapidly evaporating as what is trendy today likely won't be in a few years anyways. And the truth is after so many months or years or commits, the benefits of structure of the framework start to fade away as the application becomes more customized and bespoke. All the complexity is in the actual application functionality, not the tiny little savings and poor abstractions that a come with a framework.
I've worked for large tech companies and small alike. It all goes the same way. Some developer who is super opinionated and passionate props up their framework of choice, or does some kind of perfunctory analysis of the "current best" of whatever is available at the time and the rest of the other more submissive developers go along with him. It has more to do with group dynamics than has to do with actual technical merit, or what is best for the product or business.
Then, once the system has become a ball of mud, the "lead" guy leaves. Or he proudly exclaims there's a new hotness in town, and that we need to rewrite our application in this new thing because it's faster, or better, or you get to type less. Or some other such bullshit. He'll then go to give demo's of how fast you can make a simple app that has nothing to do with anything -- like a simple TODO list -- "look how fast it renders!" he'll exclaim (of course forgetting to tell everyone the first page load or stale cache hit is actually worse).
I personally hate giving up the freedom of what abstractions I get to decide on, how to structure my code, how to organize my API's, etc. for a supposed one size fits all solution created by someone I've never even met or talked to, and for code that I haven't reviewed.
If it's a library that's doing something useful and providing a great API, like some 3D graphics, drawing primitives, ML, database engine, etc. that's a different story. That is useful software that actually does stuff. But for "rendering" (I say that lightly because the browser does the rendering and layout, a framework merely is a middle-man) forms and buttons and keeping state of an application? Or telling you how and where to put source files, and name things? That's your job as a developer to come up with these conventions and to build an application that is 1:1 with the problem domain.
Vue-cli is great too. It just works, creates a really well thought out initial project that can build to a single static html/js/css. Or, it can be turned into a typical express app easily. This makes Vue.js combine well with serverless.
I find the comparison to React there pretty biased, especially wrt the learning curve... JSX is a cakewalk, and OMG, oh noes, you need to know the current JS language.
Building something fast is a radically different proposition than being able to maintain it with ease. React is mostly aimed at the latter while VueJS at the former. There is no comparison.
You are definitely not in charge under socialism. And the end result is not efficient either.
Even if you accept the definition of socialism from the followers of socialism, these points cannot be true, because either it is the government or the commune that is in charge depending on your definition of socialism.
And also everything that has to do with resource allocation needs to go through either of these political bodies by political decree or voting, neither is efficient.
A bit over a year ago, I wanted a real-time web UI to visualize some of the data I had on server-side, which I was trying to do using SignalR. I went back through some of the popular frameworks, with a pretty simple mindset of "Can I read the 'getting started', and get something basic working in about 15 minutes?".
I ended up choosing Vue, mainly because it used simple objects for models and I could literally just pass stuff I got from SignalR directly into it and have it show up. Almost everything else I tried had some type of wrapper/proxy around the data, which meant you had to run through some mapping exercise to get models working. I was close to deciding on Mithril, but when I found vue it just clicked with me way more. I actually really wanted to do React, but Vue was just so much more approachable that I couldn't justify spending the extra time learning React.
The real test however came months later, when I went to modify and add more functionality to my simple debug UI. I was able to pick it up nearly instantly, and even made some fairly substantial changes.
Contrast to my experience with say, Ember. We have a big app written in Ember, and every time I try to do even what I think should be a simple change (after not touching it for months), it takes me 5 times longer than I thought, and I end up spending most of the time fighting with it before realizing I forgot one of the 5 places you have to modify to reference an additional dependency, or some other equally trivial but infuriating detail.
You can learn the basics of Vue in minutes, and be quite adept within hours of it. That's something not a lot of frameworks can claim, and it's a seriously underrated benefit.