7 ms·

Domain specific languages I suppose are the next cool aid. Or languages with a comprehensive macro system (like Elixir) can bridge the gap between these ways o

Domain specific languages I suppose are the next cool aid. Or languages with a comprehensive macro system (like Elixir) can bridge the gap between these ways of thinking. This feels very frontend focused though - I'm wondering if there is a more holistic approach. I have an idea for a framework/project, that over web sockets, views the browser as a thin client for a server side representation; commands would be sent from the browser but defined on the server. I haven't decided how this would work yet fully but it would be interesting to do the DOM diff-ing on the server and have the thin client only transfer the changes. This would hopefully make the initial payload extremely small and the changes being transferred minimal as well. Are there any projects that do anything like this currently?

johanobergman 9y ago
I made a proof of concept for such a framework. There are some really cool benefits (like automatic server side rendering, really small js bundle, all code on the backend etc.) but falls short for things that require immediate response, such as drag/drop, or text input.
tim333 9y ago
Meteor is a little that way although it doesn't DOM diff on the server. It kind of diffs the Mongo database on the server and then updates mini Mongos in the clients where appropriate. Js in the clients then update the DOMs.
jules 9y ago
Seaside from Smalltalk. To some extent the original ASP. There is also a PHP framework that does that, but I forgot it's name.
Bogdanp 9y ago
Not exactly the same but you might want to check out Ur/Web, Eliom and the standard Racket web server lib.
randomstudent 9y ago
Yes. This Elixir library aims to have a virtual DOM on the server and send minimal diffs to the client: https://github.com/grych/drab https://github.com/grych/drab It can already do this for some kinds of diffs, but it doesn't have a full VDOM yet. It basically allows you to build interactive pages without writing any javascript.
- MrBlue 9y ago
  Drab is one of the most interesting and impressive libraries to emerge from the Elixir/Phoenix ecosystem.
thinkloop 9y ago
> DOM diff-ing on the server and have the thin client only transfer the changes. This would hopefully make the initial payload extremely small and the changes being transferred minimal as well. To achieve similar results, you could granularly partition the build so that scripts are lazy loaded as needed. This would be like sending diffs, except only once since the client can reuse them. Having a server manage the DOM state of every client, and maintaining sockets between them, seems like a complex apparatus.
noway421 9y ago
Like an X Server for the DOM? While interesting, that means that every communication would need to be tranfered to the server and there'd be no instant one-frame actions. That fits a limited set of UIs. And would lag with substantial network latency
- pjmlp 9y ago
  I once saw a company that had a product which was basically JSF as network protocol for Swing.
rlander 9y ago
N2O[0] does exactly that. You write your app in Erlang and the framework delivers the changes via websockets to the browser. You can even choose to have the changes computed in the browser through an Erlang -> Js bridge. Pretty cool. [0] https://github.com/synrc/n2o https://github.com/synrc/n2o
- andy_ppp 9y ago
  This looks great, I'll try it out!
jerf 9y ago
"I'm wondering if there is a more holistic approach." The end game, once WebAssembly is fully integrated into the browser, is to expose the 3D API and/or a high-performance low-level 2D API (or both) and slowly, but surely, a "web browser" will become an environment where you download a full rendering engine for a website, written in an arbitrary language that has WebASM support, and in the end both DOM and JS will become merely another option, at which point IMHO neither of them will actually fare very well, excepting their substantial existing install base. Caching will make this feasible as most of the "long tail" isn't going to make their own engine, just use someone else's, and there aren't really all that many sites who can afford to write their own. While I consider the forces pressing on the browser to virtually predestine this outcome, it is at least 10 years off. (If it wasn't for the fact that Javascript is still not fast enough to pull this off, I think we'd already see more frameworks that do layout and ship down a lot more divs and such with hard-coded absolute positions, turning the browser into an environment where it simply puts text and images where the server tells it to, and stops doing all this expensive reflowing and layout. You can see on all kinds of sites the desire to do this on the part of web publishers. However, it is impossible to do this on the server side because you need access to font metrics (where you may not be able to force your own), screen size info, browser zoom level, and a whole bunch of other such things that make it impractical to do server-side in a whole bunch of ways. But JS is still at least ten times slower than native code here, plus would take an inevitable penalty accessing a lot of FFI code, so this is currently almost unthinkably infeasible on the client side.)
- jpfed 9y ago
  James Mickens presents something like this idea: https://www.youtube.com/watch?v=1uflg7LDmzI https://www.youtube.com/watch?v=1uflg7LDmzI
  - jerf 9y ago
    Yes, I had the pleasure of seeing him present that live once, though not at that one. I think he was disappointed that people weren't helping him work on it, but I still think that long term the pressures are absolutely inevitable in that direction. It's just that the world at large can't jump there in one shot, it has to get there one very laboriously-worked-out technology at a time first. He's gotten a bit more famous for his sense of humor, but I can attest that he knows his stuff.
mbrock 9y ago
I once wrote an app that worked by sending diffs, not DOM diffs but JSON diffs which were then applied by the client and rendered by React. The data store was a repository, and so a client could ask "please give me the diff between states X and Y", and the server would make a diff between those trees in the repository. Most of the time the client would be long-polling for a new revision with the diff based on the previous one, which could be cached efficiently, but sometimes a client would come back from "hibernation" and ask for a diff based on an older revision. It was a nice system, I never tried to make it "scale" though.
naasking 9y ago
I've built some prototypes like this, predating web sockets though. Web sockets are simply an optimization over standard form submission. The problems of state management are the same though. If your protocol isn't stateless, then you're restricted in how you can manage the server, ie. no live upgrades without breaking all clients.

johanobergman 9y ago

I made a proof of concept for such a framework. There are some really cool benefits (like automatic server side rendering, really small js bundle, all code on the backend etc.) but falls short for things that require immediate response, such as drag/drop, or text input.

tim333 9y ago

Meteor is a little that way although it doesn't DOM diff on the server. It kind of diffs the Mongo database on the server and then updates mini Mongos in the clients where appropriate. Js in the clients then update the DOMs.

jules 9y ago

Seaside from Smalltalk. To some extent the original ASP. There is also a PHP framework that does that, but I forgot it's name.

Bogdanp 9y ago

Not exactly the same but you might want to check out Ur/Web, Eliom and the standard Racket web server lib.

randomstudent 9y ago

Yes. This Elixir library aims to have a virtual DOM on the server and send minimal diffs to the client: https://github.com/grych/drab https://github.com/grych/drab It can already do this for some kinds of diffs, but it doesn't have a full VDOM yet. It basically allows you to build interactive pages without writing any javascript.

MrBlue 9y ago
Drab is one of the most interesting and impressive libraries to emerge from the Elixir/Phoenix ecosystem.

thinkloop 9y ago

> DOM diff-ing on the server and have the thin client only transfer the changes. This would hopefully make the initial payload extremely small and the changes being transferred minimal as well. To achieve similar results, you could granularly partition the build so that scripts are lazy loaded as needed. This would be like sending diffs, except only once since the client can reuse them. Having a server manage the DOM state of every client, and maintaining sockets between them, seems like a complex apparatus.

noway421 9y ago

Like an X Server for the DOM? While interesting, that means that every communication would need to be tranfered to the server and there'd be no instant one-frame actions. That fits a limited set of UIs. And would lag with substantial network latency

pjmlp 9y ago
I once saw a company that had a product which was basically JSF as network protocol for Swing.

rlander 9y ago

N2O[0] does exactly that. You write your app in Erlang and the framework delivers the changes via websockets to the browser. You can even choose to have the changes computed in the browser through an Erlang -> Js bridge. Pretty cool. [0] https://github.com/synrc/n2o https://github.com/synrc/n2o

andy_ppp 9y ago
This looks great, I'll try it out!

jerf 9y ago

"I'm wondering if there is a more holistic approach." The end game, once WebAssembly is fully integrated into the browser, is to expose the 3D API and/or a high-performance low-level 2D API (or both) and slowly, but surely, a "web browser" will become an environment where you download a full rendering engine for a website, written in an arbitrary language that has WebASM support, and in the end both DOM and JS will become merely another option, at which point IMHO neither of them will actually fare very well, excepting their substantial existing install base. Caching will make this feasible as most of the "long tail" isn't going to make their own engine, just use someone else's, and there aren't really all that many sites who can afford to write their own. While I consider the forces pressing on the browser to virtually predestine this outcome, it is at least 10 years off. (If it wasn't for the fact that Javascript is still not fast enough to pull this off, I think we'd already see more frameworks that do layout and ship down a lot more divs and such with hard-coded absolute positions, turning the browser into an environment where it simply puts text and images where the server tells it to, and stops doing all this expensive reflowing and layout. You can see on all kinds of sites the desire to do this on the part of web publishers. However, it is impossible to do this on the server side because you need access to font metrics (where you may not be able to force your own), screen size info, browser zoom level, and a whole bunch of other such things that make it impractical to do server-side in a whole bunch of ways. But JS is still at least ten times slower than native code here, plus would take an inevitable penalty accessing a lot of FFI code, so this is currently almost unthinkably infeasible on the client side.)

jpfed 9y ago
James Mickens presents something like this idea: https://www.youtube.com/watch?v=1uflg7LDmzI https://www.youtube.com/watch?v=1uflg7LDmzI
- jerf 9y ago
  Yes, I had the pleasure of seeing him present that live once, though not at that one. I think he was disappointed that people weren't helping him work on it, but I still think that long term the pressures are absolutely inevitable in that direction. It's just that the world at large can't jump there in one shot, it has to get there one very laboriously-worked-out technology at a time first. He's gotten a bit more famous for his sense of humor, but I can attest that he knows his stuff.

mbrock 9y ago

I once wrote an app that worked by sending diffs, not DOM diffs but JSON diffs which were then applied by the client and rendered by React. The data store was a repository, and so a client could ask "please give me the diff between states X and Y", and the server would make a diff between those trees in the repository. Most of the time the client would be long-polling for a new revision with the diff based on the previous one, which could be cached efficiently, but sometimes a client would come back from "hibernation" and ask for a diff based on an older revision. It was a nice system, I never tried to make it "scale" though.

naasking 9y ago

I've built some prototypes like this, predating web sockets though. Web sockets are simply an optimization over standard form submission. The problems of state management are the same though. If your protocol isn't stateless, then you're restricted in how you can manage the server, ie. no live upgrades without breaking all clients.