Hacker News Reader

Comment by anon3_ | Hacker News Reader

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)

View on HN

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

He replied below

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.)

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.

> 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.

How much time did you actually spend evaluating Meteor? Meteor is using fibers on the server and thus the code is written in the synchronous style.

The above comparison was about the difference between JS in browser and server-side.

> How much time did you actually spend evaluating Meteor?

A week? I saw the fibers dependency.

> Meteor is using fibers on the server and thus the code is written in the synchronous style.

There is no library (promises, fibers) that alleviates the simplicity of being able to do:

  users = User.objects.all()

And not having to wrap it in a promise.

I should add, we went from Meteor -> Express -> Django. It was such a relief to invest time in our features, and not having to have the downsides of every minute DB / API being asynchronous. I could elaborate.

> There is no library (promises, fibers) that alleviates the simplicity of being able to do: users = User.objects.all()

As an counter-example, Sequelize offers both callbacks/promises so you don't have to wrap the query function manually. In fact many libraries provide promise interface or can be promisified with bluebird.

Using ES7 async/await and babel you just write:

let users = await Users.findAll()

Async/await syntax was the feature that made JS development pleasant for me. Brackets and parentheses soup that tends to be produced by callbacks/promises made my pattern recognition sick.

I'm currently working on a Express/Angular contract. I'd say the debug tooling in WebStorm for the Express server is more sophisticated than the browser debug tooling for the front end, if only for shortcuts like "run to cursor". And that's even before we get into SpyJS (which to be honest can work on either the front or back end).

Reply on news.ycombinator.com