The one question I had that wasn’t answered in the video is: If the network is cleanly abstracted away, and not even visible in the code, how is network error handling achieved?
I’d imagine that (p/server foo) returns the equivalent of (using a rust like syntax) Result<type_of(foo), NetworkError>. At least that’s how I’d design this if I was designing this.
You’d have to be extremely disciplined to avoid falling into the trap of mixing presentation and business logic: what happens if you’ve built a web UI this way and then your product manager says, “We need a mobile app?”
One compelling thing about this is that it seems like end-to-end automated tests become easier: you can run both sides of the stack in the same local process and inject events into the DAG to simulate user behavior.
It’s often bothered me that a hard-and-fast distinction between frontend and backend is a de-facto organizational reality of so many software shops that produce some kind of webapp. I have a good understanding of both frontend development in the javascript ecosystem and many types of software whose ultimate output is HTTP responses, and I’ve written both of those kinds of software at various points in my life. But I’ve always seen them as just different instantiations of the general craft of software development - a browser is a slightly different runtime than a unix system but they’re still runtime systems, using a websocket to send a request and asynchronously get a response back from a server is not so different from spawning a unix process and asynchronously getting a response from it, etc. So the idea of having your compiler take care of the messy details of splitting a unified codebase between server-executing sections and browser-executing sections is very appealing to me.
The problem with is it’s such a compelling idea at first, but there’s a lot of things people like their UIs to do that is very difficult to express this way, and shoe-horning those things into this currently-popular paradigm becomes real ugly real quick. You can see it breaking down in React wherever you encounter Context and portals, for example.
Clojure or similar is probably going to be less painful for this than most JS implementations though, because of better support for metaprogramming in ways that would (in JS) require inscrutable magic.
React offers very little in the way of state management for anything complex, because it’s more of a library than a framework & state management is ‘out of scope’.
Anything involving complex (deeply nested) state being updated.
This idea is very compelling.
The one question I had that wasn’t answered in the video is: If the network is cleanly abstracted away, and not even visible in the code, how is network error handling achieved?
How are errors usually handled in clojure?
I’d imagine that
(p/server foo)returns the equivalent of (using a rust like syntax)Result<type_of(foo), NetworkError>. At least that’s how I’d design this if I was designing this.A very interesting idea!
You’d have to be extremely disciplined to avoid falling into the trap of mixing presentation and business logic: what happens if you’ve built a web UI this way and then your product manager says, “We need a mobile app?”
One compelling thing about this is that it seems like end-to-end automated tests become easier: you can run both sides of the stack in the same local process and inject events into the DAG to simulate user behavior.
It’s often bothered me that a hard-and-fast distinction between frontend and backend is a de-facto organizational reality of so many software shops that produce some kind of webapp. I have a good understanding of both frontend development in the javascript ecosystem and many types of software whose ultimate output is HTTP responses, and I’ve written both of those kinds of software at various points in my life. But I’ve always seen them as just different instantiations of the general craft of software development - a browser is a slightly different runtime than a unix system but they’re still runtime systems, using a websocket to send a request and asynchronously get a response back from a server is not so different from spawning a unix process and asynchronously getting a response from it, etc. So the idea of having your compiler take care of the messy details of splitting a unified codebase between server-executing sections and browser-executing sections is very appealing to me.
That seems like full-stack web development to me. I don’t think it’s all that rare in the wild, though probably more common at smaller shops.
How is this different from Meteor? Meteor made the same general promise, but it definitely seemed to have failed. Why do we think this won’t?
The problem with is it’s such a compelling idea at first, but there’s a lot of things people like their UIs to do that is very difficult to express this way, and shoe-horning those things into this currently-popular paradigm becomes real ugly real quick. You can see it breaking down in React wherever you encounter Context and portals, for example.
Clojure or similar is probably going to be less painful for this than most JS implementations though, because of better support for metaprogramming in ways that would (in JS) require inscrutable magic.
What’s an example of something difficult to express? I’m not familiar with React; I have used Elm and written a few games in FRP style.
React offers very little in the way of state management for anything complex, because it’s more of a library than a framework & state management is ‘out of scope’.
Anything involving complex (deeply nested) state being updated.