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 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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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?
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.)
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.
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.
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
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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!
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'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.
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.
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.
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.
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.
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.
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.
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.
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 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.
> 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.
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 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?" '
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.
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.
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.
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.
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.
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.
281 comments
[ 2.7 ms ] story [ 224 ms ] threadI 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).
We went with polymer for web standards, bigger ecosystem and great encapsulation options. Everybody loves the change.
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.
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.
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:
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.
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.
Shameless plug: https://github.com/vuets/vuets
It is a micro-lib less than 100 LOC.
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:People seem to think using a familiar templating language excludes using the full power of JavaScript. It doesn't.
>immutable list in Vue
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.
[0] https://github.com/vuejs/vue/issues/1200
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:
No JSX: Native (note this naive implementation lacks proper scoping): 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.Let's not forget how horrible Angular templating was:
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...
- 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.
[1]: https://crystal-lang.org/
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.
https://github.com/danmademe/express-vue
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?
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.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/
' 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 think he means social democracy
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.
https://bitquabit.com/post/the-more-things-change/
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?