isOmorphic javascript

Where am I? Where have I come from?

And what am I doing here?

Intention

So in 10 days in May 1995, I prototyped “Mocha,” the code name Marc Andreessen had chosen.

- Brendan Eich

DEFINITION

By Isomorphic, we mean that any given line of code (with notable exceptions), can run on the client or the server.

- Charlie Robbins, Nodejitsu, Oct 2011

Where are we headed?

AirBnb 2013

http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/

Ember, Angular, Backbone

Meteor, Derby, Rendr

OLDEN DAYS

THE FUTURE

ASP.NET, Ruby, Django

OLDENEST DAYS

MVC Apps

Single Page Apps

Isomorphic Apps

spa SPEED + GOOGLEBOT LOVE

= isomorhic deliciousness

At the end of the day, we really want a hybrid of the new and old approaches: we want to serve fully-formed HTML from the server for performance and SEO, but we want the speed and flexibility of client-side application logic.

Single biggest draw for an isomorphic approach

TESTABLE
STATEFUL
MAINTAINABLE

ISOMORPHIC:

WHAT ELSE?

Where have we been?

Atwood's law

built atop the Principle of Least powerful

any application that can be written in JavaScript, will eventually be written in JavaScript.

- Jeff Atwood, 2007

POST 2007

V8 OPEN SOURCED BY GOOGLE

RYAN DAHL CREATES NODEJS

2009

2008

~~LEAST POWERFUL~~

MOST ACCESSIBLE

now what?

vanilla M.E.A.N. is not good enough.

Why build in server side node.js what could be accomplished in 'traditional' stacks like ASP.NET, Rails, or PHP?

Just because both client and server code is written in Javascript DOES NOT mean your app is isomorphic.

SHARE. YOUR. CODE.

Client, Meet Server

convergence principle

How many problems are being solved?

not all isomorphic apps are the same

Isomorphic? Check.

So Why meteor?

OKAY.

Three Biggest Objections...

Meteor: First to Market

Being first to market with an isomorphic framework means you have to solve all these problems [seo, performance, and maintainability], at once. But this leads to large, unwieldy frameworks that are hard to adopt and integrate into an already-existing app. As more developers tackle this problem, we’ll see an explosion of small, reusable modules that can be integrated together to build isomorphic apps.

Is it too early?

Objection #1 - Meteor is too young

The answer to Objective #1.

COMPOSIBILITY

(and the incredible respect for classical historical engineering and the 'unix philosophy' by the Meteor core team)

Meteor: only for prototyping

Objection #2 - Meteor Is Just a Toy

I mean cool, so Meteor is maybe better for prototyping. Because that's all we're talking about here, prototypes and ultra-simple websites....

- BowlOfPetunias, Hacker News, 386 days ago.

The answer to Objective #2:

hush now

Don't be discouraged if what you produce initially is something other people dismiss as a toy. In fact, that's a good sign.

- Paul Graham

SYNCHRONOUS programming + proprietary package management.

Objection #3 - Meteor Is Too Opinionated

I'M NOT CRYING.

IT'S JUST RAINING ON MY FACE.

the answer to objective #3, fibers:

...To take just one example, the thread-per-request or process-per-request model is very common in the larger software engineering community, whereas node's continuation passing ("asynchronous") style is sometimes used for chat servers and message busses but is almost never used for business logic. I think that server-side JavaScript usage is going to grow by multiple orders of magnitude in the next few years, and we're going to have a massive influx of new developers. Most of the new code that these developers write will be business logic, and they'll want to write it with the straight-line control flow that they've used in almost every other framework.

To accomodate the coming growth:

Geoff Schmidt, Meteor Core Developer, 2013

http://www.quora.com/Node-js/Why-is-Meteor-much-more-popular-than-Derby

the answer to objective #3, packaging:

SEVEN main points.