It is possible, somewhat, but you get very ugly web api's, because they are 'implementation before contract' instead of designing an api first, and then letting both sides adhere to it.
The problem is that those ancient web api's were effectively javascript windows.forms emulators running on the client getting their calls from the server side. That, of course, sucks, because of the latency. Stuff that actually pulls your program apart into server and client pieces is beautiful.
The problem, of course, is that doing it the right way requires rewriting a compiler from scratch. Doing the "emulate the UI library and hang it behind an RPC" is easy, but sucks.
You get what you pay for.
Except for when we don't, because the underlying abstractions sometimes do the wrong thing. Random paper on cache-optimizing and the hassles thereof: http://research.microsoft.com/en-us/um/people/trishulc/paper...
The challenge is that even the memory abstraction leaks a little, and the network is nowhere near as fast or reliable as the frontside bus: "abstracting away" a 100ms+ link latency and/or nontrivial packet loss means hitting that leak much sooner.
I'd love to find out more about how Haste manages the intersection between client and server since it is capable of existing as a client-side only app. Hopefully it has a well defined API and writing plugins for different sources of data is clear and simple.
(a) Does the abstraction actually lead to productivity gains in the long run, including time spent on debugging a possibly leaky abstraction?
(b) Does controlling these things manually enable you to provide a user experience that is sufficiently better to at least cover the costs of any lost productivity?
For any particular abstraction to be viable the answers need to be yes/no.
For abstracting away CPU/RAM communications the answers are clearly yes/no. But what are the answers for the abstraction that the OP referred to?
1. Enabling you to lean on the compiler when refactoring.
2. Decreasing the time you spend debugging.
The fact that it will split your program into client and server side parts is scary though, and interesting. I'll have to investigate further.
It does if you're able to share libraries between client and server. Writing one module for a particular data structure and using it on both client and server is a huge boon.
Who knows, maybe Haste will be different, but I really don't think so.
Doesn't that kill one of the best aspects of the web: client independence?
I've been thinking about this same idea recently and find it very attractive. As programmers we don't explicitly control how our RAM communicates with the CPU; we let the underlying abstractions handle it. Why don't we have similar abstractions for when a client-side program (CPU) needs to access something on the server (RAM)?
Does anyone know of other tools trying to accomplish this? I'm not a Haskeller but am tempted to dive in just for this feature.