Hacker News Reader

Comment by sergiotapia | Hacker News Reader

After being burned really badly by Ember and Meteor, I'm probably never going to use tools that are all-in-ones ever again.

With React I get something laser-focused, just does 1 thing well and that's it. With Vue, I have to buy into the entire ecosystem.

I don't want to experience what I did with ember and meteor ever again in my professional life. I think about all the great developers I've worked with and I looked up to, and almost all of them hated all-in-ones. I rolled my eyes when I was younger, but today it's like damn these guys had a point!

View on HN

I really don't think Vue is an all-in-one. It handles the UI side and the binding and rendering, but is otherwise the least opinionated of any framework I've seen with regard to how you structure and write the rest of your JS. It's much more like the Backbone and Underscore days, except even less opinionated and boilerplate-heavy.

Vue is the antithesis of Angular 1 in that sense. No stupid ontology of inane design patterns - no services, no providers, no factories, none of that mandatory crapola.

Vue isn't even close to all in one, and in fact markets itself as the "progressive framework for building user interfaces":

"Unlike other monolithic frameworks, Vue is designed from the ground up to be incrementally adoptable. The core library is focused on the view layer only, and is very easy to pick up and integrate with other libraries or existing projects."

I agree with the general notion, but I fail to see how one would consider Vue an all-in-one, its feature scope and actual size in KB are much closer to small, view focused frameworks such as React.

Out of curiosity, how did Ember and Meteor burn you so hard and why are you so averse to "all-in-one" tools as a result?

A typical all-in-one framework is Ruby on Rails. It is great to quickly start a project that does basic things planned for by the framework.

But as your project grows, and you start to need special, custom things (and you inevitably do), you understand the "Rails" part. You have to move along the rails. This leads to a growing number of ugly hacks, just to keep the whole thing within one framework. The problem is that you can't replace one component you want different. Everything is cross-dependent, aka "integrated".

In the long term, libraries rock, and monolithic frameworks suck. But in the beginning, the lure of a monolithic framework us strong.

What drives me insane about Angular, both 1.x and 2.x, is the sheer amount of idiosyncratic boilerplate required to merely get started and do things the "framework way". It's unreal, though of course Angular 2.x takes that to a whole new level. AngularJS could at least be written in vim without boilerplate generators and meta-meta-meta tooling.

I suppose the thinking behind all these services, providers and factories was that they give mediocre developers that don't really know how to program a more common vocabulary and a set of childproof "design patterns" to grok — that's always easier from a management perspective than giving people who don't really know what they're doing the freedom to architect. But it just frustrates the snot out of actual developers who just want to be left alone and resent having to shoehorn their _entire_ application code base into some framework's mandatory structure, by way of which there are still yet more APIs and conventions to learn and with whose changes it is necessary to keep up ...

In this sense, Vue wins very big. It handles data binding and rendering/UI generally, but in no way premeditates how the rest of my JS is going to work.

So ... actual developers are people who don't work on teams for large scale applications? Because what you call "childproofing" is basically the most obvious tenets of a shared codebase.

Sure, but there's a subtle difference between having to adhere to shared internal conventions and structure vs. having to adopt some overly complicated and constricting external framework's contrived conventions so that (in theory) a few people don't drive the bus off the cliff as often.

While react is perfectly capable of being mixed freely with vanilla js, you'll likely find that once you start down the react path and build up a library of components, it starts to make sense to do your project 100% in react.

that's not what they mean - they're talking about how ember/meteor etc prescribe how to do everything in the application, like routing, etc - with react you have your pick of routing libraries or can roll your own

> With Vue, I have to buy into the entire ecosystem.

Vue is really just a component framework that deals with the view, it doesn't do Ajax, it doesn't even do routing and don't force a backend or a database like Meteor.

This is the philosophy behind why I went with Knockout years ago - and am now helping maintain and write version 4.

Specific, narrow focus and it's served me well. Sensing the innate liability, I've never felt the allure of the full fledged framework.

I understand where you're coming from. However, Vue isn't an "all-in-one" or "batteries included" library. Vue is just a view layer. It fills the same layer of the stack that React does.

+1, Ember especially. Never encountered a framework with so many foot-guns and poorly documented conventions for avoiding said foot-guns.

Maybe polymer and web components are the way to go, at least that is what I'm trying to use these days.

You can very easily use React + Meteor though.

Reply on news.ycombinator.com