Why we chose Vue.js
about.gitlab.com
about.gitlab.com
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.
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.
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.
Disclaimer? I don't use Vue, but I've seen this argument made for Ember (against Angular 1.x) and Angular 2 (against React).
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.
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.
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.)
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.
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.
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.
- 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!
FYI, I'm thinking about dropping Knockout because some performance problems I'm having with a very specific use-case.
I've used Knockout before and it's really slow. I also find Vue to be less complex overall in comparison to Knockout.
- 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 mean if I look at the GitHub stars it seems pretty hyped to me. (It's between Angular/React and Ember)
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.
Here's a website that's an SPA https://preactjs.com
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.
I think Jason Miller, the Preact developer, re-tweetet the article about SEO & SPAs a few days ago.
But, because of progressive enhancement, I would using SSR on my next project anyways.
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.
Yeah there's a lot of FUD about how google indexer works, needlessly IMO
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.
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.
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.
With some projects, it's both obvious and simple. Similar to eternal summer. Democracy means that all of us get to be dumber than any of us.
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.
Then the cycle repeats itself.
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. ¯\_(ツ)_/¯
This Cracked article gave me a bit of consolation: http://www.cracked.com/blog/6-reasons-it-sucks-to-hate-popul...
Maybe it's just harder to choose a popular option without being seen as jumping on the bandwagon.
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.
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.
Try Clojurescript. It is truly amazing.
Hipster - Google definition:
a person who follows the latest trends and fashions, especially those regarded as being outside the cultural mainstream.
So I guess a framework hipster?
I also found it strange that he didn't name React by name.
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.
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.
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?
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.
if we are making an apples to apples comparison, React does not need any external tooling to stand up to Vue.
Vue, babel, webpack, vuex (or redux and vue-redux).
There's hardly a significant difference in requirements.
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.
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.
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):
<div>
<SomeComponent
debug={(() => { this.state; debugger; })()}
someProp="prop"
/>
</div>
<ul>
{immutable.toSeq().map(x => <li>x</li>)}
</ul>People seem to think using a familiar templating language excludes using the full power of JavaScript. It doesn't.
{{ data | json }}
>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 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.
JSX:
<div className="classy" onClick={this.handleClick} />
React.createElement('div', {
className: 'classy',
onClick: this.handleClick,
});
var el = document.createElement('div');
el.className = 'classy';
el.onclick = handleClick;
Let's not forget how horrible Angular templating was:
<ul ng-if="::vm.items.length">
<li ng-class="::{ 'active': item.active }" ng-repeat="item in ::vm.items | orderBy: 'id' as ordered track by item.id" ng-click="item.active = !item.active">
{{::item.name}}
</li>
</ul>
<select ng-options="item.subItem as item.label for item in ::vm.items2 track by item.id" ng-model="selected"></select>
<div ng-include="selected.template.url" />Syntactically, JSX feels more native, but both are addressing the same problem.
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).
It's a templater, read my message above - an advanced tempalter, which means it has some DOM rendering optimizations.
> The only similarity between PHP and React is that you can have tags in ("around" in PHP's case) your code.
Not just tags, but an entire "view" thing, a representation, so old fashion messy/sloppy/spaghetti-like PHP like code style.
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.
the notion that your view logic and it's template must be completely decoupled is an antiquated and misguided best practice.
Really want to play with it ...
It's really much like JSX, but without the syntactic sugar of using HTML-like markup.
https://medium.com/@housecor/react-s-jsx-the-other-side-of-t...
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. Relay/GraphQL...
There's literally only one of those, to tell what element in the HTML to bind the root Vue instance to. Vue doesn't require thinking about the DOM.
It's the same sort of thing as React's basic tutorial (https://facebook.github.io/react/docs/getting-started.html)
ReactDOM.render(
<h1>Hello, world!</h1>,
document.getElementById('example')
);Thank you!
http://vuejs.org/guide/single-file-components.html
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.
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.
There are many ways to make good views with dynamic updates, but there are even more ways to make them spaghetti.
A framework is simply a pattern that takes a certain approach to solve a problem. The lifetime of it is mostly irrelevant. Vanilla JS changes too.
JSF basically provides you with a server side component tree.
I put this in contrast to React where it's a completely new concept.
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.
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.
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.
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.
In this way Vue or more specifically two-way data binding struck me as a step back.
Or am I misrepresenting Vue?
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.
Am I missing something?
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.
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.
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 2 ditches it entirely, in favor of Vuex, which is inspired by Redux in part. http://vuex.vuejs.org/en/intro.html
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>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.
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.
Vaadin comes to mind :)
+1 on Elm, also don't think the learning curve for someone with any "functional" (even if JS) exposure is that steep.
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:
<template>
<div id="list">
<li></li>
<li></li>
</div>
</template>
<script>
export default {
// Define your component
}
</script>
<style scoped>
#list { list-style: none }
</style>
I mean, it is really handy to have a tool to save you from the initial setup and all that boilerplate code when you already know how it works.
But not knowing how the different pieces fit together will bite you when things start to fail.
But then I discovered that there's already a new tool that's cooler than webpack: rollup [1].
[1]: http://rollupjs.org/
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).
Yet I'm loving the experience of working with VueJS. I think alot of people feel this way. The library is just that simple and straightforward.
1. someone trims your product down and ship it as "simpler than X" 2. people asks for more and more 3. now you have a complex product 4. repeat
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.
600KB of CSS, 800KB of JS... That's fine on your MBP over WiFi but on most pages it locks up the main thread on my phone for a good 5-10 seconds.
Is there a strategy to tackle the CSS and JS bloat?
Is performance something the front-end endboss folk consider important enough to delay feature releases?
Are you monitoring performance with a tool like SpeedCurve?
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'd hope that people who are being exposed to this idea at least also get the chance to read 'You Might Not Need Redux': https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
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.
I haven't tried Mobx yet but it looks like a saner solution that don't need Redux's more advanced state management tricks.
I haven't actually built anything with these yet so maybe in practice it's ok but it definitely looks ugly.
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?" '
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).
Just curious, what do you find so terrible about HTML?
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.
We went with polymer for web standards, bigger ecosystem and great encapsulation options. Everybody loves the change.
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.
I think he means social democracy
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 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).
I just realized that it's more dynamic than I thought when I saw two stories switch positions on the page. How cool!
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.
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!
I would give it time before I use it.
I am currently using it (the 4.0 branch) in a project and enjoying it.
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.
<p ng-bind="value"></p>
instead of
<p>{{value}}</p>
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.
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.
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.
> Vue 2.0 seems to be ahead of Angular 2 according to this 3rd party benchmark. ( http://stefankrause.net/js-frameworks-benchmark4/webdriver-t... )
The latest benchmark provided is actually:
https://rawgit.com/krausest/js-framework-benchmark/master/we...
But, Angular 2 is v2.1.1 now, released 2016-10-20. Someone should update: https://github.com/krausest/js-framework-benchmark
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:
mkdir angular-quickstart
(add package.json)
npm install
mkdir app
(add app.component.js)
(add app/app.module.js)
(add app/main.js)
cd ..
(add index.html)
(add styles.css - optional step)
npm start
Finally, it's true that Google uses/develops Angular2, so that's some significant backing. If you want to see who's using Vue:
https://github.com/vuejs/awesome-vue#projects-using-vuejs
That doesn't mean anything on its own, though. It could be just fine to use and expect to continue to be hyped.
typescript is not optional. Just look at the official docs. the js version of docs are still incompelte even though 2.1 has been released.
>it's true that Google uses/develops Angular2
Google's major product is adwords. And adwords is built on angular2 dart version. While devs mostly use ts version.
As an opensource project, it'd be easier to get contributors if you could just stick with Angular.js, for example.
Shameless plug: https://github.com/vuets/vuets
It is a micro-lib less than 100 LOC.
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.
Why?