Around 15 years ago I needed to build an internal app for my company that would aggregate and display a lot of data. Our backends were all in Java and I had sour taste for JavaScript from a previous project so I looked around for an AJAX framework that would allow me to avoid writing any JavaScript. Lo and Behold there were actually 2 viable ones on the market: Google GWT and Echo2. I played with both of them and Echo2 blew me away. It looked and acted better than anything else on the market at the time. Rich widgets, translucency, works in (almost) any browser, etc. I rolled an app with it. The mechanism of operation was pretty similar to LiveView except WebSockets didn't exist at the time so it worked by having a super thin JavaScript client that polled the web server on the regular basis. So yeah, a bit chatty but for intranet app I didn't care much. Everything worked and felt like it was a Java Swing app but in a browser. The app became popular and we started writing extensions to it and adding modules. Then inevitable customization came. "Can we create a widget that does X?" "Ughh let me take a look.". This is when my nightmare began. Writing a new widget for this thing required putting together some utterly nightmarish JavaScript code and then compiling it together with equally nightmarish piece of Java code. If you had any custom stylesheet you basically were screwed. So roughly 2 years down the road from starting the project I started rewriting it in pure JavaScript and ExtJS (now called Sencha), which was one of the first few juggernaut frameworks for writing SPAs circa 2007-2008. That's why when things like Blazor and LiveView roll around I get flashbacks akin to post traumatic stress disorder.
I remember when Sencha came on the scene :) WebSocket's help for more efficient bidirectional comms and guarantee load-balanced process placement, but LiveView can also be used with long polling if folks have a hard requirement. We also have much better DOM apis for things like efficient diffing/patching that I'm sure you lacked back then. Were you keeping stateful "widgets" on the Java side or hydrating from client state for interactions?
>We also have much better DOM apis for things like efficient diffing/patching >that I'm sure you lacked back then
Oh I hope so. I marvel at React virtual DOM magic on daily basis so I'm sure it can be all done a lot more efficiently these days.
>Were you keeping stateful "widgets" on the Java side or hydrating from client >state for interactions?
IIRC it was 90% on the Java side. The default polling rate was something along the lines of 200 ms. So if you clicked a checkbox on the front end, it would perform the animation for clicking it on the front end but it wasn't considered checked until the backend was informed of it and signed off on it. In Java code if you had a listener for onClick you would write a normal Java method and it would get invoked normally with access to all your server stuff. As you can imagine, Echo2 server session objects could get pretty heavy. Reminded me a bit of mainframes and terminal clients lol :)
