12 ms·

How and why we moved to Vue.js

233 points by fodoj 9y ago

wdhilliard 9y ago
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
- ggregoire 9y ago
  Exactly. > 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.
  - BigJono 9y ago
    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...
    - altern8tif 9y ago
      Same here. BEM is not "technology". It's a philosophy or an organisational pattern.
kevin_thibedeau 9y ago
2018. The year of VueJS.
- moocowtruck 9y ago
  i think 2018 is the year of 'who cares js'
  - k__ 9y ago
    Yes. 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.
    - adverbly 9y ago
      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.
      - k__ 9y ago
        After using Angular, React and Vue I think this is greatly a matter of taste. They all have great solutions.
    - Can_Not 9y ago
      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.
deleted 9y ago
[deleted]
mi100hael 9y ago
...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).
- weego 9y ago
  Why? Their example of a stripe backed payment form is massively over engineered as a Vue component
  - astral303 9y ago
    Details?
- GordonS 9y ago
  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.
  - mi100hael 9y ago
    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.
  - kangoo1707 9y ago
    What jQuery could have done with those server-rendered apps, Vue could always do better. jQuery is just bad because of its DOM mutation paradigm. You can totally use Vue with any MVC, no need to convert to SPA style
IgorPartola 9y ago
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.
- mythz 9y ago
  Vuetify Forms has great support for client validation + easy ways to hook up server validation: https://vuetifyjs.com/components/forms https://vuetifyjs.com/components/forms
lol768 9y ago
Unsure if it's just me, but the article doesn't seem to render the text properly: https://i.imgur.com/donfa0W.png https://i.imgur.com/donfa0W.png 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.
amelius 9y ago
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.
- ohceecho 9y ago
  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/ https://vuejs.org/v2/guide/
  - amelius 9y ago
    > The official website includes a way to use it by just including a script from the CDN, on the "Get Started" page. But how about an explanation of how to compile the .vue files (used in the examples) to JS? Or how to do without them?
    - baby 9y ago
      You don't even use .vue files if you follow the tutorials, this is for an advanced usage.
    - ohceecho 9y ago
      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 https://vuejs.org/v2/guide/deployment.html).
byte1918 9y ago
I was expecting a comparison to react or angular. Comparing jQuery to a reactive frontend framework in 2018 is just... too easy.
adventured 9y ago
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.
azr79 9y ago
Anything compared to jquery looks good, would be more reasonable to compare it to Angular, or React
erokar 9y ago
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.
- baxtr 9y ago
  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.
  - ryanianian 9y ago
    Spying? Conspiracy theory?
    - baxtr 9y ago
      You’re right I should have called it “data collection approach to create a strategic advantage”
      - vertex-four 9y ago
        So exactly how does React collect data on your users?
  - efdee 9y ago
    This is ridiculous. Please back up your claim that either Angular or React include literally any kind of spying capability whatsoever.
    - dictum 9y ago
      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.
Tade0 9y ago
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.
- pensivemood 9y ago
  I cannot imagine how Angular2+ is complex and you have to remember stuff that is hard to fit in memory to build a typical single page app? Are you building ng2 with typescript or javascript?
  - joshribakoff 9y ago
    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
- nojvek 9y ago
  After dealing with angular complexity, vue is great. But the simplicity of react/preact can’t be beaten. Vue does have nicer bells and whistles though.
baby 9y ago
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
- fbonetti 9y ago
  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.
dham 9y ago
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.
- whalesalad 9y ago
  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.
- dmethvin 9y ago
  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.
  - dham 9y ago
    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.
- atoko 9y ago
  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?
ourmandave 9y ago
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.)
- huskyr 9y ago
  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.
  - bartread 9y ago
    Agreed. I used to be a fan of Angular but all that drama put me off it for good.
  - krob 9y ago
    Vue is the php of JS frameworks. Feeling a bit ironic for using it, I'm also a user of php, and it just feels right.
- ohceecho 9y ago
  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.
- bartread 9y ago
  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 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.
franciscop 9y ago
Using tools that other people created, documented, and put up for free for anyone to use and calling them "junk" makes me really sad :(
- fodoj 9y ago
  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.
  - franciscop 9y ago
    How is that possibly true? You even named the junk: 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...
mythz 9y ago
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: - https://github.com/ServiceStack/Gistlyn https://github.com/ServiceStack/Gistlyn Vue's nicer to use without any build tools using just vanilla JavaScript: - https://github.com/NetCoreWebApps/Redis 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 https://github.com/ServiceStack/Gistlyn#snapshots Or when you need to sync state changes between network apps: - https://github.com/ServiceStackApps/typescript-redux 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 9y ago
  This is a pretty good comparison, especially of Vuex/Redux, which is helpful. I had been wondering what the tradeoffs are. Thanks!
- Bizarro 9y ago
  As an aside (and since you brought up snapshots), mobx state tree https://github.com/mobxjs/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.
- dabernathy89 9y ago
  You may know this already, but using Vue Dev Tools you can easily export & import Vuex state.
navd 9y ago
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. 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-webpack-1e9a6049714 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.
burlesona 9y ago
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.
- zmmmmm 9y ago
  > 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.
brwsr 9y ago
> 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.
- conradfr 9y ago
  I've always disliked BEM code looks-wise. Maybe it's a shallow reason to avoid it ...
  - mercer 9y ago
    I figure if you're gonna use BEM, you might as well just go for CSS-in-JS these days.
bichiliad 9y ago
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."
- hashkb 9y ago
  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.
  - james-mcelwain 9y ago
    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.
    - BigJono 9y ago
      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.
- burlesona 9y ago
nojvek 9y ago
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 Typescript with React is a godsend.
- burlesona 9y ago
  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!
  - joshribakoff 9y ago
    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
  - froogle 9y ago
    > Vue [...] works with Typescript too. 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/pull/77 https://github.com/Realytics/fork-ts-checker-webpack-plugin/... [1] https://github.com/kaorun343/vue-property-decorator https://github.com/kaorun343/vue-property-decorator
jaequery 9y ago
In my opinion, Vue is the most elegant javascript library out there. Jquery used to take this spot for me, but Vue has superseded it . 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 9y ago
  > 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.
  - BigJono 9y ago
    I'm curious how people think React is overkill when it's entire API pretty much boils down to one or two functions. React is the simplest, most powerful library I've used in my life. It's the community that (often misguidedly) adds the complexity.
    - jaequery 9y ago
      It's the React ecosystem. People didn't come up with the term javascript fatigue for nothing.
    - mercer 9y ago
      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.
jaequery 9y ago
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.
- spraak 9y ago
  > 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.
  - fbonetti 9y ago
    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.
    - FlorianRappl 9y ago
      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.
      - ohceecho 9y ago
        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. I agree with you point btw.
tiuPapa 9y ago
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?
- fbonetti 9y ago
  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.
- dakom 9y ago
  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... Something doesn't smell right.
- EdwardMSmith 9y ago
  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. https://youtu.be/x7cQ3mrcKaY https://youtu.be/x7cQ3mrcKaY
crimsonalucard 9y ago
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?
Bizarro 9y ago
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.
ggregoire 9y ago
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)
mythrwy 9y ago
`There are 284 lines of such unbearable mingle, which is absolutely impossible to grasp for anybody.` 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.
- always_good 9y ago
  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.
  - tomgp 9y 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.
  - mythrwy 9y ago
    Ok great, but I'm just laughing because I regularly get mudballs 10-20 times+ that size and I figure them out. So when I got the end and he advertised to share more wisdom for a fee I nearly fell off my chair.
deleted 9y ago
[deleted]
nikon 9y ago
That example component code is hideous. It reminds me of Backbone, and not in a good way.
nthnclrk 9y ago
On the front page: "Hire a programming mentor and learn how to do everything he knows." Might be worth being a little more inclusive here.
- drumttocs8 9y ago
  Boy, it's a good thing we don't speak a language with strict grammatical gender, or you'd be all kinds of pissed off
mruniverse 9y ago
How useful are these "Why we moved to ..." blog posts?
sjellis 9y ago
Vue.js is due to drop support for legacy browsers in March (oddly, in a point release): "Will be targeting evergreen browsers only in order to leverage native ES2015 features" https://github.com/vuejs/roadmap 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.
- breakingcups 9y ago
  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.
luord 9y ago
Similar experience to mine, only I already had experience with the frontend and other frameworks. Vue is just that nice to work with.

233 points by fodoj 9y ago

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

ggregoire 9y ago
Exactly. > 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.
- BigJono 9y ago
  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...
  - altern8tif 9y ago
    Same here. BEM is not "technology". It's a philosophy or an organisational pattern.

kevin_thibedeau 9y ago

2018. The year of VueJS.

moocowtruck 9y ago
i think 2018 is the year of 'who cares js'
- k__ 9y ago
  Yes. 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.
  - adverbly 9y ago
    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.
    - k__ 9y ago
      After using Angular, React and Vue I think this is greatly a matter of taste. They all have great solutions.
  - Can_Not 9y ago
    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.

deleted 9y ago

[deleted]

mi100hael 9y ago

...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).

weego 9y ago
Why? Their example of a stripe backed payment form is massively over engineered as a Vue component
- astral303 9y ago
  Details?
GordonS 9y ago
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.
- mi100hael 9y ago
  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.
- kangoo1707 9y ago
  What jQuery could have done with those server-rendered apps, Vue could always do better. jQuery is just bad because of its DOM mutation paradigm. You can totally use Vue with any MVC, no need to convert to SPA style

IgorPartola 9y ago

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.

mythz 9y ago
Vuetify Forms has great support for client validation + easy ways to hook up server validation: https://vuetifyjs.com/components/forms https://vuetifyjs.com/components/forms

lol768 9y ago

Unsure if it's just me, but the article doesn't seem to render the text properly: https://i.imgur.com/donfa0W.png https://i.imgur.com/donfa0W.png 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.

amelius 9y ago

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.

ohceecho 9y ago
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/ https://vuejs.org/v2/guide/
- amelius 9y ago
  > The official website includes a way to use it by just including a script from the CDN, on the "Get Started" page. But how about an explanation of how to compile the .vue files (used in the examples) to JS? Or how to do without them?
  - baby 9y ago
    You don't even use .vue files if you follow the tutorials, this is for an advanced usage.
  - ohceecho 9y ago
    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 https://vuejs.org/v2/guide/deployment.html).

byte1918 9y ago

I was expecting a comparison to react or angular. Comparing jQuery to a reactive frontend framework in 2018 is just... too easy.

adventured 9y ago

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.

azr79 9y ago

Anything compared to jquery looks good, would be more reasonable to compare it to Angular, or React

erokar 9y ago

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.

baxtr 9y ago
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.
- ryanianian 9y ago
  Spying? Conspiracy theory?
  - baxtr 9y ago
    You’re right I should have called it “data collection approach to create a strategic advantage”
    - vertex-four 9y ago
      So exactly how does React collect data on your users?
- efdee 9y ago
  This is ridiculous. Please back up your claim that either Angular or React include literally any kind of spying capability whatsoever.
  - dictum 9y ago
    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.

Tade0 9y ago

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.

pensivemood 9y ago
I cannot imagine how Angular2+ is complex and you have to remember stuff that is hard to fit in memory to build a typical single page app? Are you building ng2 with typescript or javascript?
- joshribakoff 9y ago
  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
nojvek 9y ago
After dealing with angular complexity, vue is great. But the simplicity of react/preact can’t be beaten. Vue does have nicer bells and whistles though.

baby 9y ago

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

fbonetti 9y ago
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.

dham 9y ago

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.

whalesalad 9y ago
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.
dmethvin 9y ago
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.
- dham 9y ago
  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.
atoko 9y ago
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?

ourmandave 9y ago

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.)

huskyr 9y ago
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.
- bartread 9y ago
  Agreed. I used to be a fan of Angular but all that drama put me off it for good.
- krob 9y ago
  Vue is the php of JS frameworks. Feeling a bit ironic for using it, I'm also a user of php, and it just feels right.
ohceecho 9y ago
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.
bartread 9y ago
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 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.

franciscop 9y ago

Using tools that other people created, documented, and put up for free for anyone to use and calling them "junk" makes me really sad :(

fodoj 9y ago
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.
- franciscop 9y ago
  How is that possibly true? You even named the junk: 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...

mythz 9y ago

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: - https://github.com/ServiceStack/Gistlyn https://github.com/ServiceStack/Gistlyn Vue's nicer to use without any build tools using just vanilla JavaScript: - https://github.com/NetCoreWebApps/Redis 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 https://github.com/ServiceStack/Gistlyn#snapshots Or when you need to sync state changes between network apps: - https://github.com/ServiceStackApps/typescript-redux 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 9y ago
This is a pretty good comparison, especially of Vuex/Redux, which is helpful. I had been wondering what the tradeoffs are. Thanks!
Bizarro 9y ago
As an aside (and since you brought up snapshots), mobx state tree https://github.com/mobxjs/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.
dabernathy89 9y ago
You may know this already, but using Vue Dev Tools you can easily export & import Vuex state.

navd 9y ago

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. 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-webpack-1e9a6049714 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.

burlesona 9y ago

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.

zmmmmm 9y ago
> 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.

brwsr 9y ago

> 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.

conradfr 9y ago
I've always disliked BEM code looks-wise. Maybe it's a shallow reason to avoid it ...
- mercer 9y ago
  I figure if you're gonna use BEM, you might as well just go for CSS-in-JS these days.

bichiliad 9y ago

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."

hashkb 9y ago
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.
- james-mcelwain 9y ago
  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.
  - BigJono 9y ago
    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.
burlesona 9y ago

nojvek 9y ago

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 Typescript with React is a godsend.

burlesona 9y ago
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!
- joshribakoff 9y ago
  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
- froogle 9y ago
  > Vue [...] works with Typescript too. 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/pull/77 https://github.com/Realytics/fork-ts-checker-webpack-plugin/... [1] https://github.com/kaorun343/vue-property-decorator https://github.com/kaorun343/vue-property-decorator

jaequery 9y ago

In my opinion, Vue is the most elegant javascript library out there. Jquery used to take this spot for me, but Vue has superseded it . 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 9y ago
> 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.
- BigJono 9y ago
  I'm curious how people think React is overkill when it's entire API pretty much boils down to one or two functions. React is the simplest, most powerful library I've used in my life. It's the community that (often misguidedly) adds the complexity.
  - jaequery 9y ago
    It's the React ecosystem. People didn't come up with the term javascript fatigue for nothing.
  - mercer 9y ago
    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.

jaequery 9y ago

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.

spraak 9y ago
> 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.
- fbonetti 9y ago
  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.
  - FlorianRappl 9y ago
    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.
    - ohceecho 9y ago
      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. I agree with you point btw.

tiuPapa 9y ago

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?

fbonetti 9y ago
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.
dakom 9y ago
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... Something doesn't smell right.
EdwardMSmith 9y ago
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. https://youtu.be/x7cQ3mrcKaY https://youtu.be/x7cQ3mrcKaY

crimsonalucard 9y ago

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?

Bizarro 9y ago

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.

ggregoire 9y ago

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)

mythrwy 9y ago

`There are 284 lines of such unbearable mingle, which is absolutely impossible to grasp for anybody.` 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.

always_good 9y ago
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.
- tomgp 9y 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.
- mythrwy 9y ago
  Ok great, but I'm just laughing because I regularly get mudballs 10-20 times+ that size and I figure them out. So when I got the end and he advertised to share more wisdom for a fee I nearly fell off my chair.

deleted 9y ago

[deleted]

nikon 9y ago

That example component code is hideous. It reminds me of Backbone, and not in a good way.

nthnclrk 9y ago

On the front page: "Hire a programming mentor and learn how to do everything he knows." Might be worth being a little more inclusive here.

drumttocs8 9y ago
Boy, it's a good thing we don't speak a language with strict grammatical gender, or you'd be all kinds of pissed off

mruniverse 9y ago

How useful are these "Why we moved to ..." blog posts?

sjellis 9y ago

Vue.js is due to drop support for legacy browsers in March (oddly, in a point release): "Will be targeting evergreen browsers only in order to leverage native ES2015 features" https://github.com/vuejs/roadmap 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.

breakingcups 9y ago
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.

luord 9y ago

Similar experience to mine, only I already had experience with the frontend and other frameworks. Vue is just that nice to work with.