Meteor Raises $20M

http://techcrunch.com/2015/05/19/meteor-raises-20m-to-build-the-one-javascript-stack-to-rule-them-all

by brendannee • 11 years ago

256 155 11 years ago

rywalker2• 11 years ago

Congratz to a very smart team. Love how Meteor seeks to include other good Javascript frameworks into the platform (like React, Angular), rather than trying to force an artificial "one true way" — looking forward to seeing Galaxy.

ep103• 11 years ago

I just wish it wasn't so tightly integrated into everything. I'd love to use Meteor as a library, but I'm always afraid of choosing something that I can't replace later.

Either way, best of luck to them!

adyus• 11 years ago

You could always use the DDP library [1] ("REST for websockets") for realtime transfer. It's separate from the "core" Meteor package (a collection of packages, really).

There's also a list of libraries for other languages that communicate with Meteor via DDP. [2]

[1] https://www.meteor.com/ddp [2] http://meteorpedia.com/read/DDP_Clients

egeozcan• 11 years ago

I think the primary focus on further development in Meteor should be supporting additional databases officially, and after that, supporting operational transformation and conflict resolution strategies come to mind. In my opinion, they are the biggest hurdles towards creating reliable real-time applications.

Official React or Angular support isn't a game-changer. They can already be integrated easily with the reactive data providers.

trcollinson3• 11 years ago

I do believe that the Meteor team is working on those database strategies as well as scalability and deployability on top of their push for mobile. Taking a look at who they are hiring (and their job descriptions) is very telling. It should be exciting to see what they come up with!

kansface• 11 years ago

How often do you need OT in practice?

dorian-graph2• 11 years ago

Depends on what you're doing. I'm needing it for my thesis -> app and will probably use ShareJS for now.

smanuel3• 11 years ago

That's cool. Does Meteor actually make, sorry for using such a dirty word, money from something?

adamnemecek• 11 years ago

Hosting.

smanuel3• 11 years ago

I couldn't find any pricing information on their website and that's why I asked.

I've heard people using Meteor on Heroku, DO, etc. but I've always wondered why someone would choose Meteor's hosting rather than host Meteor on Heroku (for example) and use a ton of other available plugins.

rezistik• 11 years ago

Some investments are multipliers not profit centers.

If you invest in 9 companies that use Meteor then investing in Meteor means you've invested in those 9 companies. It's an investment in infrastructure.

untog• 11 years ago

If you invest in 9 companies that use Meteor then investing in Meteor means you've invested in those 9 companies.

Until they stop using Meteor.

morgante• 11 years ago

If you invest in 9 companies that use Meteor then investing in Meteor means you've invested in those 9 companies. It's an investment in infrastructure.

Except that I don't think you could find a single a16z, Matrix, or Trinity startup actually using Meteor in production.

Meteor is great for toys and prototypes. But as soon as you start wanting to build an actual organization and team, it's the exact opposite of what you want.

_random_• 11 years ago

Is that still a requirement for start-ups? Now, if they are not going to spend at least half the money on a new fancy office - that would be a major concern for investors.

auvi• 11 years ago

Can anybody tell me what is the business model of Meteor? If they are getting investments, the investors has some idea of a ROI and what that could be?

Cshelton• 11 years ago

My best guess...20m is a small amount to invest in your tools. It's a development budget so other companies can utilize the tool for greater leverage. (What they believe to be faster development time with quick iterations and quick MVPs)

rglover4• 11 years ago

They're working on a paid hosting platform called Galaxy that will be designed for quick, easy deployment of Meteor apps. If you work with the framework now, you can deploy to an early version of Galaxy using the command `meteor deploy` (yes, that's it) from your project directory. The goal is to keep that level of simplicity, but offer a platform that's production-grade.

dguaraglia• 11 years ago

I wouldn't be surprised if someone saw Google's acquisition of Firebase as a sign that they can invest in similar technologies and hope that Apple, Facebook or Yahoo will buy them in response.

It's a terrible model, but hey... Clinkle.

richenglish• 11 years ago

What happens to Meteor if Galaxy fails as a commercial endeavour?

DeBraid• 11 years ago

https://github.com/meteor/meteor is open source, so the community will be tasked with maintenance in the case of MDG running out of money.

gooseus8• 11 years ago

When Meteor is no longer commercially viable and runs out of venture capital brewed hype-juice everyone will jump to the Next Big Thing and companies that listened to their Meteor evangelist will have to furiously find someone to port from Meteor to ANYTHING so they can continue to build features and support new services.

Bless me with your downvotes Meteor zealots! I'll still be here when Meteor is has gone the way of Flash and ColdFusion.

sergiotapia6• 11 years ago

I looked into Meteor and it's amazing how everything clicks together. It's just such a drastic change in complexity and feels like a breath of fresh air.

The one thing that made me drop it as the choice for a primary stack was the fact that it's tied so heavily into MongoDB. Meteor has a mongodb 'server' replicated client side, that's how they can actually make Meteor so god damn snappy, it's latancy compensation.

If they were to integrate something like Postgresql into Meteor, I would easily switch over from Rails and it would become my de-facto web stack.

I'll just keep building Rails APIs with EmberJS clients until then, I do hope it's soon though. I loved working with Meteor.

rglover4• 11 years ago

Folks are working on it: https://github.com/numtel/meteor-pg. Also there are plans for core support down the road.

sergiotapia6• 11 years ago

Oh I know, the guys are very open about the roadmap, they have a Trello board. I'm counting the days where I can finally go all in with Meteor. Everyone I know IRL is excited for Meteor but Mongo is what kept everyone sort of away.

fiatmoney• 11 years ago

Yes, Mongo dependency is a dealbreaker for many people who would like to be using it.

joeriel• 11 years ago

SQL support is the biggest ask on their Trello board.

https://trello.com/b/hjBDflxp/meteor-roadmap

There are some good packages on Atmosphere for PostgreSQL, but I think that it needs to be officially supported/integrated for many people to be comfortable with it.

wishinghand• 11 years ago

Postgresql would be great, though if they wanted to keep the document style database of Mongo, maybe they could use something like RethinkDB and use its javascript driver?

juliangregorian2• 11 years ago

I'm apprehensive of the security model. Everything is highly ease-of-use optimized, to the point that you can query Mongo via the browser console.

My preferred "easy/simple" model of app design is Firebase (backend and JS lib for pure web clients), who have security figured out.

sergiotapia6• 11 years ago

What you're saying is only true on a barebones default Meteor app. Please don't comment on a tool if you've never used it for anything other than a hello world, you're doing a very sophisticated tool a huge disservice.

You remove the autopublish package and you can no longer query records from the client.

imslavko4• 11 years ago

Meteor's security model allows app developer to validate any operation or RPC going through, based on the arguments or userId (by writing JS code). Also, the published set is controlled by publications, allowing to publish only filtered out data with specific fields.

Unlike Firebase, Meteor actually allows you to send "first top 20 guest posts from November" as an example. The filtering can happen on the server, before sending the data and the data model usually fits into a sets of documents in set of collections. In Firebase, everything is part of a big subtree that is not filterable (the last time I checked).

Firebase is a good choice for keeping your real-time data. But knowing its limitations is as important as knowing its strengths.

jonlachlan• 11 years ago

"Everything is ease-of-use optimized, to the point that you can query Mongo via the browser console."

meteor remove autopublish

meteor remove insecure

The Mongo-accessible frontent is genius. This makes your prototyping much faster, and you can totally skip the "model" layer of your frontend. It matches your backend automatically. No further configuration needed. No REST endpoints, no callbacks. And yes, it's secure.

Meteor's security model is very well-designed. The list of things left for the developer to do, security-wise, is very short.

It's still important to learn your tools and understand how security works.

http://docs.meteor.com/

http://security-resources.meteor.com/

https://github.com/themeteorchef/security-essentials

https://www.youtube.com/watch?v=6_3pomxyp8M

javajosh• 11 years ago

My take on this is that Meteor (and mongo) is perfectly sized platform for individuals and SMBs. If you make a consumer thing meteor will work too as an MVP, but you'd almost certainly rewrite the backend to use more bespoke code (e.g. in Java REST SOA over Postgres etc.)

KurtMueller3• 11 years ago

I've heard the sales pitch for ember and ember-cli and I've seriously begun developing with Ember for the past 2 weeks. So far, I really like the tooling around Ember but am not a huge fan of the actual framework itself.

I mean, you have routers, routes, controllers, views, templates, and components - how many concepts do you need to display a ui?

Maybe it's just that I can't see the forest through the trees. Perhaps you could help me gain this perspective?

andreisoare• 11 years ago

You have just one router, and that's only a config file that maps URLs to routes.

They're dropping controllers and views in a month, with Ember 2.0. They're being replaced by components.

So really you will only work with routes and components - which should make things much easier to understand.

ahachete• 11 years ago

In ToroDB (https://github.com/torodb/torodb) we are currently working on implementing MongoDB's oplog server-side. ToroDB would work seamlessly with Meteor, meaning that at the end of the day your data sits on a PostgreSQL database. Watch out our next coming release! :)

methehack• 11 years ago

Wow ToroDB looks really cool! Good idea!

keithwhor• 11 years ago

Well, you can start using JS for your API server, at least. Nodal [1], a full-featured API server and framework for iojs was just released yesterday with full PostgreSQL integration. (Migration and schema support, to boot.) :)

I'm not a huge fan of isomorphic JavaScript. While it seems great for prototyping, I have doubts on its stability, security, and ability to scale. It seems to be a knee-jerk reaction to just having the technology to write web-client and web-server code in the same language and the emergence of SPAs.

The thing is, we've had working client-server application architecture (which is what an SPA is) for decades. Every multiplayer game you've ever played. Chat programs. Etc. Nobody would risk the headache of tightly-coupling your data layer, presentation layer, and business layer just to save a few lines of code. We separate our concerns in our code itself with MVC frameworks, why are isomorphic frameworks trying to tightly-couple our actual application layers? It's a little bit contradictory to me.

While Meteor seems like a great tool for a couple of newbie developers to rapidly prototype an idea, I'm still not convinced it has the potential to grow into a reasonable architecture.

[1] https://github.com/keithwhor/nodal

murbard25• 11 years ago

I'm actually looking into meteor at the moment, and the financial backing is a big plus, as it gives me some guarantee that the project will keep being maintained for the foreseeable future.

It is indeed a breeze to prototype applications with it, but I am a little bit concerned about the costs of getting an actual production ready site with it.

For intance, when is it ever OK to let your client write directly in the database, even for their own data? If you're going to pass their calls through a deny and allow call, why not just expose RPCs to the client that will handle any writing?

It seems that a lot of the light versality you have at prototyping time is lost whenever you have to get it production ready. There is definitely some value in light prototypes, but it looks like a real pain to go from prototype to production.

Likewise, I'm confused about how to get around the limitations of mongodb. Say you run a store with a finite inventory, how do you handle concurrent purchases? How about a website to enroll into classes? How about a webforum which can have exactly 5 administrators?

sergiotapia6• 11 years ago

Do yourself a favor and set aside a weekend to go through this book: https://www.discovermeteor.com/

All of your questions are answered there.

afandian2• 11 years ago

As an onlooker that's discouraging. Can you give one-line answers to the points above?

murbard25• 11 years ago

It's not cheap and I can't even find a table of content for it. I've also read excerpts that dealt with autopublish etc, and they didn't really address the point I'm making.

Is there a benefit to using meteor beyond the fast prototyping? I'm not saying that's not potentially a huge benefit, but once you're done with your prototype, I still feel like you have to rewrite the whole thing.

primigenus• 11 years ago

For intance, when is it ever OK to let your client write directly in the database, even for their own data? If you're going to pass their calls through a deny and allow call, why not just expose RPCs to the client that will handle any writing?

If you have a client-side mirror of your server-side database whose changes are monitored by the templating engine, you can execute what Meteor calls "latency compensation", where changes users make are instantly reflected in the UI and synced to the server in the background. This is a central feature of Meteor. More here: https://www.meteor.com/full-stack-db-drivers and in this Youtube video: https://www.youtube.com/watch?v=tqLbodVH3dw

It seems that a lot of the light versality you have at prototyping time is lost whenever you have to get it production ready. There is definitely some value in light prototypes, but it looks like a real pain to go from prototype to production.

It's actually very easy to go from prototype to production; you just remove some convenience packages (autopublish and insecure), set up your security rules, do some basic performance tuning (eg. don't publish entire documents if you only need 3 fields, which is a standard practice for any app) and that's about it. Of course the definition of "production" varies per project, but after shipping over 20 Meteor apps since 2012 these are the most common things I tend to do.

Likewise, I'm confused about how to get around the limitations of mongodb. Say you run a store with a finite inventory, how do you handle concurrent purchases? How about a website to enroll into classes? How about a webforum which can have exactly 5 administrators?

You can express most of these in code. Yes, in relational databases you can express constraints in the database. But then you're having a NoSQL vs SQL debate, which is sort of out of scope of this discussion.

murbard25• 11 years ago

Sure you remove the autopublish package, but then your app stops working. You need to explicitely publish what you want published, you need to explicitely check and validate every input from the client... and that's fine, but then what exactly have you gained from using meteor over, say, socket.io or autobahn? Fast prototyping, yes, you've definitely gained that, but have you gained anything else? I'm genuinely asking, not making a rhetorical point.

Since meteor integrates very tightly with mongodb, a nosql database, I don't see how the limitations of nosql are out of the scope of the discussion? I also don't know what you mean by "you express most of these in code". The problem isn't writing a piece of code that expresses that constraint... the problem is doing so without introducing a race condition!

djmashko24• 11 years ago

Here's step 10 of the tutorial, which demonstrates how you can write custom RPCs to handle writing data in Meteor: https://www.meteor.com/try/10

You don't have to use the client-side insert/update/remove syntax if you don't want to. Unless you add an 'allow' call to let some of them through, they will all be automatically rejected by the server.

(I work at Meteor)

murbard25• 11 years ago

Thank you, I know that you can do that. My concern is more of a soft question: in practice, in production, isn't that what you always end up doing anyway? And if that's the case, how much of meteor's coolness is lost in the process? If I'm going to be writing rpcs for all writes, why not just use some websocket library?

rglover4• 11 years ago

For intance, when is it ever OK to let your client write directly in the database, even for their own data? If you're going to pass their calls through a deny and allow call, why not just expose RPCs to the client that will handle any writing?

Good question. A pattern I like to use for this in Meteor is to rely solely on their Method calls which allow you to restrict any database ops to the server side. The trick is that you lock down all client-side writing from the get go so you're not trying to guess whether you set your rules properly. Here's an example of that pattern: https://gist.github.com/themeteorchef/194a803f8a28840f475f.

Re: concurrent purchases in your store example, you can actually strip reactivity from certain database queries. So, on the front-end you can prevent state shifting out from under users. To control data on the server, you could have a method that checks whether or not the inventory has been depleted before allowing certain operations (e.g. routing to a new page, manipulating the database, etc). Definitely possible to do this without going bonkers.

Does that answer what you're looking for?

murbard25• 11 years ago

Yes, thanks, sort of! The pattern you use is basically the one I would naturally do, but it doesn't feel "meteoritic"... the client side manipulation of the db really seems centric to the magic of it.

Regarding the concurrent store, forget event about the client. You need to check whether or not the inventory has been depleted and then update the inventory, and create the client's invoice. That means blocking calls, double staged commits, and a whole lot of nasty things that have nothing to do with reactivity and everything to do with integrity.

BurningFrog• 11 years ago

Is anyone hiring Meteor developers? In the Bay Area?

dweldon• 11 years ago

Yep, Edthena is! You can see our profile and job description here:

http://careers.stackoverflow.com/company/edthena

If interested, you can apply through the site or just email me: dave at edthena dot com

spacemarine• 11 years ago

Hedgy.co is looking for awesome people and we happen to be using meteor for our FE development.

Feel free to reach out to me directly at kevin at hedgy dot co

skirunman• 11 years ago

I'm the CEO of a stealth mode startup in SF that is using Meteor in a B2B CRM application. We are looking for Meteor developers and you can reach me at jim at clozertech dot com.

TimJRobinson• 11 years ago

Is anyone here running Meteor in production? I've seen so many intro's and demo's and prototypes but have yet to see any actual products / companies built around it yet.

sergiotapia6• 11 years ago

Check their home page - and those exact words you used just now, those look awfully familiar to what people used to write when Rails first came out. :)

I have such high hopes for Meteor!

nileshtrivedi• 11 years ago

Sidebar.io is based on Telescope which powers a number of sites: http://sidebar.io/

matthewmacleod2• 11 years ago

Hmm. Sidebar is an example of a site that has no reason to use client-side scripting at all. It's a plain list of links, and yet doesn't work without Javascript, and is far, far slower than it should be.

karldanninger• 11 years ago

Workpop is a large production app running on Meteor. They also raised $7.9m http://techcrunch.com/2014/09/16/workpop/

imslavko4• 11 years ago

I have two Quora answers on similar questions:

- http://www.quora.com/Which-startups-use-Meteor-in-production - http://www.quora.com/What-open-source-software-uses-Meteor-f...

clement750092• 11 years ago

A couple months ago we launched edgee, a platform for sharing high-quality content in carefully curated collections, called edgees. The app runs on Meteor and we're very happy with it. http://www.edgee.com

MajinOLesedi• 11 years ago

Great site, awesome UI. I'm also working on a web app using Meteor. This just gave me some inspiration.

hrbrtglm• 11 years ago

I browse with cookies disabled for privacy reasons. How is it that every time I visit a webpage made with meteor, the only thing I get is a blank page ? Is it specific to meteor to not work without cookies enabled, couldn't it at least display a message asking me to enable cookies, even an error page explaining why I get nothing but a white background.

yedpodtrzitko• 11 years ago

https://xkcd.com/927/

nichochar• 11 years ago

I like meteor, I think it's a good framework, that solves well the "Make a webapp with non critical data but where real time is critical" problem.

I've also used angular, which I also like, but has a little bit more of a learning curve drawback.

I do unfortunately believe that a project or framework should make it not because it's CEO or leader is good at selling something, pitching VC's, and creating a brand, I think a project or framework should make it because it is the crowdsourced best solution to a problem. And this kind of money raising worries me a little, because it gives an unfair advantage to a framework. Now meteor might be the best answer, but if it's not, this is a shame and we all stand to miss out on a potential right answer for this...

Anyway, all of this is a little moot because I believe you shouldn't be using javascript for this kind of stuff ^^ but that's another debate altogether

wmf• 11 years ago

It's way too late for that anyway. AFAIK DerbyJS was better than Meteor all along but no one has heard of it.

akhatri_aus3• 11 years ago

I've heard of it and have used both and disagree.

Keep in mind both are open source projects. The community has been immensely successful filling up Meteor's gaps.

auganov• 11 years ago

I don't agree about the unfairness or that it will have a negative effect. But I do think that Meteor's nature as a framework, might be its downfall as a company. I have a hard time imagining how Meteor is going to be able to contain or maintain control over the project given how broad it is. They'll need to provide really strong integration benefits to fight unbundling.

jules• 11 years ago

This is not a zero sum game.

oldmanjay• 11 years ago

In the long run, you'll probably be happier if you realize there are no "right" answers in software engineering. People who can't get past the belief that there is spend a lot of their time telling kids to get off their lawn.

neumino• 11 years ago

Woot, congrats folks!

pdkl95• 11 years ago

sigh

At least judging by www.meteor.com, they are still insisting their users accept the risks[1] of javascript and sending an empty body tag.

[1] If you think these risks don't exist, you haven't been paying attention. I don't care if you want to run exploit code from an ad or be used as ammunition by the Great Cannon; just don't insist that others must accept that risk if they want to read your page (slower loads or reduced functionality with the javascript is perfectly fine).

edit:

So you all value convenience over safety. really, it's probably because you're so used to spying on people that the idea of losing that ability is a thought you cannot abide. After all, why would the idea of losing javascript be attacked so strongly? This gets downvotes faster than anything else. What a lot of website developers don't seem to understand is that recording hover times, click paths, reading times and the like may be "metrics" or "important business data" to you, to normal people that is "creepy peeping-tom" behavior.

I know, you're thinking that this is off topic, or that it's just a tool. No, you're making a political/sociological decision by forcing people to take the risk of javascirpt - and business recording information about people is risk #1.

The non-technical people I know, after slowly learning about how the tech industry really works, have been doing a lot to reduce their internet use. A few have turned luddite. Others are trying to reduce their dependence on network services. That is the end game of people finding out the real price of using some webapp - you're driving people away from the entire concept.

Of course, I'm wasting my breath - clearly the features of some tool are more important than the reality of the future you're creating.

Either that, or djb is right. ( http://cr.yp.to/talks/2015.05.08/slides-djb-20150508-a4.pdf )

akhatri_aus3• 11 years ago

Most sites use javascript anyway. How is this different? If people want to use Meteor to solve their business problem (even internally) how does the negligibly low chance of a great canon infecting a site make this different.

There's also a couple of libraries that implement server-side rendering if the blank page is something that disturbs you.

Ps the loads are faster due to caching & are highly CDNable as they don't change at all. Mostly static.

For the great canon issue: it's not difficult to check against a hash on the script either right? Besides not exlusively being a Meteor problem.

cdnsteve• 11 years ago

Has anyone seen DDP used outside of Meteor? https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP...

rgoomar• 11 years ago

I haven't seen a push for it outside of Meteor yet, but i'm sure that is one of the things that they would want to push for later.

Although, there are various DDP clients for other languages as you can see here: http://meteorpedia.com/read/DDP_Clients

dethos• 11 years ago

One example: https://github.com/whitesmith/meteor-motion

imslavko4• 11 years ago

(I work at Meteor).

There have been some discussions with Asana (asana.com) teams who are building their new data store with a DDP API published for their clients.

GVRV• 11 years ago

We use it to interface with our Django projects https://github.com/commoncode/django-ddp/

dorian-graph2• 11 years ago

I'm writing an Arduino library at the moment as a small part of my thesis which I'll release.

danenania2• 11 years ago

Beginner question: how does Meteor handle storing server-side web socket connections in a scalable way? Are they kept in ram? Redis? Mongo's ram?

The complexity of this is why I always end up reaching for hosted WS solutions like pusher or fanout.io.

merb• 11 years ago

Why is this complex? There are so many ways for pub/sub implementations.

However I always ended up using Playframework for WS, since it's really really easy to set this up in a scalable way.

danenania2• 11 years ago

WS are fundamentally more complex than HTTP since connections are stateful and that state needs to be stored somewhere. It's another dimension that needs to be properly distributed and load balanced to be scalable.

It's not something you need to worry about for small applications, but for a scalable architecture, it's important to know the details of how this works. What happens to Meteor (or Play) with 100k simultaneous connections? How much ram and how many servers will I need? How do I load balance WS data between them? Will another datastore like redis be required? If so, how does it integrate with the framework? What if I outgrow a single instance of that datastore?

If I use pusher, I don't have to think about any of this.

smaili• 11 years ago

Not trying to sound like a jerk, but I'm just wondering is it really a good thing to put on your homepage that there are nearly 12K questions posted on StackOverflow about Meteor? Seeing a number like that makes me wonder if maybe the documentation and or APIs are not very well done if it's generated that kind of activity on SO.

acgourley• 11 years ago

Personally I see it as positive - it means people are using it and I often find searching SO answers faster than searching docs.

trcollinson3• 11 years ago

Maybe it works as the opposite. On SO there are ~800,000 questions about Java, Javascript, and C#, each.

akhatri_aus3• 11 years ago

Maybe on SO questions are answered very efficiently. It doesn't mean the documentation is bad.

It means the community is very at it and its a place to go if you have a question and don't want to dive into the docs

Alot of people do prefer personalised answers over the effort of finding it in docs, sad reality.

gooseus8• 11 years ago

Maybe you're right and everyone else on this comment thread are suffering from some cognitive dissonance?

I'd be willing to bet much of those SO questions and replies are a part of keeping up the Meteor hype with most questions being answered by a core group of devs.

The PR machine for Meteor is crazy. It's funny because this 20M will go to generating more hype and PR opportunities, while the actual development will fall to these wide-eyed open-source evangelists who will give up their time for free to make it better.

Then Meteor will be sold to Facebook and all these open source developers will realize that their work was driving up the valuation for a bunch of investors who couldn't care less about their code or the products it powered.

I'm having a relatively cynical day, I can't tell if I woke up this way or if this Meteor news is what set me off.

DiNovi2• 11 years ago

I was under the impression most of the meteor devs work for meteor?

ibejoeb2• 11 years ago

I wonder where all of the dislike for Meteor originated. It's a cool product built buy some really smart people. They have the best cli tool I've used in a dev environment, and they're making a ton of progress. They're constantly publishing materials on integrating with third-party components including react, rethinkdb, famo.us.

I hear you about the potential implosion by acquisition. It's definitely a risk. It's not much different than other burgeoning technologies in that regard.

Meteor is advancing a new paradigm of building consumer applications, much like Django and Rails did for REST. It lowers the barrier to entry, and it really has the potential to expose a new generation of programmers to modern techniques.

I also think they've been pretty clear about when Meteor is unsuitable, despite the hype. It's not going to magically scale. It's not a bad place to start, though.

sgdesign3• 11 years ago

Just because they've raised $20M doesn't mean every single positive comment about Meteor is part of their "PR machine". How do you know people are not genuinely happy with it?

Disclaimer: I'm one of these "wide-eyed open-source evangelists", I guess.

hamoid• 11 years ago

Someone described this as "high WTF factor".

http://larseidnes.com/2015/01/05/the-wtf-factor-quantifying-...

arxpoetica2• 11 years ago

A few of us have been happily hacking away on SocketStream (https://socketstream.com/) for quite sometime. It's a smaller, piecemeal framework that borrows more from the community of Node pluggable/playable modules.

With this 20M, Meteor just became a heavy-weight—

That said, I still like the idea of a more community-drive approach.

arxpoetica2• 11 years ago

Also, shameless plug, but we've been keen to sponsorship and/or other contributors to get a little more momentum in the SS community. Ping me over here if interested so I don't completely derail this thread. ;) http://robertlangfordhall.com/contact/

dovg• 11 years ago

Serious question: does Meteor scale well in these days?

davidjwoody• 11 years ago

Just published a post related to this topic. Short answer: Yes. - http://blog.differential.com/scaling-meteor-to-20000-users-i...

Everhusk• 11 years ago

Awesome job and congrats on the massive traction on launch day. Thanks for sharing!

debaserab23• 11 years ago

It's amazing how many developers willingly giving up their entire tech stack in exchange for a proprietary one.

If it was MSFT trying to pull this off, would the reaction on HN be as positive?

trcollinson3• 11 years ago

Maybe I am getting lost in your comment but, are you trying to suggest that Meteor is a proprietary stack?

_greim_• 11 years ago

My worry is that with JavaScript-based stacks evolving so fast these days, monied interest in one way of doing things would ultimately be incentivized to suppress better ways of doing things, as they emerge.

Kiro• 11 years ago

What I don't understand with Meteor is how you can build secure applications if you actually write your database queries in the front-end. Can someone enlighten me? How do you hide logic or prevent people from manipulating however they want?

djmashko24• 11 years ago

Database modifications on the client are usually disabled in Meteor. There are two ways to control database access in Meteor:

1. You can write allow/deny permissions rules to allow only certain modifications: http://docs.meteor.com/#/basic/Mongo-Collection-allow

2. You can not use client-side modifications at all and instead write all of your database code inside Methods, which are basically supercharged RPCs that give you automatic optimistic UI updates: https://www.meteor.com/try/10

I think this issue comes up a lot because new Meteor apps come with the "insecure" package by default to enable faster initial development and debugging, but most or all production apps will remove this package.

(I work at Meteor)

M8• 11 years ago

Oh, so that's why they have been trying to sell it here on HN.

aliakhtar6• 11 years ago

For those who're looking for a full stack framework, I can't recommend GWT enough. GWT lets you write java for both client & server, and then compiles the client code to javascript. This compiled js is highly optimized and your css / images / html templates are bundled together to minimize HTTP requests. On the server side, this lets you use java which is a lot more performant than javascript is.

smileysteve• 11 years ago

On the server side, this lets you use java which is a lot more performant than javascript is.

Is it? http://benchmarksgame.alioth.debian.org/u64/javascript.html

aliakhtar6• 11 years ago

Yep: https://www.techempower.com/benchmarks/

Its also fairly obvious that a statically typed / compiled language will have better performance than an interpreted language. Compiler optimizations make a huge difference as well.

Also, even the link you gave shows js being slightly faster in 2 or 3 benchmarks, but for the remaining 4-5, java is significantly faster.

galfarragem2• 11 years ago

I think the main issue with Meteor is that it has the possibility to change the status quo and be an important player in the market. That 'pisses' a lot of people (like once rails did) because it might turn some of their personal investment into obsolete. I am not 'invested' (my background is not CS) but if I was, I would certainly be pissed also.

People here are even pissed that they got more money and other frameworks didn't. Nobody invest (their money at least) without a good risk/reward ratio.

shams93• 11 years ago

Lol Meteor just literally saved my bacon, the combination of meteor + ionic enabled me to build an entire app in less than two weeks working part time on it and if I hadn't told the client it wasn't native there was no way for them to tell, the performance is that good. Plus the error messaging is awesome and the isometric approach is just a huge win, the previous version of the product was in angular + rails, industry standard but slow as hell, absolutely did not perform like a native mobile app, but Meteor is just fantastic in my experience for extreme starup scenarios where we are going with Mongo anyways. Certainly if I needed to tie into legacy sql based systems I would be looking at loopback, but with lookback you are still stuck with the weight of the other available front end frameworks and the back end is easier, but you still have to do tons of boiler plate, except perhaps with react + loopback in the case of place a really modern front end on a legacy system while still having ok performance. Meteor feels native because you're not issuing all this old ajax, its data format is even smaller and tighter than json.

atmosx• 11 years ago

Out of curiosity, did ever rails raise any money?

Meteor Raises $20M

Related Stories