Comment by nikcub | Hacker News Reader

Comment by nikcub | Hacker News Reader

With the last three projects I have started (none live, yet) the backend is nothing more than a REST API and the frontend a single HTML page with javascript, javascript, javascript.

This is what web applications are now and will be. The user experience can not be compared to the old style of application. If you are still building applications today that are GET, fetch, pause, render, etc. then you are years behind. It is awesome being able to click on a link to a 10-page forum thread or blog comment page and have it render in ~100ms.

I think all of the web server frameworks will have to adapt - from RoR to Django etc. since a lot of what they do is being moved to the client (and it becomes even cheaper to run large-scale web services because of this). There are also tons of gaps on the client side - from more capable and cachable templating engine through to a full-stack framework (something like RoR for Javascript but less confusing and hard to use than the current)

The server now is just db+REST, auth and pubsub - soon enough somebody will release a generic PaaS that does all this based on a schema. Almost no more, or very little, server-side code (unless you insist on supporting old HTML clients).

> With the last three projects I have started (none live, yet) the backend is nothing more than a REST API and the frontend a single HTML page with javascript, javascript, javascript.

You might be doing that already, but the article mentions (if I got that right) that if you GET an arbitrary URL, the server will still serve the whole rendered page - asynchronous loading only happen on any subsequent requests.

This way, you don't "break" URLs, pleasing search engine crawlers and allowing copy/paste of the links, and still delivering a great experience for the user.

I truly believe there is a big demand for a Node.js framework to facilitate this. There are already a few that allows this kind of architecture (to some degree), but none are quite "there" yet.

I am doing async on even the initial requests. If you land somewhere 'within' the site the path will be passed from the backend router to the javascript router and then triggered on the client side.

the decision to be made there is do you want to load all the objects (models, views etc.) or have an init where it is all either loaded async or from the localstore cache. I went with the later so that the html page can be static cached.

this has taken me a while because there was a lot of js to write - for eg. a sync replacement that uses localCache and the server smartly, that responds in async with 'ok' so the view can be updated rather than waiting on the server, and then triggering server updates every x seconds or when the user closes the window (this all has to be cross-browser, which is the hardest part)

a node.js framework that does all this would be great, while I am using Python atm I think these types of apps are very well suited to run on node.

What are some of the frameworks you've seen? I've been looking for frameworks that allow client-side javascript routing to be reused on the server. So far I've found two, both using a combination of backbone.js and jsdom to render pages on the server:

https://github.com/Morriz/backbone-everywhere https://github.com/developmentseed/bones

Rendering arbitrarily on either the client or server is hard. Other solutions that I saw forced the developer to have to think about it, so I developed FaxJs which allows the system to handle that complexity for you.

https://github.com/jordow/FaxJs

The gist is that you just write standard declarative ui structures in pure javascript and the system disassembles the markup on the server, and reassembles it on the client with all the events still in tact. You wouldn't know all that is happening just by looking, though.

    ...
    var twoDivs = {
      className: 'outerDiv',
      onClick: this.outerDivClicked,
      innerDiv: {
        className: 'innerDiv',
        content: 'inner-most-div!'
      }.Div()
    }.Div();

Or you can just do it all on the client too, if that's your thing. You'll need to work to get this integrated into your routing technology as with any rendering system.

I'm mostly on the same page as you, trying to somehow integrate Backbone on the server side. In the end, the mess I was creating became really unmaintainable and I left the project on hold.

ASP.NET MVC does a really nice job. I have a pattern that detects whether the request is for JSON or HTML (via a GET or POST parameter) and return a user control (module or what have you) or the entire page respectively.

Try this combo: Express(server routing), Sammy(client routing), Jsdom, Jsviews(templates).

> I truly believe there is a big demand for a Node.js framework to facilitate this.

How do you feel about derby? (http://github.com/codeparty/derby)

First time I see this, looks extremely promising. Thanks for the link!

TBH there's no reason it needs to be node, you just need to use a template that could work on both client and server.

Not that I know of any yet.

Zappa with CoffeeKup can do server and client template sharing. Or jsdom and jsviews if you find Zappa too fancy.

Jade (very HAML/Slim-like) can do both client- and server-side rendering, and it can also precompile your template into pure JavaScript so users don't need to download a bulky template engine for it to work.

Mustache (http://mustache.github.com/) has implementations in 20+ languages including javascript. The templates themselves are entirely declarative - any logic is contained within a separate object.

If you don't need any custom logic at all, you can easily use JSON to pass that object between client and server with no further changes. If you do need some custom logic, it'd be slightly more work, but then again you could just opt to use javascript for any small pieces of logic, as there are V8 and/or Spidermonkey wrappers for most or all of the languages supported by Mustache.

"...then you are years behind." I don't agree with you. With AJAX you still have to GET, fetch, pause, and render. The only difference is the amount of data transmitted. Battlelog is transmitting layout and data the first time. Afterwards it is transmitting data only, but still needs rendering on the client side. When your website has little layout-data the overhead is marginal.

So I don't know what a 10-page forum has to do with it. I can render a 10-page forum in ~100ms without Javascript. It all depends on server-time and layout-data.

Maybe you should tell PG this site is years behind ;)

Reply on news.ycombinator.com