Hacker News Reader

Comment by TheEzEzz | Hacker News Reader

> In essence, Haste lets you write your client-server web application as a single, type-safe program, rather than two separate programs that just happen to talk to each other over some web API as is traditional.

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.

View on HN

Ur/Web's [0] pretty obscure but also does this. As does Opa [1].

[0] http://impredicative.com/ur/

[1] http://opalang.org/

Isn't this exactly the idea of the big RPC suites from 10 years ago?

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.

I would argue that GWT is an example of how it can be done, and it's very hard to beat a well-written GWT app (for the client-server part it's bloody hard to beat a badly written GWT app too).

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.

"As programmers we don't explicitly control how our RAM communicates with the CPU; we let the underlying abstractions handle it."

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.

This is a core philosophy of DerbyJS[0]. It even takes it one step further by rendering pages on both the server and the client.

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.

[0] http://derbyjs.com

I think it comes down to two questions:

(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?

I think the main feature haste is providing is Haskell to JavaScript compilation. That will increase your productivity by

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.

(a) Does the abstraction actually lead to productivity gains in the long run, including time spent on debugging a possibly leaky abstraction?

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.

There are enough differences to warrant using different abstractions when appropriate. RAM never fails. Or, it never fails in a way that application code is expected to handle. RAM is cached, and cache is so fast that accessing small amounts of it is often negligible cost, and there's no need to count round trips. RAM is far less likely to be the connection point between different versions or implementations of an application. Are some examples.

Go play with ASP.NET WebForms, then do the same thing in any MVC equivalent. Abstracting away the way the browser and server and HTTP work just leads to painting yourself into a corner where changes that should be quick take waaayyy too long.

Who knows, maybe Haste will be different, but I really don't think so.

Ocsigen does something similar: http://ocsigen.org/tuto/manual/tutowidgets

Maybe this: http://groups.inf.ed.ac.uk/links/

Isn't the result of this class of solutions a service on the web that can _only_ (easily) be accessed by the client code that was specifically written to use that service (by virtue of being built out of the same lump)?

Doesn't that kill one of the best aspects of the web: client independence?

isn' that what GWT is?

What is meteor.js?

https://www.meteor.com/

Reply on news.ycombinator.com