Agreed. I'd prefer to discuss the pros/cons of the framework, but honestly the content on the left was enough to make me stop reading. It's unfortunately very common to miss out on interesting content because of UI pickiness.
There was a link posted on reddit about this framework, however it linked to a nodejitsu blog post, and iirc, nodejitsu links cannot be submitted to hackernews.
github link? Some radical ideas in this framework! Quite close to what I've predicted in the merging of frontend and backend frameworks (think Brunch with backend DOM awareness).
EDIT: [github link](https://github.com/flatiron/flatiron)
Seems like quite a feat has been accomplished. But it also feels like it was simply done for the sake of it, instead of creating a framework that addresses real problems. Will have a close look however, correct me if my 2 second impression is completely off.
You are right, at first I did do it just to see if it was possible. I've been meaning to write in more detail about some of the implications, clean up some of the code, etc. I've also experimented with the API to feel out how it could work with other client side stuff in an isomorphic way, url routes, and other frameworks (https://gist.github.com/1336381), but havent released any of that.
> instead of creating a framework that addresses real problems.
If you need to protect code that is currently client-side while retaining responsiveness, this will solve that problem.
In my opinion, the price for that is too high. You are significantly increasing the traffic between the server and the client. On top of that, you are forced to do all your work on the server, which to me feels like a step back to the way we used to do things a decade ago. Beefy servers handling a few clients, rather than light servers handling thousands of clients.
Without going into too much detail about it your assumption is only partly true. It depends on how many API calls you make to jquery from the server, but also sending your realtime data in HTML actually doesnt suck (your server already renders html like this for http requests) and you also dont have to serve up any client-side assets -- the total number of KB transferred is likely to be less with nodequery even after x amount of time on the site because you keep everything but arbitrary strings of HTML on the server.
You could make a 10,000 loc app, and you wouldnt even have to serve up a line of it to run it (in realtime) with a browser.
EDIT: After looking through Flatiron/Plates, I'm really interested in seeing how I might be able to get them to work together.
> your server already renders html like this for http requests
This hasn't been the case for me for literally years. Everything is pretty much dynamically loaded into the DOM by javascript. The server just pushes raw data to the client via XHR.
If you're still rendering HTML on the server, then yeah, this would be a drastic improvement. Absolutely.
I'd like a simpler explanation of how it all works. With colorful flow charts and graphs.
I'm really interested in how it compares to what express does. How is it the same, how different? However since I'm reading this from the office between doing actual work I've not got time to read this version.
I may or may not remember to come back and check it out after work.
Anyways, all of that is intended as a round of constructive criticism. At the end of the day, it is what it is.
The proposed Resource-View-Presenter model is a bit of a brain bender.
Anyway, that aside, I agree -- this is described as a framework "initiative", and that page has no links to actual code, making it sound like a mere proposal.
However, looking back at Nodejitsu's blog, it looks like they have a post with a more cogent explanation... and github links:
yeah, but, it's not immediately clear to me why they built sugarskull instead of a client library to match connect's routing (I've used sammyjs for that purpose)
and while I do appreciate the philosophy of plates (I've done something similar), I wonder why wasn't that implemented as an express 'template engine'.
I'm sure there's good reasons:
I'd like them spelled out ;{)}
looking good.
sammyjs emulates Sinatra. Sinatra is ad-hoc routing, vs centrally-declarative (e.g. a routing table definition). And although sammy is great, it is also a jack-knife with many plugins, we wanted to move the plugin-like capacity to a higher position in the architecture, which keeps sugarskull simple and focused on routing. I dont think the router is the right place to hang all your functionality from.
`plates` is essentially a loose html-parser. The only reason it exists is because `weld` is too slow right now for mass consumption. `plates` is intended to ensure that developers have a way to template without DSLs since a lot of people want to keep their markup clean.
hey, thx for the explanation.
sounds like I should consider replacing sammy with sugarskull
I totally endorse the anti-template philosophy. But I want a bit more, like targeting attributes (eg, the href of an anchor, the value of an <option>) and replicating a class-selected fragment for welding data from arrays.
Awesome! I had a similar on building something like this. One thing is for certain, members of the community lean more towards a simplistic, minimal, and clean toolset. Express.js delivers, and this seems to as well.
I've dedicated myself completely to Node.js for the last month, and I'm sold!
25 comments
[ 4.4 ms ] story [ 64.9 ms ] threadOn another note, when will they launch? I got an email a while ago announcing the beta but never let me sign up.
If you need to protect code that is currently client-side while retaining responsiveness, this will solve that problem.
In my opinion, the price for that is too high. You are significantly increasing the traffic between the server and the client. On top of that, you are forced to do all your work on the server, which to me feels like a step back to the way we used to do things a decade ago. Beefy servers handling a few clients, rather than light servers handling thousands of clients.
You could make a 10,000 loc app, and you wouldnt even have to serve up a line of it to run it (in realtime) with a browser.
EDIT: After looking through Flatiron/Plates, I'm really interested in seeing how I might be able to get them to work together.
This hasn't been the case for me for literally years. Everything is pretty much dynamically loaded into the DOM by javascript. The server just pushes raw data to the client via XHR.
If you're still rendering HTML on the server, then yeah, this would be a drastic improvement. Absolutely.
I'm really interested in how it compares to what express does. How is it the same, how different? However since I'm reading this from the office between doing actual work I've not got time to read this version.
I may or may not remember to come back and check it out after work.
Anyways, all of that is intended as a round of constructive criticism. At the end of the day, it is what it is.
http://blog.nodejitsu.com/scaling-isomorphic-javascript-code
The proposed Resource-View-Presenter model is a bit of a brain bender.
Anyway, that aside, I agree -- this is described as a framework "initiative", and that page has no links to actual code, making it sound like a mere proposal.
However, looking back at Nodejitsu's blog, it looks like they have a post with a more cogent explanation... and github links:
http://blog.nodejitsu.com/introducing-flatiron
`plates` is essentially a loose html-parser. The only reason it exists is because `weld` is too slow right now for mass consumption. `plates` is intended to ensure that developers have a way to template without DSLs since a lot of people want to keep their markup clean.
I totally endorse the anti-template philosophy. But I want a bit more, like targeting attributes (eg, the href of an anchor, the value of an <option>) and replicating a class-selected fragment for welding data from arrays.
I've dedicated myself completely to Node.js for the last month, and I'm sold!