6 ms·

No matter what else happens in the world, the core team will be able to focus entirely on Meteor for several years, without taking on consulting work or trying

No matter what else happens in the world, the core team will be able to focus entirely on Meteor for several years, without taking on consulting work or trying to create some other application on top of Meteor to sell Does that raise any red flags for anybody? Do development frameworks built for their own sake ever really work in the wild? I think of successful ways to build web apps, and the names that spring to mind are rails, django, php, etc. that evolved by developers who were using them to build stuff. In some cases (rails, django especially), they were the side product of a single application. I think of overarchitected nightmares such as Fusebox and some of the magic frameworks that would be Meteor's competition, and they tend to share the quality of having been built as the Ultimate Solution to Everybody's problem (with the conspicuous exception of the developers themselves, who aren't actually dogfooding it for anything). To be clear, I'm impressed by Meteor and I'm looking forward to seeing where it goes. But it makes me a bit uncomfortable to see a declaration like "we're definitely not going to try building anything with it!" tacked onto their funding announcement.

trekkin 14y ago
I'm here with you - $11m for pure long-term development without any hands-on application seems like a clear path to an over-engineered solution.
- MattRogish 14y ago
  Agreed. I worked on an open-source app development framework and found it really difficult to "do the right thing" unless we were actively building "real world" apps with it. Although they have enough money to not do consulting - I strongly suggest they take on strategic apps (even for free!) that push the boundaries of the framework. It'll be a better product for it.
  - njx 14y ago
    100% agreement. When your app behaves like a framework there needs to be examples of applications on top. I had the same dilemma when I was about to release my dashboard framework (https://my.infocaptor.com https://my.infocaptor.com) . I had all the documentation but to truly demonstrate the framework and various different ways, we had to build various little dashboards. some of the dashboards were plain stupid like the "bug olympics" but they were built to demonstrate certain features which we did not have enough sample data to build upon. The question is do you build "real valuable applications" or "not so useful but demo like apps". We built the 2nd category apps in first go and now with our customers we are helping them build the first category of applications.
- astrodust 14y ago
  That plan worked out amazingly well for Diaspora!
wavephorm 14y ago
One thing is for sure, they will be able to build the world's most sophisticated To-Do app without regard to security or real-world application.
JTxt 14y ago
Agreed. I also follow Blender 3d; they regularly make short movies to drive various areas of development. Since they started that, the quality and ease of use went way up, and it's more ready for real studios. I hope Meteor makes some awesome examples/tests at least.
latch 14y ago
I've long thought that the spiritual difference between RoR and ASP.NET is that one is built by application developers, and the other is built by language and framework developers.
- jasonkester 14y ago
  Indeed. Though you'll note that ASP.NET is conspicuously absent from my list of nightmare monstrosities. Not because it's not a nighmare monstrosity. It's the posterchild for nightmare monstrosity frameworks. But it's unique in that if ignore roughly 95% of the "point and click your way to unmaintainable intranet sites" garbage, what's left is pretty much pure awesome. Deep in the center of the hairball is a tight little framework for building websites that has access to a really good, really big library that can do pretty much anything you'd want to do with a computer. So it's both terrible and awesome at the same time, depending on whether you know which bit you're supposed to use. I wouldn't be surprised to find that there was a team at Microsoft somewhere using that small bit to build stuff and guiding the project just enough to make sure none of the good got mangled by the tons and tons of bad.
  - untog 14y ago
    I may be telling you things you are already well aware of, but ASP.NET MVC is a separate framework that removes 99% of the utter crap that came along with ASP.NET WebForms, so there definitely is a team at MS that sympathises. To go even further, Nancy.fx is a third party framework that gets even closer to the metal. I still have enough of an undying love for the C# language that I dream of running Nancy.fx on Mono, on Linux, giving me the best of at least three worlds.
  - lucisferre 14y ago
    I can't agree with that at all. ASP.NET even after you remove all the point-and-click crap is still a mediocre web framework at best and arguably horrible in a number of crucial areas. One thing it is not is "pure awesome". 1. It isn't nearly as extensible as Rack and Rails. I mean not even in the same zip code. 2. It is not a very testable framework to work with. The ASP.NET abstractions are horrible for this, while the .NET MVC ones are better but still suffer due to all of the issues with the testability of the core of ASP.NET. Most of the testability abstractions that modern ASP.NET does have were added purely as afterthoughts, and awkward does not being to describe working with them. 3. ASP.NET regularly violates the "principle of least surprise". One of my favorite examples is where the HttpContext class throws an exception from the `.Request` property getter if you attempt to access it during the application startup (ironically it is actually starting up in response to a request so this is both confusing and inconvenient in addition to being bad API design). .NET MVC is a poor man's Rails and working with it is merely a far more verbose and complicated way to accomplish the same thing. It is far less extensible, painful to test and automate around and has a far weaker OSS ecosystem around it. I could honestly, go on. I worked with ASP.NET for years before moving on to Rails and occasionally node.js (though I'm really not all that big of a fan of callback coding).
funthree 14y ago
Agreed. I came here to post basically the same line. >without ... trying to create some other application on top of Meteor to sell I hope I dont see millions of dollars of time spent on abstraction and magic, or losing sight of a scientific process or an ability to correct fundamental architectural flaws that would challenge or invalidate the need for or the existence of what is now meteor, just because there has been introduced a fiduciary duty. Introspection on the fundamental usefulness and proper use cases in comparison to competition or existing equivalents is an ongoing dialogue that would be unprofessional to dismiss. Meteor is for everything? I really doubt that. Dont think about proper tools for the job, dont think about how to really scale out javascript architecture or solve that problem without subjectivity, dont think simplicity, just think meteor? Marketing like this seems out of place in open source -- especially javascript frameworks -- which in proper form is most functional as a meritocracy. Along this continuum we will see meteor probably fitting right in at oscon, and maybe thats where they want to be, because it seems like its just going to be enterprise software with a hipster twist, donning open source as an applause light. >Meteor was also a stealth participant in the S11 cycle of Y Combinator. Sorry to be more cynical than everyone else in this comment thread, meteor guys, but I had red flags going up about meteor the first time it was posted on HN and I saw testimonials for a javascript framework that wasnt even production ready. This is an open source javascript web framework: https://github.com/meteor/meteor/blob/master/app/server/server.js#L8 https://github.com/meteor/meteor/blob/master/app/server/serv... https://github.com/senchalabs/connect#authors https://github.com/senchalabs/connect#authors
- Jd 14y ago
  The testimonials were a bit weird, esp. since they came from people who presumably weren't using the framework. Once we all realized this was a YC thing, what happened was quite clear. YC and YC partners was throwing their valley knowhow and marketing heft into "selling" a framework in a very early stage -- and very successfully, given the wide interest it has sparked and the $11M they've just raised. I think this is a bit of a wait and see game, since this is experimental on a number of levels. On one hand, YC has started selling certain companies before they are ready on the basis of super-smarts and presumed future output. VC is willing to put in cash and see what happens. Everyone wants a piece of the next "Rails" and to create an ecosystem there, although probably no one is exactly certain what it will take to gel. In short, I'd say that the red flags are justified, but also it is cool to see the potential ecosystem for an open source project go from zero to sixty in a few seconds because of YC and co. From the moment I'd like to give them the benefit of the doubt and hope that the hype is for real. The world could use something better than rails and a slick Javascript MVCish framework would be very nice.
debergalis 14y ago
Good point. We do use Meteor. Our own site has always run on Meteor, and we build other tools and personal projects with it. Dogfood is good -- we now have an experimental version of server side rendering in Meteor because we had the pressure to get www.meteor.com into Google's index. It's not a bad strategy to build the framework alongside a product. But shipping real product is a huge commitment. We spent weeks just getting all the pieces in place for the first Meteor release in April: text, design, docs, a screencast, release engineering, community outreach. For now, we think we can move faster and build a better framework if that's our only product focus, instead of trying to ship two great things at the same time.
- jconley 14y ago
  It would probably be valuable to use some amount of that $11m to fund development of interesting applications/startups that showcase Meteor in the real world. For instance, you notice something interesting a community member is building on their own time, but you don't want to focus on it. In my experience close partnerships can work as well as dogfooding, as long as you trust the source and can make the right decisions based on the feedback.
  - brandall10 14y ago
    I feel that this is implicit in the post, that there will be this outreach/advocacy/support? "Create opportunities for Meteor developers — for example, encourage companies to adopt Meteor, creating jobs. We want to make you famous and get you paid. Support the Meteor community. This includes everything from publishing books and organizing conferences, to being responsive to bug reports and pull requests, to finally making some cool tshirts."
  - geoffschmidt 14y ago
    I think that's a great idea. The ability to do creative things like this is the "silver lining" of having so much money in the bank (which, as I mentioned above, is something I generally consider a risk, or at best a hedge.) I'd love to hear your ideas about how this could work, and when we should start doing it (it's probably way too early?) either here or on meteor-talk.
mcantelon 14y ago
>Do development frameworks built for their own sake ever really work in the wild? AFAIK Node.js, which Meteor is built on, was built for its own sake and has done well in the wild.
- adrianpike 14y ago
  Node's changed pretty drastically from the original vision though: http://four.livejournal.com/943068.html http://four.livejournal.com/943068.html http://four.livejournal.com/963421.html http://four.livejournal.com/963421.html
  - mcantelon 14y ago
    Meteor can do that as well, conceivably, if need be.
mjackson 14y ago
Ditto. Another good example is Cappuccino/Objective-J. One of my favorite things about the whole Cappuccino/Objective-J framework was that 280 North built 280 Slides with it very early on. Going through the paces of developing an actual app with your framework is an essential process to creating something really useful. The fact they've already decided they're not going to actually build a sellable product on top of it anytime soon is worrying, to say the least.
- pbreit 14y ago
  280 Slides seems like the opposite data point for me. It seemed like merely a demo of what you could do and that Cappuccino overall is fairly bloated and searching for real-world problems to solve. And 280 Slides is of course now gone, having never had much viability.
kvnn 14y ago
You are worrying prematurely. "without taking on consulting work or trying to create some other application on top of Meteor to sell" != "Meteor will be built without real-life feedback" debergalis cleared this up below: "We use meteor to build the meteor site". Furthermore, I'll bet you hard cash that they are already working on partnerships to get people using Meteor for real applications. Your post was valid, but everyone jumping on the band wagon has raised MY red flag. I think we're seeing reactions of either: (1) worrying prematurely - or - (2) "I secretly want other people to make bad decisions and fail"
geoffschmidt 14y ago
Hi, I'm the OP (or at least the author of the blog post.) I should have been clearer. Most of the core devs have side projects that they're building on Meteor. I'm building a social contact manager, which I'm using for a community group I'm involved with. Nick built an app to keep a database of his wedding guests. David built a app to keep track of the schedule for his favorite TV shows. Matt has built some games. What we're not doing is trying to turn any of these other projects into businesses. Meteor is the reason we exist, rather than something that we have to continually justify to ourselves as an "engineering investment" as we build our "real" product. You're exactly right, it is poison to try to build any kind of API without having some motivating use cases in front of you. So one of our rules is, we try not to add any feature to the framework without having seen people implement it several times "by hand" in the app. Then we try to find the common bits between those implementations, polish them until they shine, make it accessible to a new JavaScript developer, and finally package it as an optional Smart Package. So far, every feature in Meteor has been built to scratch an itch that we had while building actual apps in Meteor. For example, the reactive templating system was originally built to make the meteor.com homepage easier to build. The new auth/accounts package is something we've all wanted for our weekend projects for months. And the forms/live templating overhaul that David is working on comes partly from the difficulty we had with embedding Twitter buttons in the meteor.com homepage app, and partly from the large amount of boilerplate code that I had to write in my social CRM. Finally, there actually is one fully-scaled commercial app that we'll soon be building on Meteor, and that's the web interface that'll let you manage your deployed Meteor apps and share them with other team members (if you choose to use our "meteor deploy" servers.)
- bonzoesc 14y ago
  > I should have been clearer. Most of the core devs have side projects that they're building on Meteor. I'm building a social contact manager, which I'm using for a community group I'm involved with. Nick built an app to keep a database of his wedding guests. David built a app to keep track of the schedule for his favorite TV shows. Matt has built some games. > What we're not doing is trying to turn any of these other projects into businesses. Meteor is the reason we exist, rather than something that we have to continually justify to ourselves as an "engineering investment" as we build our "real" product. Won't this lead you to make choices that make sense for short-term projects but age poorly as your codebase grows? Many of the choices in Rails versions as early as 1.0 are undoubtedly influenced by the implementation of Basecamp (a non-trivial app) using the framework, and during the last eight years it feels like large projects have only gotten more manageable and maintainable.
dgreensp 14y ago
Among the guys at Meteor, we've built a lot of apps already in the past. For example, I wrote EtherPad. So you could say we're extracting from our extensive collective experience. Do development frameworks built for their own sake ever really work in the wild? It's hard to say what technologies were or weren't "built for their own sake." You can't invent good tools and abstractions without taking the cues from somewhere. That doesn't mean a new kind of hammer has to come out of a particular kitchen renovation, or a new kind of detergent has to come out of a single load of laundry. We're deeply embedded in a community of people who do the same things over and over, and we think we know what the next set of tools should look like. Was SQL extracted from some particular app? How about Heroku, Parse, or jQuery? HTML? In most cases you could probably frame the story either way. I think we're really talking about the "over-engineering" stereotype. Even saying we're working full time on a framework can set off that alarm. Oh no, that's too much engineering! Don't worry, we'll keep it under control.
TheSmoke 14y ago
> Do development frameworks built for their own sake ever really work in the wild? i guess so. Django was built for a CMS and then they open sourced it. Rails was built for Basecamp and then they've extracted it and open sourced it.

trekkin 14y ago

I'm here with you - $11m for pure long-term development without any hands-on application seems like a clear path to an over-engineered solution.

MattRogish 14y ago
Agreed. I worked on an open-source app development framework and found it really difficult to "do the right thing" unless we were actively building "real world" apps with it. Although they have enough money to not do consulting - I strongly suggest they take on strategic apps (even for free!) that push the boundaries of the framework. It'll be a better product for it.
- njx 14y ago
  100% agreement. When your app behaves like a framework there needs to be examples of applications on top. I had the same dilemma when I was about to release my dashboard framework (https://my.infocaptor.com https://my.infocaptor.com) . I had all the documentation but to truly demonstrate the framework and various different ways, we had to build various little dashboards. some of the dashboards were plain stupid like the "bug olympics" but they were built to demonstrate certain features which we did not have enough sample data to build upon. The question is do you build "real valuable applications" or "not so useful but demo like apps". We built the 2nd category apps in first go and now with our customers we are helping them build the first category of applications.
astrodust 14y ago
That plan worked out amazingly well for Diaspora!

wavephorm 14y ago

One thing is for sure, they will be able to build the world's most sophisticated To-Do app without regard to security or real-world application.

JTxt 14y ago

Agreed. I also follow Blender 3d; they regularly make short movies to drive various areas of development. Since they started that, the quality and ease of use went way up, and it's more ready for real studios. I hope Meteor makes some awesome examples/tests at least.

latch 14y ago

I've long thought that the spiritual difference between RoR and ASP.NET is that one is built by application developers, and the other is built by language and framework developers.

jasonkester 14y ago
Indeed. Though you'll note that ASP.NET is conspicuously absent from my list of nightmare monstrosities. Not because it's not a nighmare monstrosity. It's the posterchild for nightmare monstrosity frameworks. But it's unique in that if ignore roughly 95% of the "point and click your way to unmaintainable intranet sites" garbage, what's left is pretty much pure awesome. Deep in the center of the hairball is a tight little framework for building websites that has access to a really good, really big library that can do pretty much anything you'd want to do with a computer. So it's both terrible and awesome at the same time, depending on whether you know which bit you're supposed to use. I wouldn't be surprised to find that there was a team at Microsoft somewhere using that small bit to build stuff and guiding the project just enough to make sure none of the good got mangled by the tons and tons of bad.
- untog 14y ago
  I may be telling you things you are already well aware of, but ASP.NET MVC is a separate framework that removes 99% of the utter crap that came along with ASP.NET WebForms, so there definitely is a team at MS that sympathises. To go even further, Nancy.fx is a third party framework that gets even closer to the metal. I still have enough of an undying love for the C# language that I dream of running Nancy.fx on Mono, on Linux, giving me the best of at least three worlds.
- lucisferre 14y ago
  I can't agree with that at all. ASP.NET even after you remove all the point-and-click crap is still a mediocre web framework at best and arguably horrible in a number of crucial areas. One thing it is not is "pure awesome". 1. It isn't nearly as extensible as Rack and Rails. I mean not even in the same zip code. 2. It is not a very testable framework to work with. The ASP.NET abstractions are horrible for this, while the .NET MVC ones are better but still suffer due to all of the issues with the testability of the core of ASP.NET. Most of the testability abstractions that modern ASP.NET does have were added purely as afterthoughts, and awkward does not being to describe working with them. 3. ASP.NET regularly violates the "principle of least surprise". One of my favorite examples is where the HttpContext class throws an exception from the `.Request` property getter if you attempt to access it during the application startup (ironically it is actually starting up in response to a request so this is both confusing and inconvenient in addition to being bad API design). .NET MVC is a poor man's Rails and working with it is merely a far more verbose and complicated way to accomplish the same thing. It is far less extensible, painful to test and automate around and has a far weaker OSS ecosystem around it. I could honestly, go on. I worked with ASP.NET for years before moving on to Rails and occasionally node.js (though I'm really not all that big of a fan of callback coding).

funthree 14y ago

Agreed. I came here to post basically the same line. >without ... trying to create some other application on top of Meteor to sell I hope I dont see millions of dollars of time spent on abstraction and magic, or losing sight of a scientific process or an ability to correct fundamental architectural flaws that would challenge or invalidate the need for or the existence of what is now meteor, just because there has been introduced a fiduciary duty. Introspection on the fundamental usefulness and proper use cases in comparison to competition or existing equivalents is an ongoing dialogue that would be unprofessional to dismiss. Meteor is for everything? I really doubt that. Dont think about proper tools for the job, dont think about how to really scale out javascript architecture or solve that problem without subjectivity, dont think simplicity, just think meteor? Marketing like this seems out of place in open source -- especially javascript frameworks -- which in proper form is most functional as a meritocracy. Along this continuum we will see meteor probably fitting right in at oscon, and maybe thats where they want to be, because it seems like its just going to be enterprise software with a hipster twist, donning open source as an applause light. >Meteor was also a stealth participant in the S11 cycle of Y Combinator. Sorry to be more cynical than everyone else in this comment thread, meteor guys, but I had red flags going up about meteor the first time it was posted on HN and I saw testimonials for a javascript framework that wasnt even production ready. This is an open source javascript web framework: https://github.com/meteor/meteor/blob/master/app/server/server.js#L8 https://github.com/meteor/meteor/blob/master/app/server/serv... https://github.com/senchalabs/connect#authors https://github.com/senchalabs/connect#authors

Jd 14y ago
The testimonials were a bit weird, esp. since they came from people who presumably weren't using the framework. Once we all realized this was a YC thing, what happened was quite clear. YC and YC partners was throwing their valley knowhow and marketing heft into "selling" a framework in a very early stage -- and very successfully, given the wide interest it has sparked and the $11M they've just raised. I think this is a bit of a wait and see game, since this is experimental on a number of levels. On one hand, YC has started selling certain companies before they are ready on the basis of super-smarts and presumed future output. VC is willing to put in cash and see what happens. Everyone wants a piece of the next "Rails" and to create an ecosystem there, although probably no one is exactly certain what it will take to gel. In short, I'd say that the red flags are justified, but also it is cool to see the potential ecosystem for an open source project go from zero to sixty in a few seconds because of YC and co. From the moment I'd like to give them the benefit of the doubt and hope that the hype is for real. The world could use something better than rails and a slick Javascript MVCish framework would be very nice.

debergalis 14y ago

Good point. We do use Meteor. Our own site has always run on Meteor, and we build other tools and personal projects with it. Dogfood is good -- we now have an experimental version of server side rendering in Meteor because we had the pressure to get www.meteor.com into Google's index. It's not a bad strategy to build the framework alongside a product. But shipping real product is a huge commitment. We spent weeks just getting all the pieces in place for the first Meteor release in April: text, design, docs, a screencast, release engineering, community outreach. For now, we think we can move faster and build a better framework if that's our only product focus, instead of trying to ship two great things at the same time.

jconley 14y ago
It would probably be valuable to use some amount of that $11m to fund development of interesting applications/startups that showcase Meteor in the real world. For instance, you notice something interesting a community member is building on their own time, but you don't want to focus on it. In my experience close partnerships can work as well as dogfooding, as long as you trust the source and can make the right decisions based on the feedback.
- brandall10 14y ago
  I feel that this is implicit in the post, that there will be this outreach/advocacy/support? "Create opportunities for Meteor developers — for example, encourage companies to adopt Meteor, creating jobs. We want to make you famous and get you paid. Support the Meteor community. This includes everything from publishing books and organizing conferences, to being responsive to bug reports and pull requests, to finally making some cool tshirts."
- geoffschmidt 14y ago
  I think that's a great idea. The ability to do creative things like this is the "silver lining" of having so much money in the bank (which, as I mentioned above, is something I generally consider a risk, or at best a hedge.) I'd love to hear your ideas about how this could work, and when we should start doing it (it's probably way too early?) either here or on meteor-talk.

mcantelon 14y ago

>Do development frameworks built for their own sake ever really work in the wild? AFAIK Node.js, which Meteor is built on, was built for its own sake and has done well in the wild.

adrianpike 14y ago
Node's changed pretty drastically from the original vision though: http://four.livejournal.com/943068.html http://four.livejournal.com/943068.html http://four.livejournal.com/963421.html http://four.livejournal.com/963421.html
- mcantelon 14y ago
  Meteor can do that as well, conceivably, if need be.

mjackson 14y ago

Ditto. Another good example is Cappuccino/Objective-J. One of my favorite things about the whole Cappuccino/Objective-J framework was that 280 North built 280 Slides with it very early on. Going through the paces of developing an actual app with your framework is an essential process to creating something really useful. The fact they've already decided they're not going to actually build a sellable product on top of it anytime soon is worrying, to say the least.

pbreit 14y ago
280 Slides seems like the opposite data point for me. It seemed like merely a demo of what you could do and that Cappuccino overall is fairly bloated and searching for real-world problems to solve. And 280 Slides is of course now gone, having never had much viability.

kvnn 14y ago

You are worrying prematurely. "without taking on consulting work or trying to create some other application on top of Meteor to sell" != "Meteor will be built without real-life feedback" debergalis cleared this up below: "We use meteor to build the meteor site". Furthermore, I'll bet you hard cash that they are already working on partnerships to get people using Meteor for real applications. Your post was valid, but everyone jumping on the band wagon has raised MY red flag. I think we're seeing reactions of either: (1) worrying prematurely - or - (2) "I secretly want other people to make bad decisions and fail"

geoffschmidt 14y ago

Hi, I'm the OP (or at least the author of the blog post.) I should have been clearer. Most of the core devs have side projects that they're building on Meteor. I'm building a social contact manager, which I'm using for a community group I'm involved with. Nick built an app to keep a database of his wedding guests. David built a app to keep track of the schedule for his favorite TV shows. Matt has built some games. What we're not doing is trying to turn any of these other projects into businesses. Meteor is the reason we exist, rather than something that we have to continually justify to ourselves as an "engineering investment" as we build our "real" product. You're exactly right, it is poison to try to build any kind of API without having some motivating use cases in front of you. So one of our rules is, we try not to add any feature to the framework without having seen people implement it several times "by hand" in the app. Then we try to find the common bits between those implementations, polish them until they shine, make it accessible to a new JavaScript developer, and finally package it as an optional Smart Package. So far, every feature in Meteor has been built to scratch an itch that we had while building actual apps in Meteor. For example, the reactive templating system was originally built to make the meteor.com homepage easier to build. The new auth/accounts package is something we've all wanted for our weekend projects for months. And the forms/live templating overhaul that David is working on comes partly from the difficulty we had with embedding Twitter buttons in the meteor.com homepage app, and partly from the large amount of boilerplate code that I had to write in my social CRM. Finally, there actually is one fully-scaled commercial app that we'll soon be building on Meteor, and that's the web interface that'll let you manage your deployed Meteor apps and share them with other team members (if you choose to use our "meteor deploy" servers.)

bonzoesc 14y ago
> I should have been clearer. Most of the core devs have side projects that they're building on Meteor. I'm building a social contact manager, which I'm using for a community group I'm involved with. Nick built an app to keep a database of his wedding guests. David built a app to keep track of the schedule for his favorite TV shows. Matt has built some games. > What we're not doing is trying to turn any of these other projects into businesses. Meteor is the reason we exist, rather than something that we have to continually justify to ourselves as an "engineering investment" as we build our "real" product. Won't this lead you to make choices that make sense for short-term projects but age poorly as your codebase grows? Many of the choices in Rails versions as early as 1.0 are undoubtedly influenced by the implementation of Basecamp (a non-trivial app) using the framework, and during the last eight years it feels like large projects have only gotten more manageable and maintainable.

dgreensp 14y ago

Among the guys at Meteor, we've built a lot of apps already in the past. For example, I wrote EtherPad. So you could say we're extracting from our extensive collective experience. Do development frameworks built for their own sake ever really work in the wild? It's hard to say what technologies were or weren't "built for their own sake." You can't invent good tools and abstractions without taking the cues from somewhere. That doesn't mean a new kind of hammer has to come out of a particular kitchen renovation, or a new kind of detergent has to come out of a single load of laundry. We're deeply embedded in a community of people who do the same things over and over, and we think we know what the next set of tools should look like. Was SQL extracted from some particular app? How about Heroku, Parse, or jQuery? HTML? In most cases you could probably frame the story either way. I think we're really talking about the "over-engineering" stereotype. Even saying we're working full time on a framework can set off that alarm. Oh no, that's too much engineering! Don't worry, we'll keep it under control.

TheSmoke 14y ago

> Do development frameworks built for their own sake ever really work in the wild? i guess so. Django was built for a CMS and then they open sourced it. Rails was built for Basecamp and then they've extracted it and open sourced it.