Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Back-end languages are coming to the front-end

github.com

Post reply on HN
Print view View original

61–70 of 328 posts

Re: Back-end languages are coming to the front-end

#61

Post by jbandela1 »

The article actually left out one of the oldest frameworks for doing this:

Wt

https://www.webtoolkit.eu/wt

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/HTML to render your app in the browser. It is kind of like Qt for the web (painting with a very, very broad brush).

I have also tried wasm with various Rust frameworks (Seed and Yew).

However, for my latest project (triviarex.com) I ended up abandoning those in favor of React Javascript, however with a non-traditional architecture.

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.

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.

So this is the architecture pattern that I am using.

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.

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/css/javascript and have it instantly appear.

Re: Back-end languages are coming to the front-end

#62

Post by ihateolives »

bsuvc wrote: post #10
throwaway984393 wrote: post #7

When is the world of software going to wake up? All programming languages suck, in one way or another. All frontend/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,…

No offense, but that’s sort of a bitter take on software development and reads like a middle manager who has contempt for software engineers.

No offense, but you have probably not been in software development for 25+ years.

I've been doing web dev for 30 yrs and it's kind of funny to see everyone inventing server side rendering, plain old html and php again. It's a spiral, not a circle and we're a bit wiser and performant this time, but much of it has been done and gone in some way or another.

Re: Back-end languages are coming to the front-end

#63

Post by dbotton »

oschvr wrote: post #29
phoe-krk wrote: post #14

See CLOG, the Common Lisp Omnificent GUI - a recent project which is an implementation of this paradigm. https://www.reddit.com/r/lisp/comments/s1itqi/the_common_lis... https://www.reddit.com/r/lisp/comments/sd9wf1/clog_builder_c...

Unfortunate naming.. "I CLOGed my frontend"

I think it is catchy and saying "I tapped danced my frontend" seems to work for me and reflects the speed of development that CLOG and Common Lisp offer. https://en.wikipedia.org/wiki/Clog_dancing

Re: Back-end languages are coming to the front-end

#65

Post by ihateolives »

ivanmontillam wrote: post #47

I've been looking for this for a long while. 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). What doesn't make sense to me is that JavaScript has genuinel…

I'm really sad that Dart didn't make it as Javascript replacement. It's much better designed language, but didn't get traction.

Re: Back-end languages are coming to the front-end

#66

Post by falcolas »

hfourm wrote: post #27
jack_riminton wrote: post #20

Earlier quoted context omitted.

Agree. Specifically on the point of "clear, documented and maintainable" I think this is where languages such as Ruby (and therefore Rails) shines. Since it was "optimized for developer happiness" ( https://news.learnenough.com/ruby-optimized-for-programmer-h... ) it's more likely to be easier to understand, document and maintain.

Unfortunately in practice, there is so much ruby/rails magic going on that most Rails projects end up in terrible shape. It's kind of a catch-22, and tons of companies have overcome it, but rails by far has the "least long term maintainable" defaults. Good for quick prototypes/small teams but bad for large and scaling teams

> there is so much ruby/rails magic going on that most Rails projects end up in terrible shape

Should check out Java Spring (and for a bonus round, Lombak). So much magic pixie dust spewed around to get around not being able to monkey patch.

Re: Back-end languages are coming to the front-end

#67

Post by ivanmontillam »

ivanmontillam wrote: post #47

I've been looking for this for a long while. 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). What doesn't make sense to me is that JavaScript has genuinel…

To elaborate a bit more, and in my opinion, a web browser provides an essential service, much like the water from the mains or the electricity that powers your home.

Without the web browser engine, no matter which HTML, CSS and JS you write, the fact is it cannot run without it.

What would be great to have is choosing which programming language runs in your browser. It'd be great for me to move away from JS engines like V8 or SpiderMonkey, and be able to run CPython (directly, not transpiled to JS) as my interpreted language. The stack could be HTML, CSS and Python, for example. WASM came to solve part of this, fortunately.

We are missing an excellent opportunity for more powerful web technologies if we don't embrace WASM.

Re: Back-end languages are coming to the front-end

#68

Post by rkangel »

lucasyvas wrote: post #25

I'm surprised this wasn't about WASM. Either way, I'm receptive to the "LiveView" 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. I don't want to develop: 1. Both an API for mobile and LiveView for web. OR 2. Create my own server driven UI paradigm for mobile. I find maintaining one architectural pattern simpler. I do want…

> until such a time a server can deliver both HTML and server driven native UI for mobile interchangeably, I prefer the RPC approach.

I really think this is such a key point and is the main blocker to this sort of architecture for cases where you need to support all the platforms.

That said there are a lot of web applications that just need some form of UI and don't need full multi-platform support and LiveView type systems involve many fewer pieces to get going with. I'm thinking more here about company internal tooling for whatever purpose, rather than web services provided to customers which are more likely to need mobile apps.

Also, let's say you've already created your backend in Elixir (e.g. using Phoenix for GraphQL or JSON), and have built your mobile app against it. To implement your web frontend, is it easier and better to roll a whole JS app from scratch or just interface with the APIs that already exist locally to produce a LiveView app? Obviously there are some app characteristics that dictate this, but for a lot of things LiveView is still going to be easier. But then, maybe I'm biased because I dislike frontend programming!

Re: Back-end languages are coming to the front-end

#69

Post by riwsky »

rashkov wrote: post #60

Can anyone clarify what this quote refers to: "what really sets Erlang apart, for McCord, is its ability to preschedule processes so that the CPU doesn't get hung up on any single thread." What'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't block?

Preemptive scheduling, as opposed to cooperative scheduling.

Basically: the scheduler can interrupt an erlang thread at any time, instead of a depending on threads to cooperate with the scheduler to see if they should stop. In go, for example, goroutines will only check with the scheduler at function calls, selects, and a few other things like that.

Re: Back-end languages are coming to the front-end

#70

Post by funcDropShadow »

lucasyvas wrote: post #25

I'm surprised this wasn't about WASM. Either way, I'm receptive to the "LiveView" 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. I don't want to develop: 1. Both an API for mobile and LiveView for web. OR 2. Create my own server driven UI paradigm for mobile. I find maintaining one architectural pattern simpler. I do want…

As always, this depends on the use case. For in-house applications it is often far simpler to keep a lightweight frontend and mobile app is often of no concern. For these kinds of web application a server-heavy architecture was always a good choice.
Post reply on HN