Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

meteor.com

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#31

Post by primigenus »

maxharris wrote: post #16

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 spagh…

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.

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#33

Post by mrcwinn »

primigenus wrote: post #31
maxharris wrote: post #16

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 spagh…

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…

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!

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#34

Post by primigenus »

mrcwinn wrote: post #33
primigenus wrote: post #31

Earlier quoted context omitted.

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…

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…

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.

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#35

Post by dsyko »

maxharris wrote: post #16

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 spagh…

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...

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#36

Post by kristiandupont »

Having worked with Meteor for 8 months by now, my love affair with it is slowly fading.

I guess I've realized that it's too far on the left on the [framework...library] scale for my liking. It's very "don't call us, we'll call you". Which is awesome when you start because you just sort of put stuff out there, functions, collections etc., and Meteor magically picks it up and does stuff with it. Yes, you can still debug everything and it's all open source so nothing is black boxed, but it's still really annoying when the magic doesn't work or worse, when it works but just not very well. As with one of my apps at the moment, that is suddenly slow. Everything works so there is no error message that I can use as a break point. But it just takes a long time for my update function to be called for whatever reason, and debugging that takes me far into territory that I don't know about and frankly don't care to know about.

Libraries, on the other hand, require you to say more specifically what you want to happen, but then you can either see that it happens or not. And debug that one particular function if it doesn't, or if it's slow.

I have tremendous respect for the work that they are putting in; iteration is really fast and problems are being solved quickly so there is no doubt in my mind that Meteor will become one of the major platforms of the web like Rails did, but it's going to be a while before I will be using it for new projects.

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#37

Post by evanscottgray »

vqc wrote: post #15

As a developer and maker, one of the most important things is to ship. And as someone who is not a self-professed [insert programming language] ninja or a full-stack this or that, I can safely say that Meteor has made it much easier for me to iterate and ship. I expect that as I grow, Meteor will continue to grow as well. Excited to see Meteor get closer to 1.0.

Definitely agree with you on this one, Meteor has made code easier to deploy. Haven't used it in a while but was able to get my project off the ground in less than 20 minutes. Have recommended it to non 'full stack' friends and they have had great success too. Hopefully this project continues to improve on the road to 1.0!

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#38

Post by bellerocky »

flippyhead wrote: post #14

I cannot recommend Meteor enough for a large class of web applications. I've written 3 apps now using it and find it solves a good many of the problems inherent in more "typical" JS app app stack like rails + backbone.

If you're still using Backbone, then yes, there are better things out there, Meteor being one of them. Others include React, Angular and anything else in widespread use that came out less than half a decade ago.

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#39

Post by dhaivatpandya »

maxharris wrote: post #16

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 spagh…

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?

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#40

Post by denom »

pinouchon wrote: post #9
dfabulich wrote: post #5

What is Isobuild? The blog post doesn't actually say, and Googling [meteor isobuild] just turns up the blog post. (Is Isobuild the tool that implements "proper single loading?")

I too was disappointed that the blog post doesn't go into any detail about unibuild. One of the best and only explanations of isobuild is in this talk by Geoff Schmidt, one of the founders of meteor: http://youtu.be/EZUfQ1zA_NM?t=11m33s [iso]build Like 'make' or 'scons' but for distributed systems. One source tree One package system Multiple languages Multiple targets Multiple architectures

I think that this notion of _generality_ that meteor embraces is essentially the struggle for platform relevance. I take isobuild to mean iso-platform, one platform to rule them all. Take the discussion in the video about DDP. It's like "get on board people, we've figured it out!"

There is a tension between generalities and specifics, between abstraction and things that are concrete. I don't doubt that having a solution that satisfies everyones hopes, dreams and desires would be awesome, but I feel tension when I work on meteor apps. It feels super easy to code up demos (generalities) and then once you get into the business of building out complexity you bang into trouble. It's almost as if the underlying platforms percolate up and clamor to be heard, if you stray from that meteor happy-path.

Post reply on HN