I'm in the process of learning React, so I don't have any strong opinions of my own yet. I've read through the Vue.js "Getting Started" docs and it does look very intuitive/simply. However, what motivates me to learn React is the fact that I can build an app once and then use React Native to create an iOS and Android app. I'm assuming this isn't a requirement for Jacob and the Gitlab team but I'm wondering if his decision would be the same if he had to support native apps as well?
Why we chose Vue.js
241–250 of 282 posts
Re: Why we chose Vue.js
#242I do very little web these days, mostly working on backend data processing, network I/O and distributed comms. A bit over a year ago, I wanted a real-time web UI to visualize some of the data I had on server-side, which I was trying to do using SignalR. I went back through some of the popular frameworks, with a pretty simple mindset of "Can I read the 'getting started', and get something basic working in about 15 min…
Could you please elaborate more on mithril vs. vue? Was it ease-of-use, performance or something else that pulled you over?
This is simply my highly subjective opinion, so take it for that, but it was really a number of factors.
Template format.
I actually really like Mithril's view format: it's an API built exactly as it should be -- to make using it very intuitive and natural. I also think it's a great solution technically, since it fluently combines a shorthand for generating HTML with data binding and lets you use native javascript (making it easy to build parts with functions or loops or whatever).
What I didn't like was actually working with it, as a lazy and mainly non-web developer. I like to copy and paste chunks of markup from bootstrap's documentation or other places. Recreating is fine for small things, but then I started porting pieces of another internal app that involved at least a couple hundred lines of HTML. There is(/was) a tool to convert, but it didn't work well enough to be usable for me.
I also realize there's MSX now, but I don't remember it at the time: I'm not sure if the documentation was lacking, or I was just tryin to avoid the complexity of a build tool for this (or both).
For my purposes, the only really fundamental difference between the two was the template format, and being able to stick HTML into Vue, add a couple attributes and have it work just worked better for me.
Community/Growth Potential
I felt the Vue community was bigger and growing more. The Mithril documentation was and continues to be great, but at least at the time there didn't seem to be much writing about it beyond the Mithril site.
Contrast to Vue, where it was easy to find many blog posts, StackOverflow questions/answers, etc.
I've used my share of frameworks/libraries that were later abandoned, and I really try to avoid that.
Re: Why we chose Vue.js
#243Why is it that the first instinct of some developers is to go out and 'choose' a framework? Even before you know the thing you're building is going to be around for awhile, people automatically think they need a framework to do anything these days.
Does it feel good to let someone else make critical decisions for you, instead of thinking for yourself? Can all projects really be distilled down into some javascript framework?
The benefits of using a framework these days are rapidly evaporating as what is trendy today likely won't be in a few years anyways. And the truth is after so many months or years or commits, the benefits of structure of the framework start to fade away as the application becomes more customized and bespoke. All the complexity is in the actual application functionality, not the tiny little savings and poor abstractions that a come with a framework.
I've worked for large tech companies and small alike. It all goes the same way. Some developer who is super opinionated and passionate props up their framework of choice, or does some kind of perfunctory analysis of the "current best" of whatever is available at the time and the rest of the other more submissive developers go along with him. It has more to do with group dynamics than has to do with actual technical merit, or what is best for the product or business.
Then, once the system has become a ball of mud, the "lead" guy leaves. Or he proudly exclaims there's a new hotness in town, and that we need to rewrite our application in this new thing because it's faster, or better, or you get to type less. Or some other such bullshit. He'll then go to give demo's of how fast you can make a simple app that has nothing to do with anything -- like a simple TODO list -- "look how fast it renders!" he'll exclaim (of course forgetting to tell everyone the first page load or stale cache hit is actually worse).
I personally hate giving up the freedom of what abstractions I get to decide on, how to structure my code, how to organize my API's, etc. for a supposed one size fits all solution created by someone I've never even met or talked to, and for code that I haven't reviewed.
If it's a library that's doing something useful and providing a great API, like some 3D graphics, drawing primitives, ML, database engine, etc. that's a different story. That is useful software that actually does stuff. But for "rendering" (I say that lightly because the browser does the rendering and layout, a framework merely is a middle-man) forms and buttons and keeping state of an application? Or telling you how and where to put source files, and name things? That's your job as a developer to come up with these conventions and to build an application that is 1:1 with the problem domain.
Re: Why we chose Vue.js
#244Ok, so I've built stuff in Vue.js, React and Angular and I need to understand all the rage. I mean, Vue.js is just like Angular but with less features? I like that it's slimmer, don't get me wrong, but I just don't understand the "woah, Vue.js is the shit!" when we've had Angular for so long. I put this in contrast to React where it's a completely new concept.
Agreed, I feel like I'm missing something here. I had thought that react "won" over angular because people generally preferred one-way data flow vs. angular's two-way data bindings. At least for me, that's one of the biggest reasons why I feel like I understand react better than angular. It's a little verbose at times, but it does make it pretty easy to follow. And it looks like Vue.js is a two-way data binding frame…
In React the idea that the state controls the app and as long as you maintain control of your state your app becomes nearly deterministic is powerful.
In this way Vue or more specifically two-way data binding struck me as a step back.
Or am I misrepresenting Vue?
Re: Why we chose Vue.js
#245Earlier quoted context omitted.
Vue looks interesting. I went through a similar thought process,but ended up with Riotjs. Maybe if I had heard of Vue earlier, I would have chosen it.
I find Riot simpler and cleaner. The issue with Riot is that the 2.x version is rather slow, but the now-in-alpha 3.x fixes that.
Had a good experience with Riot. Imo Riot needs better/more docs and recipes for once you get past the beginner stage.
Re: Why we chose Vue.js
#246There's something that irks me about incorporating logic into templates. UI development is hard enough without having to bounce between js and templates to figure out how a component is actually going to behave. I haven't used Vue or React, so this is all just my gut speaking, but at least with React all the logic is there in front of you. In my mind, if there's a loop or a conditional or whatever piece of logic that…
I just don't like the bidirectional data binding that vue seems to bring with it... I've had enough experience with this in Angular at this point to know that it's painful... then the easiest way around those issues is to use classes, and computed property getters and setters. In the end, it's just painful. React is much clearer here, but there is more of a cognitive load in getting used to it, there's less magic at…
Vue 2.0 moves away from two-way binding.
Re: Why we chose Vue.js
#247Earlier quoted context omitted.
Sure popularity ruins many things. Music, movies, books, software libraries. However, you don't have to use React. React is a set of concepts. I personally really enjoy programming with those concepts (I just wish it wasn't JS). If you don't want to use Facebook's implementation, there are many other implementations.
> I just wish it wasn't JS. Try Clojurescript. It is truly amazing.
As long as you can stand Lisps.
Re: Why we chose Vue.js
#248After using React, I am firmly in the #nevertemplates camp. I don't ever want to learn a template DSL again when I could be using the full power of javascript.
Jsx is horrible is mixing markup and code all over again A DSL like Elm does is much better
jsx compiles to plain old function calls, which is how you write your templates in elm as well. there's very little difference besides developer ergonomics.
Re: Why we chose Vue.js
#249Earlier quoted context omitted.
I find Riot simpler and cleaner. The issue with Riot is that the 2.x version is rather slow, but the now-in-alpha 3.x fixes that.
Had a good experience with Riot. Imo Riot needs better/more docs and recipes for once you get past the beginner stage.
Agreed. I've been loitering on their github trying to get a read on whether they're planning to do that. I get the impression they'll revamp everything when the 3.0 final release is ready.
Riot is really very poorly advertised and Vue is generally drinking its milkshake in that regard. It's a shame really, not that Vue isn't really neat (because it is), but because Riot is just really lean and productive but nobody knows about it. The vast majority of front-end library comparisons don't even include it.
Re: Why we chose Vue.js
#250As someone who went through the complete frontend hype-trains (jquery, backbone, angular, ember, react, all in production): Vue.js 2.0 with single file components is exactly what everyone looks for desperately. - performance: faster than react now - learning curve: a few hours from scratch - getting started: cli-tool for initial scaffold & configuration - components: simple .vue files with a , and . Super easy to get…
Isn't Vue.js hype too? I mean if I look at the GitHub stars it seems pretty hyped to me. (It's between Angular/React and Ember)
Personally it's Angular 2.0 for me. I'm a big fan of Angular 1.0 but can't stand how complex it has become. I want to be able to start using a framework in a matter of hours, not weeks. Most of Angular 2 complexity is unecessary and I write large SPAs ,not toys, but I don't like the noise. I use Go and Python on the server, I don't want to have to manage a Java style application on the client, because that's what it is another version of GWT with Typescript in place of Java.