Hacker News new | past | comments | ask | show | jobs | submit login

I 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 minutes?".

I ended up choosing Vue, mainly because it used simple objects for models and I could literally just pass stuff I got from SignalR directly into it and have it show up. Almost everything else I tried had some type of wrapper/proxy around the data, which meant you had to run through some mapping exercise to get models working. I was close to deciding on Mithril, but when I found vue it just clicked with me way more. I actually really wanted to do React, but Vue was just so much more approachable that I couldn't justify spending the extra time learning React.

The real test however came months later, when I went to modify and add more functionality to my simple debug UI. I was able to pick it up nearly instantly, and even made some fairly substantial changes.

Contrast to my experience with say, Ember. We have a big app written in Ember, and every time I try to do even what I think should be a simple change (after not touching it for months), it takes me 5 times longer than I thought, and I end up spending most of the time fighting with it before realizing I forgot one of the 5 places you have to modify to reference an additional dependency, or some other equally trivial but infuriating detail.

You can learn the basics of Vue in minutes, and be quite adept within hours of it. That's something not a lot of frameworks can claim, and it's a seriously underrated benefit.

I have almost the same experience as you. I am maintaining big Ember app and have exactly the same problems as you described with it.I am interested in Vue lately also because it's so lightweight, easy, well structured, documentation is excellent, ecosystem around it is excellent and i have so much more freedom than in Ember. Author really cares about it, issues on github shows that, only 50 open and 3000 closed.

Interestingly enough, maintaining and developing Vue.js is now the author's full time job! Check out his patreon here: https://www.patreon.com/evanyou

Holy cow this is impressive. How do you think he came to this achievement? Was he marketing himself really well? I honestly would love to know what it takes!

Context: I'm currently developing a new web-based remote desktop tool in Rust and I'm still on the fence as to whether or not to release it open source.

It's a port of some work I did on Gate One that ultimately couldn't be released due to the limitations of X11 permissions in multi-user environments (too insecure).

What's funny is that I'm looking at using Vue for the client!

50 open, but only 9 of them are actual bugs!

> it's a seriously underrated benefit.

It is not without a cost, the cost being an lack of standard ways to accomplish things. For long running projects where devs may come and go, having a standard way to do things is an incredible advantage, and will result in a much more consistent code base.

For real world front end project, this is a much more important concern, imho, than ease of picking up. For your particular use case, I agree something like Vue is a better fit.

Long running projects in JavaScript may not be that long really. If you leave any codebase for a couple years, things would have changed so drastically, new devs may not even recognize the code. An year old JS project may be using React, a 2-year-old project could be using Angular, a 4-year old project might be using Backbone, a 6-year-old could have $("#el").bind() all over while 8 year-old project could have been in Prototype.js.

Since I've gone through the same experience like this, I'd like to know if this is a norm :D.

I've seen people do write-up of how they re-write the front-end from jQuery to Angular|Ember|React so it's not like there are many long-running JS projects that require solid structure. 3 years old (small-medium size) projects tend to get re-written.

Here's another one that I've seen and experienced before: 10 years old product where some section of the products are written in pure JS, some section in jQuery, some section in BackboneJS + Marionnete, some section using EmberJS.

thats an interesting reflection thank you

I've heard this argument before and I find it fascinating. Why can't we have something that is both standardized and easy to pick up? Is there something inherent to one that blocks the other? Any ideas?

Disclaimer? I don't use Vue, but I've seen this argument made for Ember (against Angular 1.x) and Angular 2 (against React).

>Why can't we have something that is both standardized and easy to pick up?

Simply because one has to learn the standards in the former case. In the latter, it is mostly left to the users imagination and their own sensibilities, which differ from person to person.

But does being "easy to pick up" intrinsically mean things are left to the user's imagination? Can't we make something that is standardized AND easy to learn?

Because "easy to pick up"/"easy to learn" means "most ideas aren't new to me", i.e. "it adapts to my particular way of thinking".

Thanks for sharing your experience. As someone at a place with both ember and Mithril it's relevant to me. Can I trouble you for a couple more details?

Did you use MSX with Mithril? We found Mithril to be usable without MSX but clicked more for people with MSX.

What thoughts do you hear from people who work on the ember app regularly?

> Did you use MSX with Mithril?

No, because it was green-field and I was trying to keep it as simple as possible; having to have a build step to run the MSX tooling was not really worth the complexity.

> What thoughts do you hear from people who work on the ember app regularly?

Mostly frustration, honestly. The main developer (who spends most of his time in Ember, though wasn't part of the team when it was originally built) has more background in Angular, and a number of times has lamented how much easier things are there. Although he's still reasonably productive now, it took months to get to that stage. Everyone else comes and goes, depending on what we're working on, and the general feelings seem to be somewhere in the spectrum between mild frustration and hate.

Maybe another interesting point.. We used to get new hires to start with fixing small UI bugs to help them learn the systems and do something with immediate highly-visible impact. We really can't do that with Ember.

I think if your style/mindset perfectly meshes with that of Ember, and you specifically decide to devote a considerable amount of time (months) to becoming an Ember expert then you can certainly master it and make good use. I'm not sure you'd produce anything better than someone who had the same time and level of mastery of React or Angular or Vue, however.

For MSX projects where you don't have a build step just load MSXTransformer.js (122 KB). It isn't that big a runtime cost.

For development that makes it a bit easier, I'd hate to add an unnecessary 122kb in production, though.

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.

I write Ember for external apps at A-Big-Tech-Co. but use vue.js for the internal stuff. The difference in readability, code size, and customizability is really starkly in favor of vue.js to me, though ymmv

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.

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.

> I wanted a real-time web UI to visualize some of the data

Got the same problem, but we already went for React/Redux and it wasn't really nice.

I would go for Cycle.js in my future projects. Because everything is modeled as a Observable (no differentiation between data and UI) and it allows to handle real-time data really well (backpressure, etc.)

I want to learn Angular2, but am struggling to find a good source, I want to also build real-time web UI, albeit not for visualization. The problem of documentation is very real. Thank you for the feedback on Vue! I will look at it now.

The Angular 2 documentation is actually really good IMO. Have you looked at the tutorial (https://angular.io/docs/ts/latest/tutorial/)?

I found the docs hard to understand. Maybe it is just that the component based concept is difficult to understand for me as a newbie. Anyways, between vue.js and angular, which one do you think is recommended for a newbie to the front-end world?

Angular is more for the entrprise/large apps, if I were you I'd start from the vue.js, it's a relatively small tool, but powerful, not so complex and has a great docs. I've an extensive Angular v1 dev experience and I don't recommend it. Angular v2 is a complex thing, it has many dependencies (it fetches many npm packages) and dev env is more complicated.

Yes, exactly. Angular is difficult to understand. I'll give vue a shot, it seems their documentation is excellent

hmm I used signalR with angular 1.x and can't speak for your 15 min requirement but I definitely didn't have any need for proxies or model mapping. I suppose if you're using knockout you'd need that (at least call a utility function to translate plain objects into KO objects) but did you find that with Angular?

I actually didn't get to Angular. I put it down on the list because it was while Angular 2 was in alpha, and there was a lot of controversy and uncertainty around it at the time, and it was very unclear from my perspective of which version I should even look at.

Angular 2 was alpha, still changing, and had the potential the community would fork and I'd be stuck on the wrong side. At the same time, Angular 1 was of course 'old', and there wasn't any real migration path yet, so I didn't want to be stuck on the old version and have to re-do everything anyway.

I was happy enough with Vue before I got to actually building anything in Angular, and from reading docs I didn't see anything compelling enough over Vue (in either 1 or 2) to warrant going further with it.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact