Back-end languages are coming to the front-end

I&#x27;m surprised this wasn&#x27;t about WASM.<p>Either way, I&#x27;m receptive to the &quot;LiveView&quot; model, but until such a time a server can deliver both HTML and server driven native UI for mobile interchangeably, I prefer the RPC approach.<p>I don&#x27;t want to develop:<p>1. Both an API for mobile and LiveView for web.<p>OR<p>2. Create my own server driven UI paradigm for mobile.<p>I find maintaining one architectural pattern simpler. I do want to support users with the best technology fit, but I don&#x27;t see why I have to make this tradeoff. The platform holders are (and always have been) jerking us around.<p>I want to see a LiveView that can deliver both HTML and equivalent native UI markup. This is needed to sell the vision end to end - the world is not just web.<p>I feel like this would enable a more sensible choice:<p>Offline (first)? Use RPC with sync.<p>Online-only? Use the LiveView paradigm and it&#x27;ll work with native or web.

What&#x27;s incredibly frustrating about the knocks on JavaScript is that it&#x27;s not a shortcoming of the language that creates the problems hinted here, but the poorly-considered engineering choices of the popular frameworks.<p>After building my own framework [1] last year, I realized just how disconnected JavaScript developers—yes, the &quot;big boys&quot; are especially off in CS la-la land—were from web development fundamentals. HTTP distilled down to its absolute essence is brilliant, but for some reason gets absolutely ignored in the JS world. When you couple that with websockets for incremental updates (similar to what Chris McCord is doing in Phoenix), it&#x27;s insanely powerful. It can be reasonably lightweight, too, if you&#x27;re only shipping the JS you need to render the page.<p>That rendering some HTML, CSS, and interactive JS in a browser has been turned into what it has is staggering. Though, not surprising, when you realize a lot of the momentum in JavaScript the last decade or so was perpetuated by venture capital (and the inevitable fast and cheap nature of that world) being pumped into inexperienced teams.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;cheatcode&#x2F;joystick" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cheatcode&#x2F;joystick</a>

Funnily enough, PHP (like, old school PHP) is a surprisingly neat fit for this style of programming when combined with htmx[0]<p>Tiny amount of glue HTML attributes, a heap of partials that are your PHP files and you’re good to go.<p>What is old is new again I suppose: we used to do this with PHP and jQuery once upon a time too — though LiveView and similar are far nicer of course.<p>I’ve been working on some personal tools with nothing more than Deno and htmx. Works quite well for my needs!<p>[0] <a href="https:&#x2F;&#x2F;htmx.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;htmx.org&#x2F;</a>

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&#x27;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&#x27;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. &quot;Can we create a widget that does X?&quot; &quot;Ughh let me take a look.&quot;. 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&#x27;s why when things like Blazor and LiveView roll around I get flashbacks akin to post traumatic stress disorder.

Chris McCord, quoted in the article, explains extremely well the absurd state of stateless http requests, from a perspective that is not appreciated in the article (queued to 40m50s):<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=XhNv1ikZNLs&amp;list=PLqj39LCvnOWYTNs1n3ZNMSNO3Svv_XweT&amp;t=40m50s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=XhNv1ikZNLs&amp;list=PLqj39LCvnO...</a><p>The programming model (in liveview, don&#x27;t know about blazor or hotwire or livewire) really lets you get better performance by doing less. A part of me sarcastically thinks wow, damn, deleting data is irreversible data transformation and therefore increases entropy, every stateless http request is inching us closer to the heat death of the universe.

See CLOG, the Common Lisp Omnificent GUI - a recent project which is an implementation of this paradigm.<p><a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;lisp&#x2F;comments&#x2F;s1itqi&#x2F;the_common_lisp_omnificent_gui_online_lisp&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;lisp&#x2F;comments&#x2F;s1itqi&#x2F;the_common_lis...</a><p><a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;lisp&#x2F;comments&#x2F;sd9wf1&#x2F;clog_builder_cl_web_3_awesome_lang_awesome_tool&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;lisp&#x2F;comments&#x2F;sd9wf1&#x2F;clog_builder_c...</a>

I just shipped my fourth large project based on Phoenix LiveView and I think it is the best thing that happened to web dev since forever.<p>The javascript is minimal (like to manage selection in text field or to handle copy&#x2F;paste). Everything else is in elixir. Tailwind is used for CSS.<p>Having the full client state available on the backend is really incredible. It is so much easier, no more ajax&#x2F;graphql... You just have all your backend data &quot;under your fingers&quot;.<p>I can only recommend giving it a try.<p>Also, if your app is offline first, phoenix channels are great for sync. It is not live view, but it is easier to use than ajax calls.

Initially, I thought this was going to be about WASM, based on the title.<p>&#x2F;&#x2F;<p>The thing about rendering and processing things server-side and relying on very little, if any, JavaScript is that it makes it possible to send very small amounts of data to the client but still handle demanding tasks.<p>There&#x27;s something to be said for making a website usable for even the most anemic of client hardware.

I remember JSF (Java Server Faces) and GWT (Google Web Toolkit). Both burned in flames.<p>JSF: main idea is to abstract away boundary between server and client. Turns out -- you really want to know where that thing is running -- on the server or on the client. So it turned into a fight against that main idea of JSF.<p>GWT: main idea is to forget JavaScript&#x2F;DOM and write pure Java. Turns out -- you really need to know JavaScript and your DOM to write GWT. So it turned into a fight against that main idea of GWT.

There is not BE or FE lang. The browser (the universal VM) just only takes JS and WASM at the moment. So they can be considered browser NATIVE.<p>TypeScript is not native. Is it then also a BE lang?<p>What is happening here is a big rift in the programmers community between the &quot;I&#x27;m productive in it so it is great&quot; and the &quot;I prefer to use strong typing and proofs to ensure it does not break at runtime&quot;.<p>And the second group has managed to compile more-and-more of it&#x27;s langs to JS and WASM.

There are 3 different kinds of web applications:<p>* smart front end, dumb back end. This is the SPA model * dumb front end, smart back end. This is the old school model * smart front end, smart back end. This is the new school model<p>If you can get away with the SPA model, by all means do it. Liveview is not going to challenge that. What it is doing, is to give new live to the old school model so you can avoid the complexity of having both a smart front end and a smart back end for a large percentage of applications. A smart&#x2F;smart system is an asymmetric distributed system, a beast to handle for gurus and novices and everyone in between.

The article actually left out one of the oldest frameworks for doing this:<p>Wt<p><a href="https:&#x2F;&#x2F;www.webtoolkit.eu&#x2F;wt" rel="nofollow">https:&#x2F;&#x2F;www.webtoolkit.eu&#x2F;wt</a><p>It uses C++ to program a back-end application kind of like you would with with Qt, and then it does all the required Javascript&#x2F;HTML to render your app in the browser. It is kind of like Qt for the web (painting with a very, very broad brush).<p>I have also tried wasm with various Rust frameworks (Seed and Yew).<p>However, for my latest project (triviarex.com) I ended up abandoning those in favor of React Javascript, however with a non-traditional architecture.<p>The downside of these frameworks for me was tooling and turn around time and integration. React has great tooling, and it is easy to do live coding. In addition, there are a lot of pre-built components for Javascript frameworks and a ton of documentation.<p>While there can be live coding with the backend, I guess because of my background, I like to use strongly typed languages in the backend to help catch logical errors earlier, and that requires a compilation step.<p>So this is the architecture pattern that I am using.<p>My backend is written in Rust in Actix, and each session is represented by an Actor. The React front-end establishes a web sockets connection to the actor, and sends commands to the actor, which are then parsed by the backend using Serde JSON, and handled using pattern matching. All the state and state transitions are handled on the backend which then sends the frontend a Javascript serialization of a Rust enum that describes what the state is, and what data is needed to render. The front-end basically has a series a if-else statements that match against the state and renders it. Most logical processing lives on the backend, and most of the buttons simply just send a web socket message to the backend.<p>For me, this is the best of both worlds. I get the strong typing and correctness of Rust in the backend to manage the complexities of state management, and I get the flexibility and live coding of Javascript and React on the front-end to quickly and interactively develop the UI. Many times, I will be testing and see that the formatting or placement looks off, and I just quickly change the html&#x2F;css&#x2F;javascript and have it instantly appear.

Not seeing ClojureScript in there... feels a bit weird... One would think, CLJS is more or less, back-end lang brought to front-end

It&#x27;s almost like what some of us did 15 years ago, use just enough JS to load things into the DOM fetched from the backend via XMLHttpRequest, is news now. Having a Websocket open to the backend and using a front end that&#x27;s aware of that instead of using HTTPS seems to be the major difference here. That difference is more about WebSockets existing now than about the choice of backend language or the server-rendered, frontend-refreshed display model.

I love Blazor and I think this concept of using one language to write the front and back-end will be the standard way of doing SPA.

Not mentioning ClojureScript in an article like this is an odd omission.

What does that bring to the table though? You&#x27;ll still need to write html, css and javascript (or some dsl).<p>As a hobbyist Python dev who doesn&#x27;t want to deal with frontend bs more than absolutely needed, I found my perfect stack - fastapi, svelte and tailwindcss.

I couldn’t care less about the actual language. What I do care about is not having to maintain two separate tool chains and package managers, one for backend and one for front end.

Javascript on the server-side has gone from something that was advised to never be used in production. Now it is so ubiquitous that people are trying to replace it with something new and more strict and less freedom... I am fan of modern javascript, I don’t complain or mad about the fast rate of change and improvement in the language. I kept up with all the latest javascript tools and now can build full-stack applications on mobile and web with very similar codebases faster than ever.

I&#x27;ve been looking for this for a long while.<p>I am surprised that there are no browsers that can support other languages. My ideal architecture is to have a browser where you can select your front-end language interpreter, as in a Chromium + V8 + CPython + Whatever front-end processor you might want (Brython[0] achieves this, but transpiling to JavaScript).<p>What doesn&#x27;t make sense to me is that JavaScript has genuinely been the only language for the front-end, and it has been a monopoly for many years. Of course, there are other great languages like TypeScript, but these end up anyway transpiled to JavaScript, which to me feels like mounting your skyscraper over dunes. Not to hate on JavaScript, but JavaScript has grown too quirky for my tastes and that&#x27;s why I&#x27;ve been away a lot from front-end development.<p>There are efforts to fix it, with the new ECMA standards, but I don&#x27;t feel it&#x27;s going anywhere unless breaking changes are introduced to modernize the language. The fact that you have to &quot;patch&quot; your scripts with &#x27;strict mode&#x27; on the top of the file speaks a lot of being defensive with programming.<p>WASM is a solution to this, except you&#x27;re not supposed to write WASM yourself. I want web development to be more straightforward, like the old days, where you didn&#x27;t have to &quot;compile&quot; or &quot;package&quot; anything, and you just did your thing, and that worked.<p>--<p>[0]: <a href="https:&#x2F;&#x2F;brython.info&#x2F;" rel="nofollow">https:&#x2F;&#x2F;brython.info&#x2F;</a>

We use Liveview exclusively for our app (<a href="https:&#x2F;&#x2F;www.grilla.gg&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.grilla.gg&#x2F;</a>) and I&#x27;m happy every day we can build stuff like this with very minimal javascript. Happy to answer any questions about what it&#x27;s like to run a startup using liveview.

I would love to see Python running natively in the browser and to be able to use Python instead of JavaScript.

I would like something explained to me.<p>When webapp logic happens on the client side, that results in slow applications (n.b. for normal users on low-end hardware, not developers on high-end hardware) due to CPU costs.<p>When webapp logic happens on the server side, that results in slow applications (n.b. for users on unreliable residential, mobile cellular, or rural connections, not those living with fiber) due to network latency.<p>Doesn&#x27;t Liveview (and related techs) simply make the slowness a stronger function of internet quality (as opposed to available processing power), instead of actually making the application less dependent on <i>either</i> of those factors for performance?

I&#x27;d love to see this approach make more headway in the Django community. Based on the last DjangoCon it seems like the community is coalescing around HTMX.<p>This tool does play very nicely with Django&#x27;s templating engine; you can just have HTMX re-render a particular template block on the server, and send down that updated block. The migration path is quite clean; you just wrap your &quot;HTMX-updated&quot; template block in a `hx-post` div.<p>Having not gone too deep on HTMX, I&#x27;m interested in folks&#x27; thoughts on where it&#x27;s lacking vs. LiveView and Hotwire. One area I can see is performance; Elixir is going to be faster than Django, and so if you&#x27;re trying to handle high session counts over websockets. But the impression I get is that HTMX is a bit more light-weight, so I&#x27;m wondering if there&#x27;s usecases that can&#x27;t be met with it vs. LiveView.<p>Other Django libraries that haven&#x27;t quite seen as much uptake:<p>We have <a href="https:&#x2F;&#x2F;github.com&#x2F;edelvalle&#x2F;reactor" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;edelvalle&#x2F;reactor</a>, and a port of Hotwire: <a href="https:&#x2F;&#x2F;github.com&#x2F;hotwire-django" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;hotwire-django</a> but both of these don&#x27;t seem to have much adoption (yet!).

I do not usually write front-end but when I do I use <a href="https:&#x2F;&#x2F;www.scala-js.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.scala-js.org&#x2F;</a>

From a costing perspective,<p>- hosting a web sockets server is expensive<p>- bandwith is cheap<p>- client cpu is free<p>So a lightweight, modern SPA wins in this case

I don&#x27;t think this is really about programming languages. The world of software (and specifically everything network based) is oscillating between fat servers and fat client every few years or so. To me the innovation seems to be orthogonal to this cycle and may actually be accelerated by this continuous change in perspective. Which is good!

Can anyone clarify what this quote refers to: &quot;what really sets Erlang apart, for McCord, is its ability to preschedule processes so that the CPU doesn&#x27;t get hung up on any single thread.&quot;<p>What&#x27;s this concept called? Is it simply a matter of setting a priority level on a certain task, that way the scheduler can make sure it doesn&#x27;t block?

Why no words about WebAssembly&#x2F;WASM?

I keep waiting for something better than js&#x2F;ts to do frontends so I dont have to learn it. I&#x27;m still waiting... I thought wasm would have gotten further along by now.

Ha. WASM with QtCreator and Qt w&#x2F; C++ would have put a decade of web developers out of a job had it launched in 2010. Most amusing about front end is that stuff like flexbox, nice animations and GPU-accelerated graphics based on web tech get praised and hailed as innovation yet we had that stuff on the desktop for years and years already way before the web bros rediscovered everything 2010-2020.

Funny to see these new incarnations of the old ASP.NET UpdatePanel. I despised WebForms back in the day, but always had a soft spot for the UpdatePanel, seemed like a great idea. Especially when the alternative was manually building and managing UI on the client using ASP.NET AJAX.

I am not a fan of these things. Much like big JavaScript frameworks whenever you need to do something outside of the mechanisms they provide things become very difficult very quickly and you still need to use JavaScript, HTML and CSS anyway as others have pointed out.

I&#x27;m working on something like this: <a href="https:&#x2F;&#x2F;nexusdev.tools&#x2F;" rel="nofollow">https:&#x2F;&#x2F;nexusdev.tools&#x2F;</a><p>Designed to support multiple back-ends and front-ends. The first back-end will be Nim and the first front-end will be Flutter.

Any thoughts on anvil? It’s a full-stack python framework. I think it features a python to js transpiler:<p><a href="https:&#x2F;&#x2F;anvil.works&#x2F;blog&#x2F;client-side-python" rel="nofollow">https:&#x2F;&#x2F;anvil.works&#x2F;blog&#x2F;client-side-python</a>

Anyone have good experiences with a LiveView-style Python framework?

How does this approach compare&#x2F;differ from using something like mighty app where you stream a video to the ui and take gestures to the server?

What is this GitHub.com&#x2F;readme special alias? I hate it. Very annoying presentation format and it breaks the GH URL structure consistency.

This is a neat result of scope creep.<p>The race between web C#&#x2F;python and local javascript could make becoming a &quot;full stack&quot; dev easier at least.

Have I interpret well? It&#x27;s like a kind of virtual dom put on server-side? What a bad idea, please don&#x27;t do it!

Not one mention of Java server faces (JSF) ?

I don&#x27;t really get the terminology of &quot;backend&quot; and &quot;frontend&quot; languages. To me, JavaScript is just a dialect of C anyway and the browser is just an OS. It doesn&#x27;t make any sense to specify any particular usage except to acknowledge that for frontend development, JavaScript is the most popular choice. And so what? Most frameworks (like Angular) are heavily-based in patterns that came from other languages.

Why not just deploy X windows and run the browser on the server as well?<p>(Pun semi-intended)

Backend languages came to the frontend with Unity and Silverlight..

Yes please; everyone who hates Javascript needs this so bad.

How do these tools work? Are they like ASP.NET Webforms?

Not to mention streamlit, gradio, plotly for Python :)

or you could use ruby on the backend and javascript on the client

No JSP love for Java.

I remember GWT.

When is the world of software going to wake up? All programming languages suck, in one way or another. All frontend&#x2F;backend paradigms suck, in one way or another. This constant churn of new, new, new is a waste. It gets replaced every few years, meaning all the time, effort and money sucked into it is gone. And engineers re-learn the same lessons over, and over, and over again. All so software engineers can be happy, because they just like doing new things in newly complicated ways. It&#x27;s like changing how we build houses every few years just for fun, with no benefit to the people eventually living in that home. We&#x27;re definitely not saving them money or building them any faster.

Would love to see Kotlin (more) on the frontend<p>Its a nice language all around on backend (and i suppose mobile, but i wouldnt know) thats a pleasure to code in

Kotlin js (ts in fact) allow us to seamlessly share our business logic between the web frontend (offline mode) and the backend