7 ms·

My first impression of this: wow. If Meteor is all it appears to be, this is nothing short of revolutionary. My second reaction: what happens when the magic en

My first impression of this: wow. If Meteor is all it appears to be, this is nothing short of revolutionary. My second reaction: what happens when the magic ends? When I was new to Rails, I really loved how easy it was to get started with scaffolding, a nice DSL for specifying relations, nifty form helpers. However, the first time I veered a little off the golden path and wanted to do something a little more complicated (that was not supported by the form helpers at that time), I ran into a huge wall. I found out that I actually had no idea how Rails worked. The magic had hidden all complexity from me before, and now the magic failed me and I didn't know where to start doing it on my own. Rails has matured a lot since then (it also dropped some of the magic in favor of more explicit behavior) and my understanding of the framework has grown with it. Meteor looks even more magic to me. There is so much stuff happening. What if I plan to do a lot of dynamic updates and I want to defer live-updating because I am doing mass-updates? What if I need a hard division between client/server code? What if I want to share the backend with an iOS app or something? Can I use this to build an API? The documentation does not yet fully answer these questions for me.

danmaz74 15y ago
This was my first concern too. I didn't have time to study the documentation, but I hope it is easy to integrate custom solutions both around and on top of the magic whenever it's necessary.
csomar 15y ago
I can't upvote this enough. When I saw the screencast, I said "Good,we are looking for that". But I want to know how this work, and how I can hack the core. At some point of building my app, I'll need finer degree of control.
- Lambent_Cactus 15y ago
  The code is on GitHub: https://github.com/meteor/meteor https://github.com/meteor/meteor
entropy_ 15y ago
Joel Spolsky coined a term for this type of problem. The "leaky abstraction". See here: http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...
- mattbriggs 15y ago
  It doesn't nessicarily need to be a leaky abstraction, in the case of rails (1) there was just a few miles between the path a beginner took and a pro took, which makes it real hard to stop being a beginner
XLcommerce 15y ago
Such a great question. I spent a lot of time working with ExtJS having been lured in by all those great, straight out of the box components which had their own healthy dose of added magic. Fast forward a year or two and suddenly when I need to do anything that is non standard then reality kicks in. I now need to buy-in to the entire (framework) mindset to progress which slows things down (because it doesn't necessarily match my own way of doing things). Had the same experience with cakephp. All those freebies which eventually caught up with me. Ties in well with the whole libraries vs frameworks debate. I'm now in the libraries camp. I wonder if Meteor packages are decoupled from each other so that I can pick and choose which ones I'd like to use in my project. Turns out there really is no such thing as a free lunch.
- DougBTX 15y ago
  > I now need to buy-in to the entire (framework) mindset to progress which slows things down That's interesting, that idea could be folded into the technical debt metaphor. So, by taking on a library or framework, I get a head start by just using it, but take on the knowledge-debt of not really knowing how it works. And when you get to the edge of what it can do, you either pay off the knowledge debt by learning how it works, or you throw the whole thing out and use a different library.
  - XLcommerce 15y ago
    Yeah, said much better than I could. I don't regret any of the time spent with these frameworks because it really broadens your horizons and makes you think in new ways. Lots of the techniques I've seen now make regular appearances in the versions I roll myself. Other ideas I've completely rejected. Eg. ORMs. A few years ago they seemed like a godsend. In reality they simply shielded me from the basics of SQL and were inflexible black boxes.
    - eric-hu 15y ago
      I have to say that I feel like Rails' ORM does a magnificent job of saving me time. Migrations allow me to write database changes that can be undone more easily. An ORM also seems to lower the amount of configuration it takes to get development databases synced. It's not as much of an issue for an experienced dev, but a designer or new team member would need help. I have had to learn AREL, the relational algebra used by ActiveRecord, in order to do more advanced queries. That's analogous to learning SQL in more detail, but I'd still take that in a heartbeat over writing raw SQL. The ORM automates things like tersely expressing the object associations I've built, leaving room for fewer syntax mistakes.
grannyg00se 15y ago
I'd like to see some additional detail on this particular idea: "In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. " Seems one of Node's primary style advantages (async non-blocking style) has been eschewed.
- mattgreenrocks 15y ago
  At the end of the presentation, I noticed they depend on a fiber library.
- jeromeparadis 15y ago
  I wonder what's the performance hit of having a thread per request. I liked everything I say, but yes, having a single threaded node removes a lot of overhead.
  - fooooobar 15y ago
    Can you cite any non-trivial benchmark of this?
  - ajryan 15y ago
    In ASP.NET, a thread pool is maintained to offset the cost of spinning up a new one. There is some default throttling that controls how quickly new pooled threads will be created, but this can be tuned if you expect sudden bursts of traffic. Not sure how Meteor does it.
- jmarinez 15y ago
  Fibers take care of the "callback pyramid of doom" and makes it easier to write thick logic layers. However, it still would have the fairness and starvation issues that Node has with callbacks. It's still single-threaded and non-preemptive like "stock" node. I wonder how dependent Meteor is on Node? In other words, why Node? Is it for Node module compatibility? If it isn't, I'd love to see Meteor running on something else. I bet this thing would really fly on a lua backend with coroutines. Luvit.io?
mmobile 15y ago
Like the reference to Rails—so easy and at the same time so inaccessible. In the earlier days without powerful frameworks I was really developing: figuring out which pattern/algorithm did the best job. Nowadays when working with frameworks I feel dumber and dumber—before thinking myself I just google API calls and put them together. I am not trying anymore because I don't know where to start and everything is already solved on Github. This magic feels sometimes so meta and boring because I am more into consuming specs, tutorials, screencasts just gluing things together instead of real programming. Just diving into JS and Node.JS to get this "go-kart" feeling back. But I guess the more magic involved the faster the development and Meteor admittedly looks revolutionary.
- ionforce 15y ago
  Define "real programming".
- spiffytech 15y ago
  That's actually the sort of programming I like best! I don't want to care which sort algorithm is most appropriate for my dataset, I just want to call sort() and move on. I love gluing things together that do the nitty-gritty stuff for me because it lets me focus on the big picture of making things happen, which is what I love about programming.
- zedadex 15y ago
  I know the feeling you're talking about. It's the difference between writing your own logic and simply learning what functions exist that someone created to handle the task you've been given.
- 10098 15y ago
  It's like the industrial revolution. Long ago, things (like furniture) used to be made by craftsmen. They had to choose the materials, they had to get a picture of what the final product should look like. They used to work by hand, using only simple tools. It was hard. To become a skilled craftsman you had to be an apprentice for several years and learn a lot from your master. Then came factories. Factories were super-effective, they produced a lot of things fast, and cheap too, and the level of skill required from a factory worker was in no way comparable to the skill of a proper craftsman. I notice the same tendency in software development today - we, the software developers, are more similar to factory workers mindlessly sticking together parts than "ninjas" or "rockstars". Of course, the process of software development today is not entirely like a factory, but I sense it's moving towards there. And if it is, programmers will become something cheap and fungible. Imagine hiring illegal immigrants to write an iPhone app :)
clintjhill 15y ago
Another part about this kind of magic IMO is that it requires you to start from the ground up within this system. Otherwise the magic is either not doable or very hard. I know it's a tired argument but it's a reality - enterprise will have a hard time reaching for this kind of thing because it's so full-stack. Not easily separated without breaking all the magic. Maybe I've missed something about it, but it appears this way.
cristiantincu 15y ago
“Any sufficiently advanced technology is indistinguishable from magic.” —Arthur C. Clarke. For an user of a product/service, this is bliss. For a hacker, it might get tricky. Now, considering the fact that this is all open source, the huge wall you’re talking about is just a matter of perception. You’re free to debug and go with it as low level as you need.
- micheljansen 15y ago
  Easier said than done. The code of Rails was also publicly available, but getting from a hello world app to diving into a hard core codebase such as that of Rails is a huge step. Understanding framework code is quite different from understanding app code as well.
  - cristiantincu 15y ago
    I agree. I didn’t say it would be easy, though. ☺ In fact, understanding “magic” is bloody difficult. It it weren’t so, then it wouldn’t be “magic”. It’s also worth observing that Meteor is not presented as a “framework”. The comparison with Rails was introduced here, on HN. They say it’s “a set of new technologies”. I guess this implies loose coupling, which is a healthy paradigm when applied to components/modules/objects of a development ecosystem. If only Meteor were nothing more than a proof of concept, it would still be mind-blowing.
nosequel 15y ago
"this is nothing short of revolutionary." Oh FFS, this is not revolutionary. It is an attempt to wrap things in a friendlier package, while at the same time making something horribly insecure as a default install. Ruby on Rails did that a long time ago. Better examples of revolutionary: Manned Flight: http://en.wikipedia.org/wiki/Wright_Flyer http://en.wikipedia.org/wiki/Wright_Flyer http://en.wikipedia.org/wiki/Apollo_11 http://en.wikipedia.org/wiki/Apollo_11 In computers: http://en.wikipedia.org/wiki/Computer#First_general-purpose_computers http://en.wikipedia.org/wiki/Computer#First_general-purpose_... Or even in programming: http://en.wikipedia.org/wiki/C_(programming_language) http://en.wikipedia.org/wiki/C_(programming_language) Try not to throw words like "revolutionary" around.
- micheljansen 15y ago
  I get your point, but just because you can name examples of other technological advances that are more revolutionary, does not mean that this (in its own small world) cannot be described using that term. Revolutionary (according to the Oxford English Dictionary) simply means "involving or causing a complete or dramatic change". A technology that dissolves the boundaries between client-side and server side development is a pretty big thing in web development and it may very well cause a dramatic change in how we go about cranking out web apps.
  - jmurley 15y ago
    I guess the problem is just with calling it revolutionary now, before we wait and see if it actually does cause any drastic change. There have been lots of frameworks that seem promising, only to learn partway in that they are still missing some really key functionality. It's unfortunate to use revolutionary to describe everything that could, someday cause a change.
  - raphinou 15y ago
    http://www.webtoolkit.eu http://www.webtoolkit.eu dissolves boundaries between client and server, and has been available for years. You shoult take a look.
herdrick 15y ago
API question answered here: http://news.ycombinator.com/item?id=3826814 http://news.ycombinator.com/item?id=3826814

danmaz74 15y ago

This was my first concern too. I didn't have time to study the documentation, but I hope it is easy to integrate custom solutions both around and on top of the magic whenever it's necessary.

csomar 15y ago

I can't upvote this enough. When I saw the screencast, I said "Good,we are looking for that". But I want to know how this work, and how I can hack the core. At some point of building my app, I'll need finer degree of control.

Lambent_Cactus 15y ago
The code is on GitHub: https://github.com/meteor/meteor https://github.com/meteor/meteor

entropy_ 15y ago

Joel Spolsky coined a term for this type of problem. The "leaky abstraction". See here: http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...

mattbriggs 15y ago
It doesn't nessicarily need to be a leaky abstraction, in the case of rails (1) there was just a few miles between the path a beginner took and a pro took, which makes it real hard to stop being a beginner

XLcommerce 15y ago

Such a great question. I spent a lot of time working with ExtJS having been lured in by all those great, straight out of the box components which had their own healthy dose of added magic. Fast forward a year or two and suddenly when I need to do anything that is non standard then reality kicks in. I now need to buy-in to the entire (framework) mindset to progress which slows things down (because it doesn't necessarily match my own way of doing things). Had the same experience with cakephp. All those freebies which eventually caught up with me. Ties in well with the whole libraries vs frameworks debate. I'm now in the libraries camp. I wonder if Meteor packages are decoupled from each other so that I can pick and choose which ones I'd like to use in my project. Turns out there really is no such thing as a free lunch.

DougBTX 15y ago
> I now need to buy-in to the entire (framework) mindset to progress which slows things down That's interesting, that idea could be folded into the technical debt metaphor. So, by taking on a library or framework, I get a head start by just using it, but take on the knowledge-debt of not really knowing how it works. And when you get to the edge of what it can do, you either pay off the knowledge debt by learning how it works, or you throw the whole thing out and use a different library.
- XLcommerce 15y ago
  Yeah, said much better than I could. I don't regret any of the time spent with these frameworks because it really broadens your horizons and makes you think in new ways. Lots of the techniques I've seen now make regular appearances in the versions I roll myself. Other ideas I've completely rejected. Eg. ORMs. A few years ago they seemed like a godsend. In reality they simply shielded me from the basics of SQL and were inflexible black boxes.
  - eric-hu 15y ago
    I have to say that I feel like Rails' ORM does a magnificent job of saving me time. Migrations allow me to write database changes that can be undone more easily. An ORM also seems to lower the amount of configuration it takes to get development databases synced. It's not as much of an issue for an experienced dev, but a designer or new team member would need help. I have had to learn AREL, the relational algebra used by ActiveRecord, in order to do more advanced queries. That's analogous to learning SQL in more detail, but I'd still take that in a heartbeat over writing raw SQL. The ORM automates things like tersely expressing the object associations I've built, leaving room for fewer syntax mistakes.

grannyg00se 15y ago

I'd like to see some additional detail on this particular idea: "In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. " Seems one of Node's primary style advantages (async non-blocking style) has been eschewed.

mattgreenrocks 15y ago
At the end of the presentation, I noticed they depend on a fiber library.
jeromeparadis 15y ago
I wonder what's the performance hit of having a thread per request. I liked everything I say, but yes, having a single threaded node removes a lot of overhead.
- fooooobar 15y ago
  Can you cite any non-trivial benchmark of this?
- ajryan 15y ago
  In ASP.NET, a thread pool is maintained to offset the cost of spinning up a new one. There is some default throttling that controls how quickly new pooled threads will be created, but this can be tuned if you expect sudden bursts of traffic. Not sure how Meteor does it.
jmarinez 15y ago
Fibers take care of the "callback pyramid of doom" and makes it easier to write thick logic layers. However, it still would have the fairness and starvation issues that Node has with callbacks. It's still single-threaded and non-preemptive like "stock" node. I wonder how dependent Meteor is on Node? In other words, why Node? Is it for Node module compatibility? If it isn't, I'd love to see Meteor running on something else. I bet this thing would really fly on a lua backend with coroutines. Luvit.io?

mmobile 15y ago

Like the reference to Rails—so easy and at the same time so inaccessible. In the earlier days without powerful frameworks I was really developing: figuring out which pattern/algorithm did the best job. Nowadays when working with frameworks I feel dumber and dumber—before thinking myself I just google API calls and put them together. I am not trying anymore because I don't know where to start and everything is already solved on Github. This magic feels sometimes so meta and boring because I am more into consuming specs, tutorials, screencasts just gluing things together instead of real programming. Just diving into JS and Node.JS to get this "go-kart" feeling back. But I guess the more magic involved the faster the development and Meteor admittedly looks revolutionary.

ionforce 15y ago
Define "real programming".
spiffytech 15y ago
That's actually the sort of programming I like best! I don't want to care which sort algorithm is most appropriate for my dataset, I just want to call sort() and move on. I love gluing things together that do the nitty-gritty stuff for me because it lets me focus on the big picture of making things happen, which is what I love about programming.
zedadex 15y ago
I know the feeling you're talking about. It's the difference between writing your own logic and simply learning what functions exist that someone created to handle the task you've been given.
10098 15y ago
It's like the industrial revolution. Long ago, things (like furniture) used to be made by craftsmen. They had to choose the materials, they had to get a picture of what the final product should look like. They used to work by hand, using only simple tools. It was hard. To become a skilled craftsman you had to be an apprentice for several years and learn a lot from your master. Then came factories. Factories were super-effective, they produced a lot of things fast, and cheap too, and the level of skill required from a factory worker was in no way comparable to the skill of a proper craftsman. I notice the same tendency in software development today - we, the software developers, are more similar to factory workers mindlessly sticking together parts than "ninjas" or "rockstars". Of course, the process of software development today is not entirely like a factory, but I sense it's moving towards there. And if it is, programmers will become something cheap and fungible. Imagine hiring illegal immigrants to write an iPhone app :)

clintjhill 15y ago

Another part about this kind of magic IMO is that it requires you to start from the ground up within this system. Otherwise the magic is either not doable or very hard. I know it's a tired argument but it's a reality - enterprise will have a hard time reaching for this kind of thing because it's so full-stack. Not easily separated without breaking all the magic. Maybe I've missed something about it, but it appears this way.

cristiantincu 15y ago

“Any sufficiently advanced technology is indistinguishable from magic.” —Arthur C. Clarke. For an user of a product/service, this is bliss. For a hacker, it might get tricky. Now, considering the fact that this is all open source, the huge wall you’re talking about is just a matter of perception. You’re free to debug and go with it as low level as you need.

micheljansen 15y ago
Easier said than done. The code of Rails was also publicly available, but getting from a hello world app to diving into a hard core codebase such as that of Rails is a huge step. Understanding framework code is quite different from understanding app code as well.
- cristiantincu 15y ago
  I agree. I didn’t say it would be easy, though. ☺ In fact, understanding “magic” is bloody difficult. It it weren’t so, then it wouldn’t be “magic”. It’s also worth observing that Meteor is not presented as a “framework”. The comparison with Rails was introduced here, on HN. They say it’s “a set of new technologies”. I guess this implies loose coupling, which is a healthy paradigm when applied to components/modules/objects of a development ecosystem. If only Meteor were nothing more than a proof of concept, it would still be mind-blowing.

nosequel 15y ago

"this is nothing short of revolutionary." Oh FFS, this is not revolutionary. It is an attempt to wrap things in a friendlier package, while at the same time making something horribly insecure as a default install. Ruby on Rails did that a long time ago. Better examples of revolutionary: Manned Flight: http://en.wikipedia.org/wiki/Wright_Flyer http://en.wikipedia.org/wiki/Wright_Flyer http://en.wikipedia.org/wiki/Apollo_11 http://en.wikipedia.org/wiki/Apollo_11 In computers: http://en.wikipedia.org/wiki/Computer#First_general-purpose_computers http://en.wikipedia.org/wiki/Computer#First_general-purpose_... Or even in programming: http://en.wikipedia.org/wiki/C_(programming_language) http://en.wikipedia.org/wiki/C_(programming_language) Try not to throw words like "revolutionary" around.

micheljansen 15y ago
I get your point, but just because you can name examples of other technological advances that are more revolutionary, does not mean that this (in its own small world) cannot be described using that term. Revolutionary (according to the Oxford English Dictionary) simply means "involving or causing a complete or dramatic change". A technology that dissolves the boundaries between client-side and server side development is a pretty big thing in web development and it may very well cause a dramatic change in how we go about cranking out web apps.
- jmurley 15y ago
  I guess the problem is just with calling it revolutionary now, before we wait and see if it actually does cause any drastic change. There have been lots of frameworks that seem promising, only to learn partway in that they are still missing some really key functionality. It's unfortunate to use revolutionary to describe everything that could, someday cause a change.
- raphinou 15y ago
  http://www.webtoolkit.eu http://www.webtoolkit.eu dissolves boundaries between client and server, and has been available for years. You shoult take a look.

herdrick 15y ago

API question answered here: http://news.ycombinator.com/item?id=3826814 http://news.ycombinator.com/item?id=3826814