I am in the same boat as OP. Started doing web things right around the growth of rails, but spent plenty of time in my career doing Spring MVC apps. For the last 6 years or so I've been forced to build SPA's because its what's been mandated from on high, but it's to the point where I can't even explain to new devs coming in what they're missing. They can't understand how much easier it is to just make a query directly to a database while responding to a request than it is to concern yourself with explicit API calls onMount of some component. Rehydration, state management, blah. What are we even trying to solve anymore.
I'm excited by the new trend in a sort of hybrid approach where you write your code as if it all runs on the server, and the framework figures out the websocket communications that need to take place. Phoenix Livewiew, PHP Livewire, even Microsoft Blazor server. This is all admirable, but I think the hyperfiddle/photon solution is finally the right level of abstraction. It's sort of like when you start programming and try to write a parser with a bunch of if statements and it becomes a mess, then you realize that mathematicians figured all this stuff out in a really elegant way that composes and provides just a solid bedrock. We need that level of formality to get us out of the SPA/SSR tarpit.
> then you realize that mathematicians figured all this stuff out in a really elegant way that composes and provides just a solid bedrock.
Can you expand on what mathematicians discovered and how it can be applied to coding? Or does it require a certain programming language? I'm looking at the Hyperfiddle website and trying to understand how these concepts are connected. Thanks!
He's basically paraphrasing Greenspun's Tenth Rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
Photon has, by construction, proven that it is possible to define fullstack web UIs as pure functional expressions despite crossing the client/server boundary, and this is done without adding in all that extra "React.js-era web framework stuff" (the travesty being discussed in this larger thread), instead using only the composition semantics of lambda that were established many decades ago. The best explanation of that is this 10 minute talk: https://news.ycombinator.com/item?id=31217448
In particular I was talking about parser/compiler formalizations made in the 50's/60's with the participation of the linguistic community. Kleene stars and their connection to regular languages, the Chomsky hierarchy, pushdown automata and table construction to make efficient bottom up parsers. And the benefits and confidence that these formalizations can provide to the programmers implementing these systems to the point that today, parser generators are an afterthought. No one would try to implement a parser today using a pile of if/then statements or well, those that do will probably find the road to enlightenment after some initial pain and then some googling.
This isn't Math in the sense of numerical computing or solving partial differential equations. But its a better and more natural abstraction to work from. We've figured out the types of graphs we require to express our computations, and we've figured out the language representations that generate those graphs, as well as efficient methods to generate those graphs given an input language and a sequence of sentences. Add to that all the rich developments of type theory.
The Photon/Hyperfiddle thing seems to me to be somewhat similar. It's declarative approach, let the compiler figure out all the cut points and join points, and just stop worrying about it. I'm sure if you looked at their source code, you'd find a lot of code concerned with walking the program tree and coloring different sections, then transforming those sections in a context-dependent way in to something that can run on a server versus a client with well defined interactions.
https://hyperfiddle.notion.site/Reactive-Clojure-You-don-t-n...
I am in the same boat as OP. Started doing web things right around the growth of rails, but spent plenty of time in my career doing Spring MVC apps. For the last 6 years or so I've been forced to build SPA's because its what's been mandated from on high, but it's to the point where I can't even explain to new devs coming in what they're missing. They can't understand how much easier it is to just make a query directly to a database while responding to a request than it is to concern yourself with explicit API calls onMount of some component. Rehydration, state management, blah. What are we even trying to solve anymore.
I'm excited by the new trend in a sort of hybrid approach where you write your code as if it all runs on the server, and the framework figures out the websocket communications that need to take place. Phoenix Livewiew, PHP Livewire, even Microsoft Blazor server. This is all admirable, but I think the hyperfiddle/photon solution is finally the right level of abstraction. It's sort of like when you start programming and try to write a parser with a bunch of if statements and it becomes a mess, then you realize that mathematicians figured all this stuff out in a really elegant way that composes and provides just a solid bedrock. We need that level of formality to get us out of the SPA/SSR tarpit.