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.
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.)
> 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.
Who knows? Maybe it will prevent them from focusing unduly on use cases that match with what they happen to be doing at the expense of other use cases.
I'm not sure why someone's ability to design an API is more heavily in question just because they have a serious commitment to building that API rather than working full-time to build a company.
There's nothing wrong with building a company and there's nothing wrong with building a tool either.
Crazy idea, but what if you get some enterprising young startups to bet on you early? I think having some big projects, even if you don't want to build one yourself, bet on you as a technology would be the best path to put to rest these concerns. I think there is a need to demonstrate it's effectiveness in a complex piece of software.
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.
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.
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.
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."
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.
This will definitely require more than the two minutes of thought I put into this post, but. . . Large companies like Adobe, Microsoft, etc, often sponsor projects that will serve as good marketing for whatever initiative they're trying to push. Something similar could work once you see projects out there. In the spirit of openness you could setup and initially fund a non profit similar to Apache Software Foundation with a board that decides where the money goes. Doing something like Google's Summer of Code might spur some interesting projects. Or maybe even set aside the cash and do some sort of community voting contest thing. Like: "Build something awesome and win up to X in no-strings-attached cash, voted on by the internet." Put in caveats like it has to become a full time project, etc.
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.
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) . 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.
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.
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.
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).
I suspect the "pure awesome" part is at the IHttpModule and IHttpHandler level, where you can do everything except receive and produce grievously invalid HTTP requests. If you need to do that, IIS is extensible via WCF to host more than HTTP.
If you don't use the legacy static accessors like HttpContext.Current, it's actually quite testable. HttpContext.Current is especially bad because it uses thread local storage, so you have to be very careful about when and where you access it.
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.
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.
"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"
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.
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.
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.
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.
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.
Gah. No. Raising $11M is not success. Raising $11M is putting yourself $11M in debt to investors. They will be successful when enough people are using, and paying for, Meteor that they turn a healthy profit. They are far from success right now. Arguably, further than before they took the money.
As the guy that raised the $11M, I agree completely. It is terrifying and a huge risk.
IMO, the biggest downside to raising a lot of money is that you are no longer accountable to anyone. You can run around saying "We're rockstars! We're winners! Catered dinners! Aeron chairs!" for years, even if you make no progress and produce nothing of value. At least if you stick to the "right" cocktail parties.
untog, I'm counting on people like you to call us out if we get slow, fat, stupid, lazy, and arrogant. Ultimately, we will be measured by what we ship, or better, what other people ship on top of Meteor.
> IMO, the biggest downside to raising a lot of money is that you are no longer accountable to anyone. You can run around saying "We're rockstars! We're winners! Catered dinners! Aeron chairs!" for years, even if you make no progress and produce nothing of value.
Aren't you accountable to those you've raised money from?
Oh, please. Fundraising is a point of success. Equity is not debt. As is more than clear, "healthy profits" are not necessary for an acquirer to find value in a property. It is easier to argue that they are closer to more success.
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.