How and why we moved to Vue.js
mkdev.me
mkdev.me
- 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.
I watched a video about Vuex last night, and with mutations, it seemed more convoluted than mobx state tree.
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.
EDIT: I assumed Vuex state was immutable outside of mutations, but that's only true with 'strict' mode enabled.
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.
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.
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.
I agree with you point btw.
“You can use the v-model directive to create two-way data bindings on form input and textarea elements.”
`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.
1) You can still use v-model with Vuex: https://vuex.vuejs.org/en/forms.html
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]
[1] - Vue Query Builder (https://dabernathy89.github.io/vue-query-builder/) - try adding a 'Range' rule to see this in action
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.
If you're new, ignore [babel, redux, (insert buzz lib here)] and just build something. Checkout https://medium.com/@clmyles/react-without-npm-babel-or-webpa... on how to create something with just React.
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.
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.)
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 right now. 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 right now is to conflate two entirely separate issues.
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.
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.
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.
EDIT: I realize now Vue does have optional support for JSX and you are not forced to use a templating language.
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.
The CSS styling for a component is handled much more cleanly than React does.
The lifecycle methods are named more sensibly.
You can add as little or as much Vue as you like, very easily, using no build system or going as far as to only use the build system.
Instead, vue was built by one guy, and it’s en par if not even better than react/angular.
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.
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.
Compare that with vue.
You can even use JSX if you want.
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.
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.
This is not a pro for me, I much prefer using the templates of Vue.js than JSX.
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.
When choosing a framework, simplicity, performance, and support are the main things you should look for and Vue is a hands-down winner here.
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.
React is the simplest, most powerful library I've used in my life. It's the community that (often misguidedly) adds the complexity.
But I agree, I love the simplicity and it fits well with my rapid descent into being a functional programming weenie.
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.
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/
But how about an explanation of how to compile the .vue files (used in the examples) to JS? Or how to do without them?
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.
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).
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 suggest create your actual project with vue-cli once you get familiar with the vue syntax.
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.
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.
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.
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.
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.
But the simplicity of react/preact can’t be beaten.
Vue does have nicer bells and whistles though.
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
Typescript with React is a godsend.
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!
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.)
[0] https://github.com/Realytics/fork-ts-checker-webpack-plugin/...
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.
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.
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.
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."
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 :)
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.
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.
Babel, postcss and yarn.
And then you stated a 3rd person saying:
"It’s not junk, these are the most important tools"
Disrespectful AND lying, nice combo you got going...
I'm definitely happy to see more and more people using Vue.js
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.
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.
"Will be targeting evergreen browsers only in order to leverage native ES2015 features"
https://github.com/vuejs/roadmap
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.
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.
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 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'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?
But the thing is we aren’t really building websites anymore. We are building web applications. And jquery just plain sucks for that.
With React, you can quite quickly stumble over performance bottlenecks in non-trivial app when you don't know what you are doing.
Especially on mobile devices.
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.
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.
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.
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.
284 lines of (relatively straightforward if poorly written) jQuery? Oh the horror!
`Want to be as cool as Kirill Shirinkin?
Then enroll to the training! In his articles Kirill shares only a glimpse of his true knowledge.`
I think I've seen enough but thanks for the offer.
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.
So when I got the end and he advertised to share more wisdom for a fee I nearly fell off my chair.
> 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
Seems like they reduce the front-end to CSS.
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.
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...
Something doesn't smell right.
You can totally use Vue with any MVC, no need to convert to SPA style
Vue is just that nice to work with.
"Hire a programming mentor and learn how to do everything he knows."
Might be worth being a little more inclusive here.
Are there options to incorporate type checking into vue?
I had the feeling 2017 was year of Vue.js
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.
They all have great solutions.