Meteor Raises $20M to Build the One JavaScript Stack to Rule Them All

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

by milkers • 11 years ago

39 47 11 years ago

techcrunch.com

nickstinemates• 11 years ago

I have been hearing about Galaxy for around 2 years, looking forward to seeing it shipped and in users' hands.

anon3_3• 11 years ago

The reality of javascript is different in browser and server (node/io).

While I find that meteor was fun to work with, we ultimately opted for plain-old express + backbone. I think it's abstraction is more of a disservice. It adds a lot of magic and unknowns to the picture.

After a few months, the initial value of having the unified codebase is exhausted, and you're left with the technical debt of having already adopted their libraries and conventions.

It's not really accurate to say that meteor allows you to use any library, you are adopting their conventions. In the end - using a single unified codebase in JS involves going against the grain in many aspects (I can elaborate if you like)

philippnagel• 11 years ago

Please do!

We are currently evaluating what to use to build a data analytics application (Work with data, ETL, connect to various DBs and APIs, etc.)

anon3_3• 11 years ago

They are inherently different on many levels.

Browser: global is window/document

Server: global is global

Browser: interacting against DOM objects and events (clicks, etc)

Server: you are wedged into the function(options,callback) pattern and many promise libraries. you are often using functions as "middleware" or wrapping them in promises.

Browser: bower

Server: npm

Browser: better debug tooling / inspector

Server: sometimes you won't be getting a good traceback unless you know how exceptions work. the way libraries are glued together make errors and error handling hell (practically another job) practice. If you want me to elaborate, please ask.

I could go on to say that most node projects I see in startups are misguided. I could elaborate.

TY• 11 years ago

Please do elaborate. I'm in the middle of building of my first Meteor app and would love to hear your perspective about it.

Exuma• 11 years ago

He replied below

CydeWeys• 11 years ago

If it's not going to be Free Software, who cares? I've seen so many people, projects, and companies burned by choosing a proprietary framework.

TylerE5• 11 years ago

Uh, it's MIT licensed. That's about as free as it gets.

JoeAltmaier5• 11 years ago

Except of course for, actually free. Like, unlicensed.

escusado• 11 years ago

if(Meteor.isServer)... uhm, no thanks.

rglover• 11 years ago

This is just one (basic) way to do this. In a real app you put all of your server code in a /server directory, removing the need for the if statements.

singlow• 11 years ago

No one would actually use this in production code. It is a useful convention for examples so that you can tell you are in server or client code. Occasionally it might be useful in a function that only has a slight deviation in behavior on the server, although usually you would wrap that difference in a function that is implemented separately in client or server only libraries.

In application code you would put all server-only code in the server directory and that code is excluded from the client code, same for client only code. In plugins, you specify which files are included in the client and server explicitly.

JustSomeNobody• 11 years ago

I've seen enough code to know that if it's in an example, it's in production.

applecore• 11 years ago

It seems like a lot of these real-time capabilties should be part of the database layer, à la RethinkDB and its model of continuously pushing query results as they're updated.

This way, you're not locked into one JavaScript-based application development framework.

twerquie• 11 years ago

But you can't have clients directly connecting to the database, their sockets still need to flow through an application layer where you have your business / application logic. Unless you start putting application logic into the db?

zippy786• 11 years ago

Shouldn't business logic reside in DB inside stored procedures ?

enos_feedler2• 11 years ago

Your right about this. Couchbase solves it by putting a sync gateway in front of a couchdb connection. But this makes things hard to manage for the reason you mention: business logic inside your DB. All your rules about access control and users are actually derived from values in your couchdb documents. Its not pleasant to design or maintain.

Lazare• 11 years ago

CouchDB is possibly a better example, as you actually can have single-page applications connecting directly to the DB for streaming updates.

That being said, I think you're right: Whatever DB, server, or client tech you use, the real-time synchronization stuff seems like a minor add on.

Meteor seems predicated on the idea that you can't do synchronization with whatever random stack you want, but need to use Mongo as the DB, Meteor as the server, and Meteor as the client. This is kinda nuts; you can trivially do it with any tech stack. Postges, Express, and Knockout.JS? Sure, will work great. Firebase and React? Super. MySQL, PHP, and some jQuery soup? Yep. (Hint: Don't do that. But it'll work.) And with all due respect to the Meteor team, I think React or Mithril are much better frameworks than what they're developing.

Honestly, I feel like the Meteor guys have such a bad case of NIH syndrome that I'm always slightly surprisd they're using Mongo, and didn't write their own DB too.

highCs• 11 years ago

Previously discussed here: https://news.ycombinator.com/item?id=9569799

murbard22• 11 years ago

This is a bit tangential, but I really don't get the value of using the same language on the client and the server. The advantages I see would be:

1) You need to know / be comfortable with one language less

2) During development, you can easily move functions back and forth between the client code and the server code, progressively deciding what will be computed on the server and what will be computed on the client

3) You can generate, exchange, and execute code in real time between the client and the server

but

1) I don't know any programmer who's both competent and monolinguistic.

3) is of course insane for security reasons

2) I used to think this would be a thing, but once you take the approach of making the client a GUI to an API, this doesn't tend to happen. It's generally very clear what's going to be server side and what's going to be client side.

enos_feedler2• 11 years ago

What about server-side render on page fetch and client side rendering afterwards? Or running business logic client side so the UI appears snappy and then enforcing that logic server-side? This would benefit from the same code running in both contexts. But I agree with your other points, its not a huge deal. Even the points I mention don't seem like core issues.

frivoal• 11 years ago

agree on 1 and 3.

As for 2, I think it makes sense. You can pre-render your GUI on the server side, so that clients get served proper html rather than an empty pile of js, and then have the same codebase take over on the client side, single-page-app style, just talking to the backend to fetch data.

murbard22• 11 years ago

That sounds good, but it only means that you have to be able to execute the client code on the server. You locally (i.e. on the server) simulate a client connecting and doing some rendering, then send a continuation to the real (remote) client.

Also - does Meteor do anything remotely like this? I doubt it.

roneesh• 11 years ago

I sort of agree, I can see virtues, but I've never seen good examples. From all my full-stack work, it's hard for me to imagine really pure isomorphic examples. Definitely we'll have similar patterns and such, and small snippets that work in both contexts, but large functionality line for line code that works in the context of a server and a client, well I've yet to see good examples (anyone feel free to point me to some!). Perhaps that's not the goal of isomorphic code, but if it's just re-using small lines here and there, I can translate from one language to another pretty well.

afshin• 11 years ago

I think the biggest benefit of having the same view layer logic on the front-end and back-end is to send pre-rendered views to the client without having to to generate the markup using two different sets of code.

Other than that, your data access and APIs could be written in any language, if you separate your view logic out. React on the client and server makes it easy to have the same view logic without making a similar commitment about the rest of your business logic.

owenwil• 11 years ago

Why is this back on here today?

serve_yay• 11 years ago

Yes, I'm wondering that as well.

bigtunacan• 11 years ago

Why has this been re-posted?

https://news.ycombinator.com/item?id=9569799

progx• 11 years ago

Why you re-post the re-posted post below?

Meteor Raises $20M to Build the One JavaScript Stack to Rule Them All

Related Stories