Hacker News Reader

Comment by maxharris | Hacker News Reader

If you're thinking about using Meteor for something important, now that they're at 0.9.0, don't.

Meteor still doesn't have a UI component API, so making reusable, reactive interface components is basically impossible (or far more difficult than it needs to be). There's a deliberately undocumented and incomplete API that's supposed to help a little bit, but you're basically out of luck if you don't want to write spaghetti code right now.

Instead of shipping an API we can use, they're holding out for the "perfect" one. I wish I could go a year back in time and build my project with Angular instead of Meteor.

View on HN

That's funny, because not having to write "spaghetti code" is one of the reasons I tell people to use Meteor. Perhaps we have different definitions.

For web apps, I tend to define spaghetti code as the huge layers of glue and boilerplate you have to write to get your data out of your database in the server, serialized into some JSON or XML format through your controller in order to send to the client and into an XHR callback hell or confusing promise-driven architecture, all so that you can finally concatenate everything into a string inside some jQuery function where you then have to manage your own state.

None of which even comes up when building with Meteor, since it takes care of all of that for you, leaving you more time to build your app. So as far as I've experienced building apps in Meteor for two years, spaghetti code is a thing of the past. Not to mention that just the fact that the API works this way dramatically simplifies your application architecture just as a side effect of how the templating system, reactivity and javascript-everywhere approach work.

Yes, there are MVC frameworks like Angular and Backbone that help you take care of the client side of that. But they don't handle the server at all, so IMO they still haven't matched Meteor's feature set.

Backbone is not an MVC framework, and it's important to know that. It's one of its greatest strengths as a client-side JavaScript tool. A well structured Backbone app can stand the test of time, and I can't say that for some other options.

Meteor shows promise, but I have to agree that without a mature UI toolkit, you just end up with the same junk we've had for years (not speaking to other components of Meteor).

For what it's worth, have another look at promises. They're not the same as "callback hell" and can be a really elegant way to compose and deal with async. It's actually really nice, when the tool is called for.

Agree with you that Meteor's built-in reactivity is really nice!

I didn't mean to imply I thought promises are the same as callback hell - they are completely different beasts, indeed. But I still greatly prefer the reactive system provided by Blaze and Meteor's overall setup. I've built reasonably complex apps with Meteor that have required no promise chaining, and no callback nesting. They're more readable, easier to maintain, and cause fewer bugs. One of the reasons why I greatly prefer Meteor now, because all of those things mean that I get to do more of what I enjoy: building cool stuff.

I'm not sure why you're claiming Backbone isn't an MVC framework. It was pretty much designed to be MVC or at least MVVM, and checking the Backbone website, it still says it pretty much in the first paragraph: models, collections, and views. That's fine, but I like Meteor because it doesn't need the MVC crutch to provide structure and elegance. Somehow, it gives me more power as a developer without also asking me to write the kind of boilerplate code normally associated with data binding, getter/setters, models, and things like event emitters.

If you still prefer Backbone, that's great! But I just wanted to explain to the OP that for me, Meteor is about getting rid of spaghetti code, not adding to it.

Will Backbone stand the test of time as both data binding and DOM eventing continue to evolve? I'm not resolutely convinced of Backbone's staying power, but I'm open to entertaining other thoughts on the matter.

1 cent for every new System that promise no spaghetti code and i will be rich ;-)

I wouldn't write a commercial, production application with anything less than 1.0. In fact, I wouldn't write a commercial, production application with anything less than a 2.1. ;-)

The cost of supporting these projects early is that you're likely to be rebuilding anyway a year from now, but I think that's implicit in the version number.

In my opinion, the biggest risks of Meteor are this:

1. It hitched its wagon for now to mongo, so you'll be doing the same. If you happen to believe that schemaless isn't all its cracked up to be, that's a real problem in production.

2. You're picking both a client and a server. Sure, you can strip apart DPP or Blaze, but why would you? If you're not wanting to benefit from Meteor's reactivity, you can just use any server+client combo and, say, a websocket connection or something like React.js for UI components.

3. Meteor has a financial incentive to round up as many devs into their own ecosystem (atmosphere?). They want to sell you servers, services, et cetera, like Heroku does. Nothing wrong with that, but it's something to be aware of.

For all the debate about JavaScript frameworks, I have Backbone code I wrote a relatively long time ago and it's still durable and not being refactored. I can't say the same for Ember or Angular code in my experience or observation. Backbone as a library is lightweight enough that I create the framework, following good design principles, that's best for a given application. Your mileage may vary.

It's not to say the people at Meteor aren't a great bunch of people who really love what they're making. Meteor does some interesting things and I think hopes to solve some complex problems. Hope they get there. I'd love to see Meteor mature and become a tool to build bigger things (UI components I agree would be a welcome step).

Not that I implied a lack of data validation was my reason for disliking mongo - just to keep myself honest - there are the collection2 and simple-schema packages that help enforce schema validation on Meteor collections.

https://github.com/aldeed/meteor-collection2

https://github.com/aldeed/meteor-simple-schema

Why does everyone insist on this 1.0 nonsense? Ever looked at the latest Node.js version number?

I have built and integrated some pretty complex components with blaze templates without needing a component api. I am curious what use case you ran into where the template api was not sufficient?

In your comment history I saw that you asked for reactive template variables. I know of two ways to accomplish that, 1) attach a ReactiveDict to a template instance in it's render function, 2) pass it in as a variable to the template inclusion {{>template myDict}}.

Since Meteor automatically scopes by file, you can write your template helpers and event handlers in the same file, and place a reactive data structure at the top of the file that both can access.

You could use reactive-object (my package), as it provides a fairly drop-in reactive object that supports arrays as reactive properties, including all the Array.prototype methods.

It's coming, and the community is already doing a lot of cool things around UI components and with the parts of the UI API that are starting to emerge. For one example check out the UI Harness being built over at Respondly: https://www.youtube.com/watch?v=jscINbvWoDg&list=UU3fBiJrFFM...

I wouldn't quite call it spaghetti code... You can still structure things into models, views, controllers, and view controllers (event handlers that pass data to controllers basically). Having a component API isn't really a deal breaker.

What do you mean by "UI component API"? Couldn't you use Blaze in order to construct the the UI you need or modify existing components to fit the Meteor reactive model?

Reply on news.ycombinator.com