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.
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.
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.)
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.
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.
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.
> 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.
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/
> 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.
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!
> 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.
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 :)
> 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.
[+] [-] mythz|8 years ago|reply
- 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.
[+] [-] faitswulff|8 years ago|reply
[+] [-] Bizarro|8 years ago|reply
I watched a video about Vuex last night, and with mutations, it seemed more convoluted than mobx state tree.
[+] [-] fny|8 years ago|reply
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.
[+] [-] dabernathy89|8 years ago|reply
[+] [-] jaequery|8 years ago|reply
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.
[+] [-] spraak|8 years ago|reply
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.
[+] [-] navd|8 years ago|reply
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.
[+] [-] ourmandave|8 years ago|reply
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.)
[+] [-] erokar|8 years ago|reply
EDIT: I realize now Vue does have optional support for JSX and you are not forced to use a templating language.
[+] [-] GhostVII|8 years ago|reply
[+] [-] agumonkey|8 years ago|reply
[+] [-] wishinghand|8 years ago|reply
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.
[+] [-] Tade0|8 years ago|reply
[+] [-] baxtr|8 years ago|reply
Instead, vue was built by one guy, and it’s en par if not even better than react/angular.
[+] [-] ohceecho|8 years ago|reply
You can even use JSX if you want.
[+] [-] spion|8 years ago|reply
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.
[+] [-] baby|8 years ago|reply
This is not a pro for me, I much prefer using the templates of Vue.js than JSX.
[+] [-] collyw|8 years ago|reply
[+] [-] jaequery|8 years ago|reply
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.
[+] [-] mercer|8 years ago|reply
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.
[+] [-] amelius|8 years ago|reply
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.
[+] [-] ohceecho|8 years ago|reply
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/
[+] [-] zmmmmm|8 years ago|reply
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.
[+] [-] Can_Not|8 years ago|reply
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.
[+] [-] ergo14|8 years ago|reply
[+] [-] theprotocol|8 years ago|reply
[+] [-] adventured|8 years ago|reply
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.
[+] [-] burlesona|8 years ago|reply
[+] [-] zmmmmm|8 years ago|reply
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.
[+] [-] Tade0|8 years ago|reply
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.
[+] [-] nojvek|8 years ago|reply
But the simplicity of react/preact can’t be beaten.
Vue does have nicer bells and whistles though.
[+] [-] pensivemood|8 years ago|reply
[deleted]
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] nojvek|8 years ago|reply
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.
[+] [-] burlesona|8 years ago|reply
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!
[+] [-] HumanDrivenDev|8 years ago|reply
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.
[+] [-] bichiliad|8 years ago|reply
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."
[+] [-] burlesona|8 years ago|reply
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 :)
[+] [-] byte1918|8 years ago|reply
[+] [-] brwsr|8 years ago|reply
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.
[+] [-] conradfr|8 years ago|reply
[+] [-] franciscop|8 years ago|reply
[+] [-] fodoj|8 years ago|reply
[+] [-] baby|8 years ago|reply
I'm definitely happy to see more and more people using Vue.js
[+] [-] fbonetti|8 years ago|reply
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.
[+] [-] ggregoire|8 years ago|reply
[+] [-] Bizarro|8 years ago|reply
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.
[+] [-] lol768|8 years ago|reply
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.