Interesting approach writing interactive web apps without JS, kinda server-side React

[al6x]

Hi, just want to let you know guys about an interesting approach for writing interactive web apps without JS. It seems like it could be done in Julia too.

Checkout the demos. All done without JS

The demos and the framework itself done in Phoenix Framework, but it should be also applicable to Julia too. The full article https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript

[essenciary]

Ooooh, nice, thanks for the tip! Although, if I understand correctly, it's not that the apps can be built "without JS" but "without writing JS" (JS is auto-generated).

[EricForgy]

You might also find this interesting

https://nextjournal.com/sdanisch/executing-julia-in-the-browser

[essenciary]

Nice!

Being able to translate/transpile/compile Julia to JS would enable some very nice applications. In my Ruby days, I had a lot of fun with Opal (https://opalrb.com). And the same for F#.

I'm more of a WebAssembly skeptic. The demand is driven by a category of programmers which don't want to be bothered with HTML/JS/CSS, without taking into account that WebAssembly as well will raise the same UIs questions. Blazor is well positioned because .NET already has powerful UI abstractions, but most other languages are not in the same boat. And even so, there's still a lot of HTML (or HTML-like) coding involved, JS interop, etc.

[al6x]

if I understand correctly, it's not that the apps can be built "without JS" but "without writing JS" (JS is auto-generated).

Nope. No need to autogenerate JS. The only thing that needed for Browser to display UI is HTML. On the Server the HTML is generated by Julia (or Elixir in Phoenix), then user clicks button - some event happens, and new HTML generated on the Server again by Julia. The Julia Server compares the previous HTML (the Server has to be stateful and needs to remember the last STATE and HTML it sent last time to Browser) and new HTML and finds the DIFF (the HTML diff algorithm could be written in Julia), and then sends a command to Browser how to apply that DIFF to the DOM. There will be some minimal JS, but it all will be static, no need to generate it.

I guess it could be cheated and simplified a little bit for proof of concept demo - it would be inefficient but will work. The Julia Server could be simplified and always respond with full HTML without bothering to calculate DIFF. And in the Browser the React could be used behind the scene to calculate DIFF and apply new HTML in a smart way. Julia server still needs to maintain the State though.

That's one of the beauty of approach - no need to care about JavaScript, it could be done in any language. JavaScript is not needed, the only thing that needed is VirtualDOM (tree traversal and comparison) and it could be implemented in any language.

[tweenietomatoes]

It's my dream to write zero-js web apps(pages whatever)! I don't know why i'm allergic to browser side scripting but i hate it and my brain is kind of refusing to do/learn/plan any kind of browser scripting! However, companies want to cut infrastructure expenses so maybe one day there will be almost no server side scripting maybe even no rest? But HTML is OK i love it.

Thanks for that, someone support this guy. We don't want jscript anymore at all. The only thing in the world that i am racist to is browser side scripting surei am obsessed.

[al6x]

This approach is not about avoiding JS. It's about avoiding working with distributed system and related complexities. It would work just as well with the Node.JS server where app would be written in JS on the Server.

[essenciary]

I had a bit of time and read more about this technique. From what I understood the centerpiece of the technique is a very fast DOM diff system on both server and client plus DOM patching:

Thanks to José Valim’s excellent work on LiveEEx, a template language for embedded Elixir capable of computing diffs, we are able to send only the parts of the page which have changed, and we never send the static parts of the template after the initial render. This allows the browser to receive all static and dynamic parts on mount, then only the dynamic parts that have changed on update. When the browser receives an update of dynamic parts of the page, it computes the HTML from its static cache and performs a minimal DOM patch with morphdom.

I don't think anybody in the Julia community is planning on undertaking the development of something similar to LiveEEx.

Personally, I'm happier to see Julia moving towards WASM compilation. I'm looking forward to building a Blazor like implementation in Genie - feels like a more natural and standardized solution (https://dotnet.microsoft.com/apps/aspnet/web-apps/client).

[al6x]

After thinking about it - agreed. Something like Julia + WASM would be a more universal solution. A little more thoughts about Julia + WASM + something-like React.JS approach.