How we do Vue at GitLab: one year later
about.gitlab.com
about.gitlab.com
We did a POC in both React/Vue and ended up using Vue mainly due to the following reasons:
Single File Components
Single file components (.vue files) is the best thing about Vue. I understand this might be a personal preference, but we wanted to avoid CSS-IN-JS. Our designer could churn out neat html/css, but was a beginner in Javascript. With Vue's single file components, he could also hack parallely with us while iterating on html/css.
Standard / Official way of doing things
This again is a personal preference but Vuejs comes with a recommended way to do a majority of things. Vuex(state management) and Vue-Router are provided/maintained by same Vue core team.
React at times can be overwhelming for beginnners, just because of the amount of choice available
Example:
Google Search for 'React CSS style' [https://www.google.co.in/search?q=react+css+style] points to a bunch of links all of which link to valid solutions, but I have to go through a few of them before I get what I am looking for.
Similar search for 'Vue CSS style' [https://www.google.co.in/search?q=vue+css+style] all top links lead to official documenation on vuejs.org.
Excellent documentation
Also, as a team we were primarily writing Angular 1 when we decided to choose a frontend framework for newer projects. I feel this also made our transition to Vue easier vis a vis React
import styled from 'styled-components'
const Container = styled.div`
padding: 10px;
background: ${
({ isHovered }) => isHovered ?
'green' :
'red'
};
`
const H1 = styled.h1`
font-size: 15px;
`
const P = styled.p`
font-size: 10px;
`
const MyComponent = ({ isHovered }) => {
return (
<Container
isHovered={isHovered}
>
<H1> Hello <H1>
<P> This is a thing </P>
</Container>
)
}> Our designer could churn out neat html/css, but was a beginner in Javascript.
I write JS every day, and frankly that code looks like an unholy mess to me, so I can't imagine what it looks like to a beginner. Is "styled.div``" a function call? It's not self-evident. How do you do inheritance? Is that a template string with functions inside it? Would that CSS autocomplete?
That code looks very much like it sacrifices ease of writing CSS for ease of writing JSX. That isn't the correct tradeoff for everyone.
Yeah styled.div is a function as you can check out in the mdn docs I linked, it's really cool stuff.
Inheritance is done like:
const List = styled.ul`
li {
padding: 10px;
}
`
const HeavyPaddedList = styled(List)`
li {
padding: 20px;
}
`
const ListItem = styled.li`
padding: 10px;
`
const HeavilyPaddedListItem = styled(ListItem)`
padding: 20px;
`
I've never worked with designers that wrote css, I'd also probably not trust them to do so (my own failings).
I don't agree that it looks like an unholy mess (hyperbole may be lost on me), but I can see how it could be jarring at first look. I had a similar reaction when I looked at Relay (https://facebook.github.io/relay/), when they used literals for data fetching.
So, yeah, you lose all the syntax highlighting etc. that comes with just writing normal CSS. I don't think it's unreasonable for a designer to object to that - how would you feel if you were presented with a build system that required you to write all your JavaScript inside one big string statement?
Maybe it's just me, but I don't find it intuitive at all. `styled` has properties for, I assume, every HTML tag? But it can also be called as a function for inheritance purposes? And that inherited call appears to use the same tag as its parent... but what if I want to reuse styles across different tags? How could I define some shared CSS properties I'd use across different elements?
Don't get me wrong, it is cool stuff. But it also feels far too much like hand-wavey magic stuff. I've literally never used Vue before, but looking at this page:
https://vuejs.org/v2/guide/single-file-components.html
I have zero confusion about how to write styles for it. And I really don't understand why styled-components would be worth the extra effort by comparison. What does it bring to the table? It's different without a compelling reason for being different.
Except you don't. Editor support is quite good, and syntax highlighting, syntax validation, auto-completion, etc all work.
I mean, same way with Vue really. If the editor didn't know wtf a Vue file is, you'd lose all the integration too.
In a way, that's fair. In another way, the example single component Vue file I linked to is an HTML file. It has a <script> tag and a <style> tag. Just associate .vue with HTML and you're done.
That gets to my broader point as well - styled-components reinvents the way you declare styles and the way you apply styles, and requires the entire thing to be written as a JS file. And for what? I still don't understand what the advantage is over a syntax everyone already knows (and has validators for already!)
The reality is that tooling for templates (even Angular or Mustache style) is pretty terrible. Tooling for CSS is just as terrible. Static analysis or doing simple things like interpolation of data is pretty darn bad.
But JavaScript tooling isn't half bad. It's not the best there is, but its still reasonably advanced. Thus you have React, which is basically just JavaScript and objects. Sure JSX, but when used in React, it's just sugar to define those objects (hyperscript would work just fine too if you don't want to use a compiler, and early on in React's life just creating the objects from factories was just fine. Certainly better than weird templates with bad tooling).
Once it's all javascript, everything works: my linter works (and is certainly more advanced than css linters), both major type systems work, my refactoring tools work, and I have all the language at my disposal without learning anything new to do stuff like conditionally showing or hiding things. No need for an ng-if, v-if or whatever.
The same logic keeps going with styled-components. Associate the styles with a plain old JavaScript object, using javascript constructs (in this case, template strings), and all the tooling to manipulate them, interpolate them, or type check them just works (eg: TypeScript isn't bad at typing interpolations in template strings). And if that's not good enough, Glamorous is just objects so it's even easier.
Now I mentioned both styled-components and glamorous...normally this logic would heavily favor the later, but for some reason, tooling for styled-components have gone above and beyond to make up for the shortcomings of template strings, so it ends up working better for me.
Maybe someday some very motivated people will make tooling for the non-JS parts of ecosystems that are not "all JS", and this point will be moot, but right now the React ecosystem is the one that lets you most heavily lean on tools.
It's probably why it doesn't look so great from a newcomer perspective though: if you're not at a point where you're trying to squeeze every last bits of power from the tooling ecosystem, then it's just overhead and a waste of time.
Vuejs is great. Found it to be easy and simple to understand. Big thumbs up for Evan You.
We have hundreds of full sized frontend applications, millions of lines of both javascript and scss. Thousands of extremely complex i/o operations and algorithms. We push the tools in the ecosystem to their limit and have to write our owns where they fail us.
And when I'm at home making a small app, create-react-app and VSCode, then npm install-ing styled-components, is all I need to replicate 80% of the above. It's all just JavaScript so all my tools just work the way I expect them to.
Not everyone needs (or want!) this. And that's okay.
It seems a little odd that the front-end designer, who is in our hypothetical not comfortable enough to actually work on component themselves, would be brought in to tag-team with someone else who also doesn't feel comfortable enough to do the work themselves.
https://github.com/webpack-contrib/extract-text-webpack-plug...
I guess now you have two files per component but to me, it's well worth it.
One of the boons of react is that you can create a set of reusable base components that can be built upon throughout your app.
If you can code-split the app, lazy-loading components as needed, and if you can cache all of the static app anyway, why does it matter if the presentation is tied to the logic?
The same can be said for vue.js. :)
The two languages have many merits and they both make their own sacrifices. But they are ultimately two peas of a pod.
Like Thor and Loki. But who is Thor and who is Loki? ;)
I've seen it with other stacks as well with almost complete re-implementations, a lot of duplicated effort and it feels like it goes against the packaging philosophy for javascript
https://github.com/facebookincubator/create-react-app
npm install -g create-react-app
create-react-app my-app
cd my-app/
npm start
I'm probably starting to sound like a shill for React. I've used both and love both. I do like that React is "just javascript", which I think is why I use it.
So...2030.
https://html.spec.whatwg.org/multipage/scripting.html#custom... https://dom.spec.whatwg.org/#shadow-trees
Any application that I've built which actually required a technology like Vue or React was a significant undertaking and a few hours getting up and going (not that either of them require anywhere close to that) is nothing.
Secondly, a lot of my projects just don't need anything else. If i have a 2 weeks contract with a client, i'm not going to setup webpack, a ci server and docker.
Having the choice to scale up or down is an amazing feature.
It makes experimenting easier for beginners, for people considering switching to it, for people who are already using it and want to try something outside the context of their existing codebase, for people writing tutorials and demos, etc.
The less bullshit to wade through when using a tool, the more situations it will be applicable to, regardless of skill level or project size.
My pet peeve with react is that I can't just code. I have to stop every 10 steps and reflect on the tool I use, instead of the problem I'm trying to solve.
Create React App gives you a zero configuration way to not only write hello world, but also bootstrap a non-trivial production ready application. In the company I work for, we were previously using JSPM/SystemJS/Gulp. We replaced all of that with create-react-app. It allows you to very easily bootstrap existing applications on top of it: http://fredrik.anderzon.se/2016/12/04/adding-create-react-ap...
And if you want full control of your project, you can "eject" and CRA will generate the webpack configuration file being used so that you can tweak to your heart's content.
I use React daily, and the whole experience has been extremely pleasant.
That means you want to be able to understand it well enough to write the webpack required for a react pack from memory.
And with react, that's years of learning.
Thank you! Every time I've tried react (and enough attempts were made to finally decide it was just not for me), there was always something in the back of my mind that I didn't like and I just couldn't put it to words. You just described what it was.
And, if one forgoes tooling, then the situation is like the one you described in your previous comment: an afternoon just to get a "Hello world".
I highly recommend watching Rich Hickey's "Simple Made Easy" [1] talk which covers how the right ("simple") choice may not be the "easiest" (convenient, most familiar) one.
The talk I referenced talks about how the opposite is often true. Tools that result in objectively simpler systems can come with a initially steeper learning curve.
> You can't accurately deduce from time alone that the time to pick up Vue was based on familiarity with similar libraries.
True, I was really just suggesting questioning instincts when evaluating tools based on the initial 'time to get started'.
I'm aware of Rich Hickey and Clojure. In my experience with Lisps, although they are superficially simple, they make you do more abstraction work than is necessary in more commonly used high-level imperative languages. Lisp seems to strongly encourage building a high number of helper functions, which is fine if you're highly opinionated about how a job should be done, and less so if you just want to import some battle-tested libraries and write something that gets the job done. I suspect this is where the learning curve with Clojure really comes in, in that it's more closely related to being learn how to architect an application in a Lisp-friendly way than it is about getting familiar with the language.
I've heard it suggested somewhere that possibly the leap is in believing that 'a simple thing + a simple thing = a simple thing'.
In summary, vue offers a simpler hands on experience while allowing smooth learning curve to more complicated setup matching react's.
React just throws you in unkown waters and say 'now swim'. And on the side of the river, 3 persons are screaming to you contradictory advices.
BTW - You don't need webpack for React either. It is entirely possible to write React without it.
Not at all. That's the beauty of it. A lot of projects just drop Vue in a script tag and use no components. There are 1000's of projects out there with such a scale that anything else would be overdoing it.
> BTW - You don't need webpack for React either. It is entirely possible to write React without it.
Technically yes. But realistically no. First, you will find almost zero doc/tutorials on how to do so. All the ecosystem and community assumes webpack, and a top-down component architecture. If you ask on a forum how to do x, people will promptly tell you to use Redux. And the React API is clearly not comfortable anyway without tooling.
It's a bit like saying "well you could perfectly code a Java project without an IDE". Yes you can. But who would do it ?
And the reason is: projects starts small, and grow. But not all grow to become large.
The wonderful thing with vue: you start small, and IF you reach the stage you need more, you can do so easily.
Another issue with CSS-IN-JS seems to be security - as it opens up another vector for cross-sight scripting attacks - see here for example. [1]
If I end up going with React, I'll probably avoid CSS-in-JS outside of React Native.
>You can’t use CSS in react-native apps. But you can use CSS-in-JS with styled-components. [2]
Disclaimer: met James K Nelson of reactarmory.com at #hntokyo on Thursday - otherwise unaffiliated.
[1] https://reactarmory.com/answers/how-can-i-use-css-in-js-secu...
From the Vue documentation [1]:
>Even if you don’t like the idea of Single-File Components, you can still leverage its hot-reloading and pre-compilation features by separating your JavaScript and CSS into separate files:
<!-- my-component.vue -->
<template>
<div>This will be pre-compiled</div>
</template>
<script src="./my-component.js"></script>
<style src="./my-component.css"></style>
Is there any tool from the Node ecosystem designed to reduce that boilerplate?
Thanks for any insights!
[1] https://vuejs.org/v2/guide/single-file-components.html#What-...
Newer JavaScript functionality makes that work nicely.
Almost all of my components fit on one screen.
If you like that, why not go with Ember?
I feel like this is Vue starting to get the React treatment. React was (and still is!) a very simple library until people realized they needed to do fancy things to make complex applications manageable. Redux came out, everyone fell in love with it, and React+Redux became an official couple. This lead to the perception that React has a steep learning curve because new developers were learning React+Redux without learning React first.
I wonder what Vue can do to avoid the same pitfall.
This image, from React conf years ago, communicates this sentiment perfectly: https://i.stack.imgur.com/tnk9a.png
Now I did two projects without and everything is nice and simple.
Because everyone with a React job or substantial React project uses Redux (or a similar library). It is common for junior devs to rush through learning libraries in hopes of being employable or a "real developer" as soon as possible.
React itself is an incredibly simple library: you can explain the entire thing in a few sentences. In my experience it has an undeserved reputation for being more complex than Vue.
I think React is very cool, and I haven't tried Vue, but everything on this thread points to it being a much better learning experience, and might be better for small or middle-sized projects.
I mean, it's necessary, at some point, to see a full system that uses all the tools for delivering a real application. But, it is definitely a lot of concepts to grok at once. I actually found it most useful to see tutorials that started without even using React, and built up from first principles to what React does (given that React is conceptually very simple, this isn't so crazy...a toy version of React can be built in an hour or so, so it's perfect for a video or article; much of the complexity in React is in making it fast rather than in making it work). But, that may not be a necessary first step for people who have more frontend or reactive programming experience than I have.
But, the learning materials and marketing are the ones that bug me...especially the ones that neglect to mention that the materials cover React+product, and only mention React in the title. You might not even know it's marketing until you've read half the darned thing and the crux of the thing turns out to be "now create an account here and use this service to outsource the specific thing you googled to learn how to implement yourself". GraphQL has a lot of the same thing going on. It's like "how to draw an owl", only instead of "now draw the rest of the fucking owl", it's "now send us money every month for the rest of your app's life and we'll draw an owl for you".
Yes, since probably early 2016, many tutorials have basically said "you need to learn React and Redux together", and that's the message that a lot of junior devs have been taught.
However, my own advice is the same as Dan Abramov's: you should focus on learning React first. Once you understand React thoroughly, then you'll better understand why a state management lib like Redux _may_ be helpful for your situation.
That's not really a fair position to take. It basically allows you to believe that React and Redux don't need to be learned together.
Put yourself in the shoes of a CTO at a new startup. They need to decide whether to build their company on top of React or Vue. They need to make this decision quickly.
Is it really fair to say they don't need to learn Redux? And that maybe Redux won't apply to their situation?
Of course Redux will apply, because Redux is for all intents and purposes how you manage state at scale. And everyone who's entering the field who isn't a junior dev is thinking "We need to come up with a way to manage state at scale. Does Vue help us do that, or are we stuck with React+Redux?"
It really doesn't help matters when you look into big players like airbnb and discover that they wrote their own state management framework rather than use Redux. They even have a two week onboarding process for new devs that teach them how to write features using their blend of tech. It's a bit... Eh... The whole thing just feels like WPF, a dead technology that few people here have probably heard of. There must be a simpler way.
Okay, how big is our web application? A few pages with a form? We'll avoid Redux for now. We might even avoid React.
It's like anything else: should you set up a Spark cluster if you're only processing Gb's of data? Probably not, but you might need it some day -- so make your best guess.
Build something small. Learn React. When you're comfortable, and your small app grows in to something a bit bigger that might merit it, learn Redux.
Then, build something small. Learn Vue. Repeat.
Now you understand both options enough to make an educated decision. Feel confident building your big, gotta-get-it-right-off-the-bat startup project in whatever works best for you.
Theoretically, you can get by without learning it. In practice, the moment you try to build a real company, you need it. That necessitates learning Redux.
I think this is an uncomfortable thought because it implies that Vue is way easier for devs to get into, and that's step one to displacing React+Redux. But that seems like an uncomfortable truth.
Whoever is in charge of React needs to give Vue the Snapchat treatment. Take them seriously as competitors. There's still time.
You have to take yourself out of the "experienced React+Redux dev" mindset and put yourself in the shoes of "Experienced dev looking to invest in one of two ecosystems" mindset. Which one is the path of least resistance?
The point is, React+Redux people would love to believe that it's "Vue+VueX." But in reality, it feels like "just vue." A sword is stronger as a single piece, and Vue+VueX feels like a single piece.
It's up to people to learn both and decide for themselves, but my argument is simply this: it's a mistake to underestimate the traction Vue is gaining.
There's a strong temptation to blame the dev: They're not smart enough, they should have been able to pick up Redux easier, Vue+VueX is the same as React+Redux. But all I can do is report my experiences, and an honest survey of the ecosystem would lead us to conclude that Vue+VueX is far easier to learn without sacrificing any flexibility for your company in the long run.
To be clear: I like both React and Vue and am fundamentally skeptical of arguments that one is significantly better/worse/different than the other.
My first step is to hire someone that knows how to build a FE app. We'll use the tool that someone is familiar with.
If you're a CTO of an incubator startup with 2 people straight out of college who learnt Python and basic JavaScript and you're trying to build a serious web app from there, well, it doesn't really matter what you pick, you'll have to rewrite it in a few months anyway (that's a pretty common scenario).
Almost everyone I know learning React in a professional capacity ends up having to learn Redux at much the same time, my experience is very much the opposite.
Trainer here. I train in React and in Vue.
My students do 3 times the work with raw vue than in raw react. Every one of them. All the time.
It's not even on the same map.
Starting with vue is just: add a script tag, put your template here, now your data here. Done.
The start up experience is nothing alike.
Like you can write Java without IDE. Nobody would. But plenty do with Python.
I haven’t found anything nice for a guide in building a real world application like this. Maybe it would involve multiple things vue + ? + Postgres or Mongo or some other option. But I want love something that would hold my hand start to finish connecting the dots.
Vue on the other hand was so simple. And the documentation made getting hello world done in a few minutes. This got me off the ground and made me feel productive as I felt I knew right away what vue was doing at a most basic level. Then it was just constant learning on top.
If you love to type, though, I highly recommend Redux!
const ADD_TODO = 'ADD_TODO'
import { ADD_TODO } from '../actionTypes'
function addTodo(text) {
return { type: ADD_TODO, text }
}
dispatch(addTodo(text))Also you don't have to import your actions, it's just a smart thing to do. This gives me heartache a bit: https://github.com/vuejs/vuex/blob/dev/examples/counter/Coun...
Vuex & Vue are the easier APIs to learn. Not only that the developer ergonomics are just better for Vue's API. For example in vue you have "mounted()" instead of "componentDidMount()" or "ngOnInit()". Likewise, redux requires learning CS terms (if you don't know them) like thunk, saga, memoized selectors, etc. Vue uses more layman's terms, like "computed" instead of "memoized selector" which just makes it easier to learn.
My big hangup with Vue is having to declare reactive properties up front. It's author says this is a best practice anyways, but it leads to hard to debug issues when you accidentally declare new properties at runtime & you get race conditions. With react & redux both making immutability possible & encouraging immutability, you get easier to debug apps. But there is a more up front investment.
I also really love Vue's single file components. I know you can do that in Angular & React, but again the API is just so much more ergonomic in Vue.
Vue and Vuex seem less clever JS (shiny es6 features), less clever programming (mutability etc) which I feel may be a detriment for complex apps in the long term but it is simpler.
(I may be biased because before Vue and React/Redux I did Angular1 & React/Reflux and I view Vue as a Angular/React mix and Vuex is not far from Reflux)
That's not part of Redux, it's a separate design pattern you can use with any Flux architecture. React-Redux doesn't even require you to do it that way, and for good reason: you might not need it. There's nothing wrong with just importing a store reference wherever you want it. That's a totally reasonable pattern for some applications.
This illustrates my point I guess. There's so many people thinking about how to architect and implement React applications that there's a lot of cargo-culting.
You might still need to place actions/selectors in their own directory since they're not necessarily specific to any reducer. I believe this is how sagas are organized, though.
Thematically, it may be a result of obsession over tools instead of product which occurs in other areas like photography, writing(hipster typewriters), and others. In tech, technology as lever supports a "hacker" mindset of getting 10 for 1. However this misses the point of hacking to get around your weaknesses in order to focus on your core competency which MUST intrinsically have value instead of being an empty shell.
The core competency for many client side developers is probably more rooted in a form of design than pure technical ability. Design, like music, writing, speaking, and art have incredibly low barriers to entry. This can create an arrogant mindset from people coming from more rigorous disciplines. Instead of focusing on the thing that must be done, they try to take shortcuts that only have the appearance of reaching the goal.
When you're hyper-vigilant about simplicity, you end up creating the simplest design that meets the goals. It takes a little extra time, but it's so worth it.
* https://laracasts.com/series/learn-vue-2-step-by-step * https://laracasts.com/series/testing-vue
It's good enough and fast enough as it is for most medium side projects.
And the awesome thing is that you can scale it up for this one big project you need it for.
I’ve never used Vue but I’m also curious to see how it and VueX fares in this regard.
Not me.
But I think it’s good that there’s competing library, though the problem domain felt eerily similar.
However, I would argue that is not ok in that it should never be necessary and it's use would be a code smell to me and indicate that the code in question is likely not using Vue properly.
I suspect it would be more valuable in the long term to ask people to take more time and learn to use Vue instead of jQuery to solve the problem at hand.
Edit: I should note that Gitlab came to the same conclusion and I misread their comments on it as accepting the argument that it would be ok for querying the DOM. What the article says:
> At first I had several discussions about using jQuery with Vue. Some had said it might be OK, but only in read-only (querying) situations. However, after doing the research, we found that it is not a good idea to use jQuery with Vue. There will always be a better solution. We found that if you ever find yourself needing to query to DOM within a Vue architecture, then you are doing something wrong.
This I completely agree with.
First, you can gradualy migrate from jquery dom to vue. As both are very light, having both is not bloated.
Plus, you need something to do ajax anyway, and if your site uses it, why add axios as well?
Actually I'd say that vue is probably the best tech if you want to progressively improve a legacy jquery heavy website instead of doing a complete rewrite.
I would argue as well that AJAX requests don't belong inside Vue components. They belong in services and those services should ideally be behind the Vuex store, but there is nothing wrong with not using Vuex.
If we were just talking about using jQuery for AJAX given that you already were using it, then sure that's fine, use it instead of adding something else like axios. From the article what was being proposed was using it to query the DOM. There is no use case for that with Vue.
https://caniuse.com/#search=fetch https://www.netmarketshare.com/browser-market-share.aspx?qpr...
Plus, although fetch is tremendously better than XMLHttpRequest, it still has quirks. It doesn't send cookies by default. The promise resolve on success on code 400 and 500. Headers are verbose. You have to encode and decode json manually. You have to force CORS for it to work.
The end of this article show you the problem:
https://medium.com/@shahata/why-i-wont-be-using-fetch-api-in...
Eventually you end up writting code to wrap fetch. So why not just use jquery or axios ? It's already documented and tested.
I have a hard time taking seriously the opinion of someone who bases their sweeping global assertions on "research" and not on actual experience.
Emacs was very difficult for me when I first started learning it. It was much more difficult than using a simple text editor (and this was with 10 years of programming experience)! Yet I persevered and you know what? After giving it some time and learning it properly I found myself vastly more productive with the tool.
Some things don't lend themselves well to immediate gratification. If the OP provided even a hint as to why React was more difficult for him I'm guessing it's not something with React but rather that he was using two completely different state management solutions.
I'm a big vi and sublime text user but always open for better tooling.
btw - I actually agree with you on the learning thing but React just sucks. I'm able to get shit done with Vue and at the end of the week I haven't wasted three afternoons learning jsx/webpack/deployment/relearning-a-new-way-of-doing-css blah blah. I say this with some hesitation but CSS is a solved problem in my opinion with Sass.
If you mainly choose technology based on the fact it doesn't take any effort to learn at all, you will soon hit a wall on what software you can use overall.
With Vue you can write a scalable understandable application using the documentation. The same criticisms do certainly apply, but many of the advanced features are worked into the application.
For example Vuex is bundled into Vue and has verbose and opinionated documentation on how it lives in your vue application.
The React and Redux developers are incredibly good at what they do - they've also spent a lot of time putting out material, books, video courses, blog posts, talks help everybody else understand the new paradigm they've created
They can't be that stupid when a lot of modern javascript framework components are either direct clones of, or influenced by, their work
The JS ecosystem is like the baskin robbins of st. Which is mind-blowing because JS has gotten so much better and browsers have gotten so much better in the past 10 years. Yet the apps people are creating today are worse that the st people were creating with IE8 and jQuery.
I am hardly the only one who has recognized this as a problem. I see an article from a major dev on the same topic on a regular basis here.
Can you list off any tools that you like where there aren't any people using them to make crap? Does the fact that some people produce junk undermine your success using a tool? Or is it actually inevitable that people will use a tool to produce garbage?
So I'm not understanding your point.
Every time I see a topic about Vue or React (or practically anything JS related) I see the polar opposite of the disarming friendliness coming from the community leaders on Twitter.
... But in all seriousness, there is a diversity of viewpoints here. It’s a conversation and people vote up things they find thought provoking. Would you prefer only people who think React and Vue are great post here?
I'm talking about comments like
"God this is horrible. It's ugly. Hard to read."
"ugly piece of code"
"React failed miserably"
"The JS ecosystem is like the baskin robbins of st"
and so on.
React took time to learn, but it was definitely worth it. The one way data flow and explicit event handling (aka no ng- or v- tags) just seems cleaner to me.
Of course this is no way a critique of Vue. Its a great framework for people who want that sort of thing.
This "hurr jQuery and everything it brought sucks" mentality is not good.
Put a function on the vue component that will make a request, keep all the data stuff in vue.
React for example wrecks your HTML with react related attributes on every DOM element.
There is nothing wrong with storing some information in the DOM.
Except you're coupling your application state with the document model. If you ever do anything to change the DOM later on, (like installing React into your codebase) it'll come back to bite you in the ass hard, as now you need to find a means to communicate state that you just threw into the DOM like it were a slightly more acceptable global variable.
E.g. on the server-side .html.erb they'd have something like
`<div... data-endpoint="@controller.url">...</div>`
Our frontend application was originally built with Rails. When we added Vue, we did not refactor our entire code base.
This means that we've kept the existing server rendered pages. Once the page is rendered we build our vue app on top of it.
The reasons why we pass certain data through HTML is: 1 - Avoid duplication. Our endpoints and paths are still built in rails, by passing them through data attributes we keep only one single source of truth 2 - Passing data from the server to the Vue App Some data is not being sent through the API, but we still need to access it. For those cases we also use the data attributes.
We know that this is not ideal but it was a mid term solution that allowed us to quickly add Vue.
You can read more about our architecture with Vue in this blog post: https://about.gitlab.com/2017/06/29/gitlab-at-vue-conf/
I decided on Webpack. First time using it and no idea where to get started. I ended up downloading some boilerplate webpack / vue / vueX that now does everything for me, but I have no idea what webpack is actually doing or how it is doing that. I'm not even sure how big this stack is... how big is my chain of dependencies here?
Am I going to be in trouble at some point? It feels like I'm on borrowed time here and my little house of cards will come tumbling down soon.
You really don't want your first time reasoning about your build process to be some kind of deployment disaster or production bug. And that's exactly what these tools are selling you.
For a long time, the way webpack worked in the Vue template was at least 70% black magic to me. I had some issues with it, sometimes I solved those issues after google-ing a lot and landing on completely unrelated projects Github issues for a fix. I never quite felt that I had mastered that whole ecosystem like I felt I had mastered my regular programmin languages and tools.
My day job is C# and my day IDE is VS2017. I've been given permission to explore doing a new application in .NET Core with Vue. So, I've started to translate the default template from vue-cli to Visual Studio and I have learned a LOT by trying to glue these pieces together that no one else seems to have glued together for me. Luckily, MS has done a lot of work to make React play nice with VS2017 and that seems to benefit Vue as well.
I'm not quite there yet, a few last issues remain. Most of them have to do with Intellisense's understanding of Typescript vs. Webpack's understandinf og Typescript. Some remain unsolvable for now (Single File Components using Typescript and SCSS).
Still, the point I'm trying to make is that being forced to read through the entire thing has increased my understanding of the Webpack process immensely. I feel like I'm at 80% mastery now.
I think this quote from this article is a good summary of this discussion: "Scala people don't have time for redditing and blogging, they're busy getting crap done."
While it might seem like all the JS devs are arguing on here over their choices, there are many folks who are silently being incredibly productive with whatever tool they choose.
I was stuck with the Xbox so I had to validate that reality to myself by defending it on the internet.
It's no different on HN.
Web Components might be the solution, but it's not exactly ready yet: https://caniuse.com/#search=components
To understand how to improve JS, try writing in vanilla JS (no frameworks) and find the common pain points. Organise with fellow JS developers to get features to address these shortcomings in the EcmaScript standard. Once this is done, use tools like Babel to polyfill the missing functionality from the EcmaScript standards until browser vendors implement them. Rinse, repeat.
I did end up needing to reach for jQuery in two situations with Vue. First was to auto focus form inputs when the form becomes visible. For the life of me could not find a good way to do this with Vue. Second was when a particular architecture of the app required using lots of modals. Vue just doesn’t do well with components that live inside modals and need to be reset whenever a modal is opened or closed. Basic CRUD using Bootstrap modals is a huge pain, especially the Update mode. I ended up creating rather gross hacks for notifying the component in the modal that it needs to be reset.
One of the coolest things I did with Vue/VueX is having updates about server side events delivered via WebSockets. A single generic connection to the server pushes CUD events about all the relevant models to the client, where VueX duetifully executes the ADD/UPDATE/REMOVE actions for instant updates to all parts of the app.
The primary reason why I would not adopt Vue is because Vue is still driven by Evan You - which is great, but if something had to happen to the guy (and I hope nothing does), I'm unsure Vue would have the long term support & drive it does right now.
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...