Having used both React and Vue extensively. I'd say React's great at Single Page Apps in the true sense of the word, Apps that have a single UI like an IDE:
Vue's also nicer for "page-based" Websites that are converted into Single Page Apps. Nuxt.js really shines here which lets you develop complete Websites using Vue's Single File Components and takes care of routing by following a conventional page structure. Nuxt.js + Vuetify will be my goto for many traditional Website style Apps (implemented as SPAs) going forward. It imposes an opinionated convention but saves you a lot of effort having to manually configure and integrate different libraries together.
Vuex is more pragmatic and requires less effort/code to use than Redux, but Redux is great when you need to access previous states, e.g. it makes it effortless to capture "Snapshots" of the entire current state of the App that you can send to someone else so they load your App exactly as you see it:
As an aside (and since you brought up snapshots), mobx state tree https://github.com/mobxjs/mobx-state-tree seems to have combined the ease of use of Mobx with the power (and beyond) of Redux and its ecosystem.
I watched a video about Vuex last night, and with mutations, it seemed more convoluted than mobx state tree.
All of these are possible with Vuex. It's based on the same fundamental paradigm: a single state Singleton that renders everything.
You can even use Jest's snapshot testing for Vue components. Time travel also exists in Vue developer tools, and there are plenty of undo/redo plugins available.
It will never be as easy as Redux where the entire state is maintained in an immutable and naturally serializable plain JavaScript object in which all messages can be inspected, serialized, dehydrated, sent over the network, etc with every App state transition being easily captured / replayed or reverted to any period of time. You can force it with other state management libraries with additional machinery, but Redux's approach of sending plain JS object messages to create immutable states is naturally well suited for the task.
I'm sure they operate differently under the hood (and that's a bit of a black box for me), but as an end-user I can do any of those things with Vuex as well - time traveling, serializing state, subscribing to state mutations, etc. Doesn't require Dev Tools either, although obviously that's much more user-friendly.
Like I said it's possible but requires additional effort and machinery, with Redux your App already constructs and dispatches state transition instructions/delta messages and renders the plain state object as a first-class construct, whereas other state management libraries need to create foreign artificial constructs to support it.
Perhaps I'm missing something. Vuex state is almost a plain JavaScript object but with Vue's getters/setters on it. I can access the root state object easily with `store.subscribe((mutation, state) => {}`. Mutations feel nearly identical to reducers (but simpler!) and interact with the state as a plain JS object. What `foreign artificial constructs` are we talking about here?
EDIT: I assumed Vuex state was immutable outside of mutations, but that's only true with 'strict' mode enabled.
Coming from Angular, I hated seeing another framework that has conditions inside elements, like v-if, v-bind, etc.
Especially when I saw things like @click, @submit, etc, I said Vue is not for me.
However, you quickly realize it's not like Angular where those declarations can at times be overwhelming. In Vue, there are not that many and it is actually much more simpler and even intuitive.
Also, when coming from React, being able to use certain things like v-model makes you not want to go back to React, and has shrunk the code and simplified it quite a bit.
> Also, when coming from React, being able to use certain things like v-model makes you not want to go back to React
Could you explain that further? I definitely see Vue as an improvement over Angular, but React still is much better for me than Vue, so I'm curious what you mean.
v-model is a two-way binding. In other words, you don’t have to write a setter function for every piece of state - you can hook up a state field directly to a text input, for example.
React doesn’t allow two-way binding, or at least heavily discourages it. The downside of two-way bindings is that they can make it hard to track and understand state changes. The upside is that they drastically cut down on boilerplate for things like forms.
Personally, I think one of the best things of React is that it left out two-way binding on purpose. I agree, that sometimes people write a lot of boilerplate therefore, but at least it can be understood (and modified) easily. Advanced people write nice re-usable functions with the same effect, but less boilerplate.
v-model in Vue is not exactly two-way binding. It is just syntax sugar for passing the value as a prop and setting an event handler for the “input” event. It looks like two-way binding but has none of the gotchas.
Yeah, the documentation should probably reflect that. It works like shallow two-way binding, but it implemented differently. Instead of using observers on the data itself, it uses an event, thus maintaining a cleaner interface between the components and avoiding the performance problems and bugs that come with two-way binding.
`v-model` is just a syntax sugar to save you from typing `v-bind:value="val" v-on:input="val = $event.target.value"` over and over. Nothing more than that.
2) You can easily distribute custom components that provide `v-model` to users
3) You can dynamically accept 3rd party components that implement `v-model`. E.g., I have a component that incorporates standard form fields, but can also be used with any custom components that properly implement `v-model`.[1]
Have you tried mobx with react? For me it looks like a good solution without much boilerplate.
Also, for simple forms you can just store state as component state and then passit along at submit.
These posts are becoming redundant. Although I do understand where the author is coming from. I think the issue is that frontend development is hard! Especially modern frontend dev. It requires an entirely different thought process than backend development and this is why I think so many people get scared and reach for the most familiar lib out there.
However, getting used to the React ecosystem really does have huge benefits (code clarity, minimization of bugs, ease of creating complex interactions) and I do recommend that those interested really just dive in and build something simple to see for themselves.
All the extra libs and tools are helpful and make your job easier in most cases. But they can be phased in as you get a deeper understanding of the ecosystem.
The ecosystem is standardizing now. And I don't see webpack or React going away anytime soon.
I'd love to read the follow up article 1 year from now. And then 3 years, and 5 and 10.
Vue 2.0 was a complete rewrite and their "long-term-support" for v1 was 9 months of security updates.
I'm not trying to single out Vue, but I wonder how many job posting are for someone to maintain a legacy framework code base. (Legacy meaning 6 months old.)
Yeah, I'm always a bit sceptical of these kinds of articles. Been saying to people for years that everything we build today is tomorrow's legacy.
This whole idealistic fantasy that this time around "we're going to get it right" - whether it's because we're smarter than those who came before, or we have better tooling, or a better framework, or better languages, or whatever specious reason is given - is just that: fantasy.
In the face of changing business and product requirements, and evolving markets and technologies, you have to accept the fact that almost every piece of software you build has a shelf life, and that shelf life is often surprisingly short.
Therefore, rather than try to guess the future (and get it wrong, because most people do, most of the time) you're much better to focus on the problems you have to solve rightnow. Sure, don't code yourself into a corner by building some sort of tightly coupled ball of spaghetti, because that's always going to turn out badly, but to think that's what you're resigning yourself to by focussing only on problems you need to solve rightnow is to conflate two entirely separate issues.
> This whole idealistic fantasy that this time around "we're going to get it right" - whether it's because we're smarter than those who came before, or we have better tooling, or a better framework, or better languages, or whatever specious reason is given - is just that: fantasy.
I'm glad smart people before me have decided that they're going to try and get stuff right or at least more right. Say what you will about Java or C# enterprise software, but I can't imagine COBOL was any more fun.
I'm not against doing things well - far from it - but the idea that you should try to build a perfect system that takes into account every unforeseen eventuality is madness.
Also, agree about COBOL, but software systems these days -
in C#, Java, whatever - are often larger and more complex than those written in COBOL. Partly this is because of higher user and business expectations of what can be achieved with technology, partly it's because the modern tools make it easier (or even realistically possible!) to do that. It's still the same deal though: it's all legacy in the end.
The difference to me with other frameworks (most notably Angular) is that the transition from Vue 1.0 to 2.0 was relatively smooth. I've migrated a couple of smaller applications and that was done in just a couple of minutes. If Vue keeps the core and focus small i think maintenance will be easier than with comparable frameworks.
For me this is actually a reason to use React even if Vue might be more appropriate. I fear that the 'front-end ecosystem' is still a bit too much in flux to settle on a framework as relatively opinionated as Vue.
What makes React both nice and complicated is that it's really pretty bare-bones (even with Redux), and as a consequence a lot of the stuff you learn with either be useful for JS programming in general, functional programming, and UI building in general.
For example, I've been working on a little command-line tool in Elixir, and a lot of what I do in the view/render code is very much like React and what I learned by using React.
Anecdotal, but I had to migrate a mid-sized app (about 400 components) from Vue 1 to Vue 2 and it took less than a day of work to modify the code, test it and push to production. We weren't using that many removed features to begin with, though.
VueJS 2 was an easy upgrade. Most people are probably starting on VueJS 2 anyways, coming from jQuery or ng1. When I started using VueJS my biggest pain point was how much bootstrap assumed you were using jQuery.
I don't get the Vue hype. Sure, Vue seems nice enough, but it is concepteually very similar to React, so nothing new there. The pros of React are a smaller API and JSX instead of an added templating language (the latter being a contentious issue, I know).
EDIT: I realize now Vue does have optional support for JSX and you are not forced to use a templating language.
I find vue much simpler to start out with and build off of, since it is almost all just regular html and JavaScript, as opposed to React which uses jsx and has lots of painful setup of tools like redux and react router. Vue.js has a really good webpack starter kit that will give you a working site that you can expand really easily so that makes setup super simple.
Just don't use redux. Maybe one day there will be a decent, ergonomic framework on top of the flux architecture, but redux ain't it.
Try mobx state tree for all the benefits that redux has without the pain.
Vuej seems nice enough (especially for migrating server side tech apps), but I'm still not digging the templating engine. I've seen the way you can use JSX in Vuej, and I don't like it.
it's cultural/human; debian/fedora/archlinux are all nothing but linux distro.. yet I cant fathom the first two, while arch mindset and wiki suit me in ways that never fails. I think vue is just like that. It's readable, efficient, does 90% of react. For some people it's the right fit.
No, the pro is that is not supported by one of tech giants with infinite resources for the sole reason “to have larger footprint on the web”, basically to increase their spying capabilities across the web.
Instead, vue was built by one guy, and it’s en par if not even better than react/angular.
You're not wrong, but I think the parent commenter touched a good point, just not in the most masterful way: using open source software from Facebook or Google increases their soft power over the web and Open Source in general.
In the same way Google pretty much decides web standards these days (unless most other implementors refuse to back a proposed standard; even then, Chrome can keep supporting something), Facebook could end up deciding standards. The former with the browser, the latter with code that runs in the browser.
Though Vue has more contributors now, that a single person could start and grow an open source project, with his own goals an opinions, shaping a community around certain principles, is something that appeals to me on philosophical and political grounds.
By the way, until recently, the recommended way to get started with React (unless you were using a bundler, hosting it yourself or using another CDN) was to load it from fb.me, a Facebook-owned domain.
Ok, I realized, that I’ve used the wrong words. I’m sorry for that.
What I meant: I believe big corporations like FB and Google do open source for a reason. A strategic reason. There are two that come to mind: (a) being able to push standards (like MS tried with IE). (b) usually these libraries are loaded from the respective companies’. It is possible that the loading data is then used to augment other data they have. In the end, both companies’ business models is based on data, only.
People hate having a build step and will go to great lengths to get rid of it. To add on top of that, the situation with writing modular code in JavaScript/HTML/CSS is such a total disaster - even with a build step.
Of course, the problem is not quite solved by not having a build step. It just means that things will bite you later, once you have enough components that just loading them one by one wont do. (at least not yet - we need smart HTTP/2 servers for that).
Then you add a simple build step in the form of bundling. This is a happy medium and most apps will survive very well with this sort of setup (a single bundle).
But another point might come where the single bundle is too large to be served in one piece. At that point you need code splitting. And now if you're using one of the custom framework module systems (which work by defining global named "injectables"), you might regret it, since code splitting bundlers rarely understand the dependencies between them. Not sure what the situation in Vue land is, but if you're using the asset pipeline you'll likely have to manage two sets of dependencies per file (your requires and your vue components) and then last time I checked, Sprokets does not support code splitting.
This entire situation is caused by two major problems with the web platform:
1. The ES6 module system is not yet available in browsers, and servers and browsers are not taking advantage of HTTP/2 push to ensure efficient module loading. You can create a service worker to support this browser-side (https://mariusgundersen.net/module-pusher/), but then there is Safari - and dammit, this stuff should be built in and commonplace everywhere!
2. You can't use the ES6 module system to modularise the rest of the assets like CSS and HTML. An ES6 module can't request for a CSS file, templates or other assets to get loaded via push. (Well actually it can via loader hooks I suppose, but there is the CSS modularity problem). There is another way to do this called HTML imports (which combined together with Shadow DOM finally gives CSS some modularity), but its a whole different thing form ES6 modules and its unclear how to make those work together. So to use that you kinda have to throw ES6 modules with the bathwater too.
3. IE11.
Someone on those standards bodies should get their act together and fix this dire situation. Until then, I'm excited about Parcel's way of handling this, with its async imports support making code splitting quite transparent. In general the ES6 module system has the best bundler support thus far, so JSX and css-in-JS (or at least css-modules) make sense to me for the foreseeable future.
p.s. One other reason why this isn't fixed is probably because the big companies that have the most say in standards bodies and browsers don't care. Preliminary research showed (can't find the link) that HTTP/2 push would have about 5-10% overhead over current optimal bundling and code splitting solutions, and these companies have their own developed infrastructure to optimise every last bit of performance - they can't afford 1% drop, let alone 5%. So there is no incentive to help the rest of the web.
I don't think there's anything wrong witha build step as long as a) it's simple and b) there are distinct advantages.
Most of the js ecosystem fails miserably at a). And for b) the advantages of es6 and / or jsx aren't universally appreciated.
A good example of a build that IMO delivers both a) and b) is Elm. The build is simple (like compiling anything, but you can get all webpack complicated if you really want) and the syntax, static typing, and compile time errors add enormous value.
> Everything just makes a lot of sense without a lot of fluff added to it. It does everything React does and I'd say does a lot more using less codes.
This is also why I'm positive about Vue having a good 'place' in the ecosystem. React can be a bit overkill for smaller projects.
That said, I feel about it a bit like I do about testing. It might not be necessary for a lot of stuff, and it can feel tedious to do, but as projects grow, I often find myself wishing I'd added tests from the start.
In general I find myself leaning towards preferring too much 'boilerplate' over too little, at least as rule of thumb.
Overkill might not have been the best choice of words. What I meant was that because React is so simple, it can be a lot more work for relatively little gain in a smaller app. It's same reason I used to often still go for jQuery.
But I agree, I love the simplicity and it fits well with my rapid descent into being a functional programming weenie.
I tried to use Vue.js recently, but found that there's a huge set of idiomatic coding principles, as opposed to a small set of primitives. Which basically makes it not for me.
What I also disliked was how they don't explain how to get it working without a build-environment like webpack. That makes it really a "framework" in the sense that it's all-or-nothing. Again, not my style. I prefer self-contained libraries.
I disagree with the assertion that it has "huge set of idiomatic coding principles", but I think that's a matter of opinion.
However:
> What I also disliked was how they don't explain how to get it working without a build-environment like webpack.
This doesn't make sense. The official website includes a way to use it by just including a script from the CDN, on the "Get Started" page. It even discourages using the build tools if you don't have prior experience: https://vuejs.org/v2/guide/
My understanding is that if you're using just plain vue.js (without any tools or npm magic), you're not gonna be able to use single file components.
You can "do without them" but going to .vue files that you like, and splitting them back up into their HTML and JS bits and copying and pasting them into places you like.
vue really isn't at its full potential without using webpack/browsify. But I understand not wanting to use it.
For example, we've been sprinkling vue into an existing jquery+bootstrap internal application. It's flask/python, so we just went in and split up things that would be a .vue component into HTML snippets that we can embed using our templating engine, and JS components that you just src include. Now we have bare bones reusuability (no composability though). We'll probably have to swallow the bullet and just figure out webpack/browsify.
You mean the examples in the link I posted? Those are just javascript and HTML, there's nothing special about them.
Just put that on an HTML file and run it in a browser. No need for any tool other than a text editor.
To compile .vue files you have to use vue-cli (linked on the "Get Started" page), or some third-party tool (instructions here: https://vuejs.org/v2/guide/deployment.html).
Ok, upon a second look, it seems that those directives are translated in-place in the HTML document, so indeed I could have coded the examples in HTML. But it feels a bit like magic.
Still, I wonder, how do I make components? Are they also encoded in the DOM tree? It feels a bit strange to encode templates in the actual DOM tree, even without using them.
I have developed a production vue js app without any building tools.(!) Keep in mind that you should not do so. Some community vue component expect babel helps to transform their es6 code for IE11. Besides, you cant do code splitting, which is an issue when you have many small components to be loaded in the same time.
I suggest create your actual project with vue-cli once you get familiar with the vue syntax.
> I also disliked was how they don't explain how to get it working without a build-environment like webpack
Your comment is a bit mystifying. Go to https://vuejs.org/. Click "Get Started". There is literally an example right there on the page, the first thing they show you is a frameworkless Vuejs app with nothing but a script tag.
if anything this is one of VueJS's advantages over most other similar frameworks.
> What I also disliked was how they don't explain how to get it working without a build-environment like webpack. That makes it really a "framework" in the sense that it's all-or-nothing.
That's weird you think VueJS is weak on this feature, because this is basically VueJS's most significant competitive advantage over react and one thing it does extremely well and has tons of documentation and tutorials for.
Try Polymer 2.0 + lit-html/hyperHtml, it's jQuery for web components basicly + `react-like` templating but based on WHATWG standards. And your code will be small and will work in the future because of web components being part of browser API.
I keep waiting on fully commiting to either Vue or React, to see which might end up dominating so I don't have to waste a lot of time on the one that will likely end up wilting. I've been doing the equivalent of full-stack web development non-stop since 1995 or so. My tolerance for going with the loser has declined persistently toward zero year by year, due to two decades of randomly eating shit when going with the wrong platform/library/tool/whatever (wrong, meaning, the one that loses the popularity contest and ends up practically disappearing).
I've spent a modest amount of time with both. I find myself repeatedly drawn back to Vue every time I work with the two. I like it dramatically more than React. HN seems to love Vue, I can't decide if that's primarily due to its underdog non-FB position. HN loves the underdog, as most forums made up of people will. Whatever the case, React is winning the popularity contest at the moment. I'm pulling for Vue.
One thing that is really great about Vue is it’s ability to just work with whatever setup you have. Sure if you’re building from scratch it’s great to have robust build tooling, but sometimes you need to write good front end code in the midst of an old app that’s in bad shape. Having used both React and Vue extensively, I’d always reach for Vue when trying to add modern UI components to a legacy app. It manages to work beautifully even when you need it to just be loaded old school via script tag and to interop with adjacent jQuery code.
> I’d always reach for Vue when trying to add modern UI components to a legacy app
This is the thing that steers me strongly to Vue. If I'm building a component I like the idea that it's at least potentially reusable in the widest possible set of situations. With React I feel like my component is usable only in other React apps (including the full webpack build etc), which, as popular as React is, is still approximately 0% of the world's web applications. With Vue I feel I can make a component that can drop in seamlessly to just about any HTML page in the world.
We use Angular (2+) at work, but after hours my framework of choice is Vue.
One striking difference between these two is: I can build a Vue application from scratch mostly relying on my memory using a basic text editor if need be. The same feat is nigh impossible with Angular.
A decent IDE helps, but being on my second project now using this framework I still rely on examples from the first one.
What I wanted to say is that comparing to Vue Angular is full of unnecessary complexity.
I'm guessing the custom syntax like "banana in a basket" for bindings. Or inputs and outputs and having to weave together components that use different reactivity models. Vue also has similar syntactic sugar and angularJS was guilty as well. React just has props with one syntax to use them. Although the syntax is simpler in react it does lend itself to computer science terminology so vue may be easier for lots of web Dev's without a computer science background
Not sure why he/she hates webpack or any sort of web bundler. It’s one of the most nicest things. I can use es6 modules and declare dependencies upfront.
Also I don’t get the hype about vue over react or any virtual dom based framework.
Vue just doesn’t feel like you’re dealing with functions. It’s too much spaghetti.
I want to be able to hot replace templates, it’s controller logic and styles without a page refresh. I also want great type checking and intelligent refactors of props and states
Vue does hot module reload and all that jazz, and it works with Typescript too.
I totally disagree with you about the code being spaghetti. To me the spaghetti is designing views in React and having a relatively simple DOM structure broken into twenty little functions so that it can be expressed as readable JSX.
To me one of the best things about Vue is that it lets you effortlessly choose between and even combine templating and JSX. Templates are vastly easier to read when you need to understand the DOM structure and when you're looking at something on the screen and identifying where it lives in your components. And when you have complex elements where a render function really is better, JSX!
Vue nor react do hot reloading per se. There are official webpack plugins to do so, which the author didn't want to use so presumably that wasn't a motivating factor. I also disagree that small focused components are spaghetti. The authors giant components smell like spaghetti because they mix business logic and rendering. Author should look into separating container and presentation components, which is idiomatic in react
React doesn't force you to break a "relatively simple DOM structure" into twenty functions. That's just shit programming, which unfortunately is library agnostic.
It """works""" with it. React's story is much better on this front. I set up Typescript with Vue at work and:
1. Setting it up and getting it to compile was hell. The documentation was incredibly poor (often out of date on several options) and I often had to try several things just to get it to compile.
2. It was slow with Webpack - far, far too slow to start up (what was once 10 seconds to start up easily was taking 45+). tslint was a no on top of that. I looked into various ways to speed up Webpack, wasting hours trying to parallelize things with various plugins, and found almost everything would just refuse to work with .vue files.
I got this fixed, thanks to fork-ts-checker-webpack-plugin - which didn't actually have .vue support at the time. I ended up having to use a fork by the amazing David Graham [0] which thankfully has been merged now.
3. Vue's "support" for TypeScript isn't there yet. It's maybe 80% there. Vuex isn't typed - which, at least for my company's SPA, kills half the benefits of type safety and requires a lot more type annotations than is pleasant. (Yes, I'm aware you can get Vuex working with some serious hacks... but this isn't documented, and I found out it was possible from GitHub comments. It did not look easy enough for me to do without an hour of pain, so I have yet to try it.)
Also, you can't strongly type props in both directions using the standard template language. In fact, I'm not sure you can strongly type the things you give to a component, only the things you take in... if you use a third party library [1], which modifies an official new way (ES6 class syntax) to declare Vue components.
You could use JSX - which Vue supports - but again, you're going off the beaten path and aren't really writing standard Vue components. Swapping to JSX was not possible at my company - requiring developers to learn an entirely new templating language when they already know Vue components is a no. It's a wonder we're okay with ES6 class syntax.
All this is to say, standard Vue components can't be fully typed. Not only do you have to use a new way to declare them, you have to use a third party library to get proper typing for props and more. And it's still not enough unless you swap to JSX too. (I'm not even sure if JSX would end up working for full type safety, either - Vue might have some stupid thing which screws it all up.)
---
Compare this to React, where because of JSX you get strong typing on literally everything without special hacks. They're not the same here.
Vue is moving very nicely in the direction of more and more TypeScript support - I'm a huge fan of that. I'm glad we swapped over at work. But right now, claiming Vue supports TypeScript is misleading. It's a second class citizen. You're not getting the full benefits. This seems to be changing, but glacially.
(Am I allowed to say that something which might take less than a year is glacial? I guess this is just how web dev is.)
> Not sure why he/she hates webpack or any sort of web bundler.
Not OP, but I have built up a natural aversion to adding any new tool as a dependency to my work flow. More complexity, more edge cases, more things to worry about.
I tried webpack, with settings from the tutorial. It took 7 seconds and the result was a JS file much bloated then the parts used to make it. Given that, why should I bother? I have programming to do, not build tools to yak-shave.
I share the exact same aversion as you (in-fact I'm often criticised for being too far in that direction), but I find Webpack to be a very peculiar target for reducing complexity.
At it's core it's a very simple tool that does exactly one thing (combines multiple JS files into one, using the standard ES6 import/export syntax). Any additional complexity is the user's fault.
browserify did it almost instantly with a much smaller bundle file. all without having to write a script.
It's probable that with enough time spent learning... a build tool... that webpack could perform well. But I want to solve a problem, not learn about webpack.
Honestly, I empathized a lot with this. I spent a lot of time at work writing non-frontend code, and felt pretty rusty once I moved back to it. There are a ton of fuzzy things to learn: what's the right way to require a module? build systems are common practice now? what happened to bower? are there differentiators between node and browser libraries?
Worse yet, every time you search for a topic, there are dozens of conflicting community-generated articles, just because the landscape changes so quickly. I don't think there's a solution apart from "watch what the industry is doing" and "be patient."
Yeah, front-end dev is a mess right now, and it probably will be for a while. I think a simple description of what we're living through is the low level primitives (DOM and JS) are locked in and are gradually becoming more powerful.
Meanwhile developer world doesn't love working on complex apps using low level primitives, and since the web is pretty easy to grok there are a million devs who feel like "oh man I can write a good higher level framework/pattern/tool on top of this," so they charge off and make it.
And the thing is, most of the tools being built are reasonably good and useful, but it is overwhelming trying to keep up.
What I suspect will happen is that the more successful patterns will become more and more deeply entrenched until there are only really two or three accepted "good ways" to build stuff, and then you'll see a few major libraries in each of those camps that rise to the top, and this will all start to settle down into boring old tech as the hipsters run off to tackle some new hot ecosystem.
We're probably still a few years out from that, though :)
It's already happened. There are basically already 2-3 good patterns: Vue, Angular and React. It's just that the existing patterns are far from perfect so the industry continues to evolve at a breakneck pace.
No.. it's "watch what the industry is doing and learn it ". Or, admit the front end is now a full specialization that you don't have, and understand you're not qualified until you learn some new tools and akills.
I've been having this argument constantly at work. Everyone loves our SPA, but they still want to be able to hire really cheap front-end devs to do maintenance. Having back-end devs do MVC and designers doing CSS and light interactivity is a totally valid model, but doing SPA requires specialist knowledge.
I understand why business people are reluctant to view front-end as a real engineering discipline from a cost-perspective, but trying to get a SPA for a JSP prices is silly and unrealistic.
Yep, I've fought this fight multiple times. The latest iteration for me has been managers trying to repurpose React devs into React Native ones at a moment's notice. React Native isn't a replacement for years of familiarity with a platform and knowledge of it's quirks and complexities. If anything it's another level of abstraction and an extra layer of complexity to deal with. And I say this as a veteran React dev who is very much in love with it.
> I’m very bad with the front-end and don’t like it. The rest of our team has the same feelings.
Hmmm..
> In early 2017 we almost solved the problem with the front-end, as we hired an expert who made the whole site over using BEM block technology.
BEM! hahaha
BEM is not mandatory for a good front-end, at all.. It sounds like you actually need a good, experienced and passionate front-end developer. But if you don't want one, I agree that Vue.js is a relatively safe choice. I only do Vue.js for smaller projects, a little bigger and I switch to React or Angular. But I always try to mind (before switching and advocating a library) that there is a fair chance that within 5 years it is deprecated already, just like jQuery.
I didn't mean calling tools themselves "junk", but rather dozens of auto-generated files which don't give me any profits at this time. I am pretty sure all these things make a lot of sense, and we are getting to the point where trying out WebPack might make sense for us.
I made a DAPP with Vue.js recently (www.davidwong.fr/FiveMedium) and it was amazingly fun to learn and use. Things made sense while I had difficulties grasping how to use React or even follow their tutorial to do anything practical.
I'm definitely happy to see more and more people using Vue.js
I also made a couple DAPPs recently, the first using Vue (which I have very little experience in) and the second in Elm (which I have years of experience with and have used in production).
I never thought I’d say this, but I was a lot more productive with Vue and it was more fun. Static types and immutability are great for long term stability and refactoring, but it felt great to just bang out an app in a few hours and not worry about the overhead and boilerplate that comes from using a strict language/framework like Elm. I’m definitely going to use Vue on my next DAPP.
I'm not so familiar with Vue (coming from jQuery -> Backbone -> Angular 1 -> React) but I know there are different ways to write components in Vue (including classes and JSX). Well, it's the first time I saw the style they chose and it looks awful. It seems like Backbone but with everything in a single JS object. A component as a configuration file. Maybe it makes sense for Backend people? (familiarities with defining systems in json, yaml, dockerfile, etc)
I've been doing React for a couple years now, but for the past couple days I've been watching some videos and reading up on Vuej.
The thing that I will always hate about Vuej (and other/most frameworks) are templating engines (aka string code in attributes). That's always going to be a code smell to me.
That said, I can see the appeal to Vuej. There's a very gentle migration path to Vuej. It's much more natural just to use ES5 with Vuej than with React.
Vuej like most "frameworks" is opinionated about the rest of the pieces of the puzzle - routing, state management, etc. React is very a la carte in that regards. State management is still a complete mess in the React world.
I'll probably have to try a small project or two in Vuej. The tooling in VSCode seems to be decent these days.
With that said, definitely an interesting read and reassuring to see that you don't need a million tools to get started. I'm doing less frontend than I used to now, but I'd still like to have a play around with Vue.js at some point to try and avoid the jQuery mess you often end up with when you end up sprinkling some client-side functionality on top of a primarily server-side rendered app.
I feel very productive using Vue. I wish it had first class support for forms though. My home cooked concoction for that works well enough but isn’t ideal. Otherwise, it’s the best thing I’ve used in 2017.
I sympathise a lot with the desire, but if you work with corporate or other markets where old browsers just won't die, then Vue may not be a feasible option.
It actually won't be a point release if I recall correctly, it's just weirdly worded on the roadmap. 2.X (current version) and the next version will be maintained in parallel.
They're using jQuery wrong and now reaching for a framework. If you write bad code in jQuery you're going to write bad code in a framework. I've seen it a dozen times. Use event delegation and behaviors, not "if window.location = ''". That's just wrong. You can solve a ton of problems with jQuery(or plain DOM api) and mutation observers.
I disagree. As someone who recently made the switch from jQuery to React, it is way easier to shoot yourself in the foot with jQuery. React let's you focus on how the component should behave instead of doing mental gymnastics trying to manipulate the DOM. There are always so many edge cases with DOM manipulation, it rarely turns out well for anything but trivial things (which I still use it for).
It's easy to shoot yourself in the foot with any technology. People switch to a technology thinking they're writing better code with it, but in reality they're just a better at coding. Or it's a rewrite of something, in that case you know more about the problem you're solving. If you're bad at coding jQuery, when you switch to Vue or React, you then have gigantic mono components, if else if else rendering, 5000 state variables, or some other thing that you shoot yourself with.
Some technologies make it much easier to shoot yourself in the foot than others. jQuery is in that category. Some technologies make it easy to do things right by making sure that the right way is the path if least resistance.
> React let's you focus on how the component should behave instead of doing mental gymnastics trying to manipulate the DOM
Agreed - a huge benefit of Vue is exactly that - it's declarative. You describe what you want with a (more or less) plain ol' Javascript object, instead of how you want something to work. It's almost like writing JSON - and is just as readable.
Not really sure how you can reach that conclusion. With JSX you are declaring what the HTML will look like, rather than specifying how to do the transitions. It's difficult to get more declarative than that.
Yeah if you need a SPA jQuery won't work. Ultimately react and Vue will give you much cleaner code at the cost of learning the shadow Dom. All the old Dom methods from jquery and vanilla js over to shadow Dom instead.
It will certainly work, there are plenty of SPA which use jquery (or even vanilla JS) for their DOM manipulation. But it will likely be significantly more painful and prone to desync bugs than using a vdom-based system
Not just SPAs either, any non-trivial component is affected.
I challenge anyone to use jQuery to build a SPA and not re-invent backbone (poorly or otherwise).
I built a simple site recently and one complex page ended up with shitty recreations of backbone Model and View.. and never knew until a colleague reviewed my code and suggested I look those up.
I recently did exactly this and it wasn't that bad. It's not that I couldn't use Backbone, I decided not to because I didn't see the point in introducing yet another library when all I really needed to do was bind inputs to a model, which I did in about 5 lines of terse jQuery. Besides, I had custom widgets that wouldn't have benefited from Backbone anyway and would have required customization anyway. I think judicious use of libraries is ok, but tbe more elite among us tend to become libray snobs and shame people for not doing things the "right" way.
> there are plenty of SPA which use jquery (or even vanilla JS) for their DOM manipulation.
I've seen jQuery included in VueJS/react/ng2 for a specific complex plugin, and I've seen it for a few simple DOM manipulations where there was no reason for kQuery to do it instead of the framework, but is there actually a paradigm for jQuery being the root framework in an SPA? I've looked for jQuery SPA and found nothing. Does a jQuery SPA framework actually exist or are you talking about lots of homemade frameworks that use jQuery?
I agree. Generally speaking, jQuery or VanillaJS will be more performant than React. If you combine jQuery with template literals, you can put together some pretty nice, manageable code for most use cases.
Generally speaking a regular dev under normal time/budget constraints will.het better performance out of React or Vue. It takes more time and more expertise to get that "optimal" VanillaJS performance. Analogy: Ruby vs C.
Could you give some examples? When it comes to trivial apps I'd say jQuery could be fine, but it feels like kind of working against what it was designed for. But for non-trivial apps I can think of at least as many jQuery 'gotchas' as I am aware of in React.
If your app is non-trivial, I expect maintainability nightmares in vanilla long before performance issues (which will be in both for people who don't know what they are doing).
I completely agree that you can do a lot with jQuery or even plain DOM and JS. It's often the right way to go when there's already back-end structure like Wordpress, Drupal, or ASP.NET and you just need simple things like form validation.
The benefit that frameworks offer is exactly that structure that jQuery doesn't provide (and was never designed to provide). A long-lived SPA needs good structure. If you aren't good at understanding how to create it yourself a framework can save a LOT of work.
I'm all for frameworks, because jQuery can eventually get out of hand. I just see a lack of knowledge on how to structure basic DOM code, so that's going to transfer into other frameworks. I'm more of a fan of someone going the DOM api route, seeing the pitfalls, then move to a framework. Not necessarily in the same project, just overall. It's good to see the pitfalls so you know why you're choosing something.
Exactly. The OP should learn the underlying technologies, instead of learning frameworks. They even admitted to not being willing to learn properly. At that point, how can you even make a fair comparison?
You could probably make this comparison: For someone who, for whatever reason, doesn't want to spend time learning the underlying technology, they will end up with a better solution if they use Vue.
In my case I have looked at the underlying technology of front end web and it appears to be nothing fundamental. Rather, it's a series of historical accidents, mainly around trying to make a markup based, styled, document behave like an application. I find it hard to get motivated to learn that. According to the article, the likes of me would be better off using Vue or some equivalent.
>You could probably make this comparison: For someone who, for whatever reason, doesn't want to spend time learning the underlying technology, they will end up with a better solution if they use Vue.
Or Wix or Wordpress even.
But for someone who has taken the trouble to develop an in-depth knowledge of, and facility with, the underlying technologies (HTML, CSS and JS), front end development is not that difficult or mysterious. And for them, these frameworks make the process needlessly complex rather than simpler.
Does wix/WordPress have the application level UX capabilities of VueJS/react before becoming a plugin writer? I find the comparison grossly disingenuous. If you were asked to write a TodoMVC in VueJS/react vs WordPress, you'd probably figure out how to start (and/or have already finished a proof of concept) in an hour with VueJS. In WordPress, you'd be 6 hours into the introduction to WordPress plugins and still unsure if a TodoMVC is possible or if WP is the right tool. If you legitimately think what people do with VueJS can be done just as well by juniors in WordPress, then you don't understand what VueJS/react actually do.
> If you write bad code in jQuery you're going to write bad code in a framework.
Preventing this is precisely what frameworks are for. A framework - a good one at least - provides a frame that has you code along guidelines (best practices, opinionated style devised by the framework creator etc.) and therefore prevents you from committing common mistakes.
Using a framework allows you to delegate low-level decisions to someone else, who - hopefully - is more knowledgeable than yourself in that area.
Agreed. I had to make something using jQuery after a couple years of working almost exclusively with React I found that I could mimic react components using jQuery plugins and it looks and works pretty good.
Yeah this is a pretty bad case study. I kept scrolling expecting to see some clean separations and healthy, maintainable components but it kinda just ended abruptly and left us all hanging.
The jQuery might be straight-forward in the sense that you know what `$cardForm.find('input[type=submit]').prop("disabled", false)` does, but the hard part is reasoning about the possible states of your UI when your only source of truth is a bunch of procedural mutations.
Not only does it incrementally change the DOM, but it also queries state from it. We've been trying to move away from that for some time now. I remember that's how jashkenas pitched Backbone 7 years ago.
Still, introducing a framework and a build system and everything that entails for the sake of 300ish lines of code? You could rewrite that in plain js avoiding the pitfalls you mention in less time I would have thought. As others have mentioned they’d be better off employing a front end specialist... whether they’d recognise a good one is a moot point.
Sounds like they could have solved their problem by hiring a solid Front-End Developer. Saying that you like to "focus on the backend" is a lot like saying you only like to do half the work. If you find it too hard to master a whole suite of software that you have ignored for 3+ years, go find someone who already has and quit treating the front end like it's a toy
For some reason the phrase "BEM block technology" makes me cringe. It sounds like something a non-technical manager would say, but these guys are actual devs...
I am kinda new and here is one confusion I still have about frameworks like Vue or React, why do we still need Virtual DOM? Shouldn't the browser DOM already be first enough?
The virtual DOM automatically updates the real DOM for you, in a way that only touches the parts that have actually changed. Think of it like a diff.
This allows developers to focus on the business logic and presentation of their apps without worrying about how to update the DOM efficiently to match the current app state.
Hah! This is a fantastic question... isn't the whole point of HTML that it's a declarative markup language? Isn't the browser supposed to be focused on dealing with a diff between the markup/state changes - and doing it fast?
The DOM itself _is_ a virtual model thing... why do we need to abstract over it- and somehow get performance benefits from an abstraction over an abstraction? Afaik you can't even force a repaint beyond rAF...
If you’re not sure of the “why” of react, I’ve found that Pete Hunt’s talk “Rethinking Best Practices” gives a great overview of the reasoning behind react. Especially from about 15:15.
...from jQuery. Safe to say any JS framework would have been an improvement (and that's coming from someone who has very little love for JS frameworks).
Disagree. Well, better to say 'it depends'. jQuery is still absolutely fine for server-rendered apps that need some client-side functionality. Especially if your devs are well versed in frameworks such as ASP.NET. MVC Core, for example.
Fair point. I think it's sort of a one-or-the-other situation with jQuery or Vue/React/etc, though. If one's a good solution, the other probably can't be.
Anybody have experience with vue building something that is long term, maintainable and very complex? What is the technical dept when compared with React?
Are there options to incorporate type checking into vue?
I think the biggest players (Angular+NativeScript/React+React-Native) have left Vue behind. While they try to abstract the UI problem from problems like native, web or whatnot, leading to better abstractions and ease of use on multiple platforms, Vue and co. are still meddling around on past problems.
You know VueJS has multiple react native alternatives (both the native performance kind and the native look and feel kind and an actual bridge library to react native itself and also support from NativeScript)? I admit that VueJS is probably a minimum of 12 months of maturity behind react at this time, but at least do your research.
Fair point, but I'd like to add that if Vue is able to come up with better solutions to past problems, then they will likely come out on top in the end.
- https://github.com/ServiceStack/Gistlyn
Vue's nicer to use without any build tools using just vanilla JavaScript:
- https://github.com/NetCoreWebApps/Redis
Vue's also nicer for "page-based" Websites that are converted into Single Page Apps. Nuxt.js really shines here which lets you develop complete Websites using Vue's Single File Components and takes care of routing by following a conventional page structure. Nuxt.js + Vuetify will be my goto for many traditional Website style Apps (implemented as SPAs) going forward. It imposes an opinionated convention but saves you a lot of effort having to manually configure and integrate different libraries together.
Vuex is more pragmatic and requires less effort/code to use than Redux, but Redux is great when you need to access previous states, e.g. it makes it effortless to capture "Snapshots" of the entire current state of the App that you can send to someone else so they load your App exactly as you see it:
- https://github.com/ServiceStack/Gistlyn#snapshots
Or when you need to sync state changes between network apps:
- https://github.com/ServiceStackApps/typescript-redux
But if you don't need these features, in general Vuex/Mobx is easier and requires less effort to develop with.