HN Explorer

Ask HN: server- and client-side web framework?

9 points by alecbenzer ↗ HN
I've been looking around at some of the new Javascript UI frameworks (sprout core, extjs, kendoui, dojo), and been thinking about the pros and cons of js-based web apps. One that comes to mind and that I've seen mentioned elsewhere is the fact that there's a fair amount of duplication in creating code that manages your data. Ie, you need client code to receive your data from your server, and you need server code to serve your data to your client. Why hasn't someone developed a framework that address this issue? Ie, something where the developer works in one language, and then the appropriate server and client code is generated, so there's no duplication.

Does something like this already exist, and I just haven't noticed it? And if not, is this a good idea? I've been thinking about trying something like this out in a project, but I have a tendency to overlook things and go ahead doing something that I think is smart but that I later realize has some flaw that makes it not a good idea. So I wanted some other thoughts on this.

8 comments

[ 3.1 ms ] story [ 31.5 ms ] thread
knowtheory
Yes.

https://github.com/danski/spah

What @angryamoeba (danski on github) is trying to do, in so far as i have understood it is to address the problem that say twitter has in that it loads up a dumb empty template, and then you have to wait for the JS app to boot up and populate your page.

Instead what he's tried to do is specify a consistent way to specify data in HTML documents (via data attributes), and a framework for syncing modifications to data between the client and server (and this is bi-directional).

That way, if you're doing a cold boot, data is specified in page, and if the client has already loaded an object, full pages/data don't have to be pulled down to the client when things change, and likewise full page state doesn't have to be shoved up to the server when the client changes something.

angryamoeba
Thanks for mentioning that - Have to say, it's a work in progress. The query language for JSON (called SpahQL) is done, but I'm currently working on the document runner. See the readme for how it's meant to turn out.
alecbenzer
Don't have time atm to read it too in-depth, but it seems like this is a bit different from what I was thinking of, in that I was thinking of a more complete rails-like MVC type thing. But it does seem to confirm that I am in fact not retarded, and that this type of thing is a good idea.
angryamoeba
Sure - Spah is intended to act as the V in your MVC. I'd probably just use Express for the C and Mongoose or similar for the M.

I find that stitching my own framework from quality open source components gives me a bit more flexibility than Rails (rails user since version 0.7) and lets me get closer to the metal when I need it. Your mileage may vary :)

And no, you're definitely not retarded.

alecbenzer
Okay but so there may be, for example, duplication as far as your model code? Like, I need to define my model through Spah, but then I also need to define the same model in my server side code that's going to be serving you that data?

I was thinking of something where you essentially write the whole app in ruby, and then it generates DataMapper models for your objects, sinatra routes to access the data, and js code to actually access the server and hook it up with your ui. Something more along those lines.

I first touched rails at 2.something, a bit before 3.0, but it was my first experience with MVC (that is, a single framework that handles all of your MVC) and I had a lot of mixed feelings about it. I still bounce around a lot but right now I'm leaning more towards "MVC is good".

hdeo
Some 'possible' reasons to use different client and server frameworks:

1> Decoupling. Add APIs / more clients in future 2> Effective use of skills. Many developers specialize in one of the two. 3> Parallel development of client and server 4> Future client side caching, tracking etc. (can be solved with a lot of server code)

This is not to say one should not do it, use cases differ.