N2O: Erlang Web Framework

http://kukuruku.co/hub/erlang/n2o-erlang-web-framework

by andreygrehov • 12 years ago

98 20 12 years ago

kukuruku.co

rdtsc3• 12 years ago

This framework is really out there. It is well ... different and interesting.

Here are some not so conventional things going on:

* Write your page in Erlang.

* Even translates Erlang to JS as a parse transform.

* Websockets (with a fallback mechanism) is the default connection mechanism.

* Don't want to use JSON for some crazy reason? That's alright, user Bert (and ship binary encoded Erlang terms to the browser!).

* Can render stuff on the server and send the whole thing over the websocket connection.

https://github.com/5HT/n2o

toast0• 12 years ago

JSON doesn't really fit very well into Erlang structures (at least in r16; I haven't played with r17 yet); so I don't think not using it is that crazy.

rdtsc3• 12 years ago

r17 does have maps, here is a jsx version with maps instead of proplists for example.

    jsx:decode(<<"{\"library\": \"jsxn\", \"awesome?\": true}">>).
    #{<<"awesome?">> => true,<<"library">> => <<"jsxn">>}

https://github.com/talentdeficit/jsxn

Speaking of json in general, this reminds me of a part of a talk by Joe Armstrong he gave at the React 2014 conf (K things I know about building Resilient Reactive Sytems)

https://www.youtube.com/watch?v=rQIE22e0cW8

Not related to Erlang necessarily, he talks about how at Ericsson they build these cell phone network-to-internet gateways and now they go to great lengths to pack data as tightly as possible on the communication channel, bit by bit, to conserve shared bandwidth and then "here come the users and shove json across the pipe, what a travesty!" -- it was a funny statement, and I never really thought of it that way. So I guess shoving binary across websockets like N2O is not totally insane.

hackerboos2• 12 years ago

Websockets (with a fallback mechanism)

Not enough frameworks make this as seamless as it should be. So it's refreshing to see it done here.

I've been looking at Phoenix (Elixir not Erlang) but the problem is that I'll have to do logic to detect when WS are available and do the fallback myself which results in more code server side.

I think this is something that should be handled by the framework itself.

5HT3• 12 years ago

It is handled by N2O automatically. See how https://github.com/5HT/n2o/blob/master/priv/bullet.js

chrismccord• 12 years ago

I'm the author of Phoenix. I'm glad to hear you're giving it a look! I spent a lot of time thinking about the WS layer and fallback support. Ultimately I settled for standard WS with a small multiplexing layer on top. For those that need fallback, they can drop in websocket-js (flash fallback, compatible with native WS api). Have you taken at look at this for your fallback support? https://github.com/gimite/web-socket-js

Phoenix is still far from 1.0, so any and all feedback is welcome.

pygy_• 12 years ago

Not enough frameworks make this as seamless as it should be.

There are lots of options for Node.js, for both low-level socket-like libraries (SockJS, SocketIO, EngineIO), and frameworks (Meteor, Derby, SocketStream).

Thinking of this, it's a pity that SocketStream failed to gain traction. It has a lot, technically, and was way ahead of its time (in 2011). Beside the middleware framework for WebSockets, it also provides

* RPC and Pub/Sub, built on top of the middleware stack,

* live reload for development, including swapping CSS files without reloading the full age, which enables

* automated, continuous testing in as many browsers as you like (keep your test pages open, they are reloaded on file change)

* a Browserify-like environment to structure the client code.

* an elaborated asset pipeline, that handles JavaScript, HTML and CSS preprocessors, and packs/compresses everything for production.https://github.com/socketstream/socketstream

Both the socket layer and the asset preprocessors are based on plugins, which makes the framework flexible.

A really good system, that was plagued by a severe case of not second but third system syndrome, which scared users away, since they (rightfully) feared that the rewrites would leave them in the cold.

The original developer (Owen Barnes) is a visionay and a brillant programmer, but he still failed to execute by never being satisfied with the implementation details. He has now moved on, and the framework is being maintained by Paul Jensen. Things have now stabilized. A third rewrite of the framework has been canned. The frameworks is still as good, but it remains marginal because Meteor managed to get the mind share.

[0] https://github.com/socketstream/socketstream

5HT3• 12 years ago

Some mentions about the list:

* You can use both Erlang DSL and/or DTL templates

* You can use JSON, BERT, RAW BINARY messages. see http://synrc.com/apps/n2o/doc/web/protocol.htm

* You can use N2O both as server-render and in SPA mode

davidw• 12 years ago

I think there's still room to innovate in the Erlang/Web space. Chicago Boss was a nice improvement because it ties so much different stuff together. It does have a few issues though, like not being very 'Erlangy' in places: it uses lots of parse transform magic. I think it's the right direction though, in that it's fairly general purpose.

N2O: Erlang Web Framework

Related Stories