Live data from Hacker News

Back-end languages are coming to the front-end

github.com

41–50 of 328 posts

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

#41

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

After reading the article, Clojure would probably be better suited to be mentioned than ClojureScript. The point of it all looked to be speaking to the new paradigm that Phoenix LiveView brings which is server side rendering of subsections of a page. ClojureScript, while being Clojure in a Javascript uniform, doesn't look to be used in that manor.

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

#42
post #29

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"

When would you use the name of a project like that?

"I Reacted my frontend"?

"I AngularJSed my frontend"?

"I VueJSed my frontend"?

I just don't see it.

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

#44
post #27

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

This was my experience with rails (to be fair, some years ago). Each new version reinvented some huge chunk of the previous version with magic all the way down. Basically why I stopped using it despite having invested lots of time.

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

#45
post #34

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

The gist I was able to glean, specifically about Pheonix Liveview, is that all updates on the Frontend and Backend are pushed to the other side via websockets. For the Frontend, this means sending some json payload to the Backend. For the Backend this means either responding to a request or sending out a new update both of which involve sending out a snippet of pre-rendered HTML to replace/update an existing element that was already on page.

The benefit here is that we can get to a place that is almost a SPA without needing to do a whole lot of JavaScript for the Frontend. It also helps that Elixir is built on top of Erlang which gives it a boon to be able to handle a lot of users on one server.

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

#46

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,…

After having been in this industry for 20+ years, I can pretty confidently say the world of software will never wake up. It's just been an endless cycle of adding abstractions, removing them again, using back end languages on the front end, using front end languages on the back end, using relational databases instead of a key value store, using key value stores instead of a relational database, unit tests over integr…

I think it's a maturity thing. I've found myself going from wanting to use cool technology to build whatever to wanting to use boring technology to build cool software.

A few decades of programming has taught me that cool technology inevitably turns out to be janky and annoying and half-finished.

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

#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 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's why I've been away a lot from front-end development.

There are efforts to fix it, with the new ECMA standards, but I don't feel it's going anywhere unless breaking changes are introduced to modernize the language. The fact that you have to "patch" your scripts with 'strict mode' on the top of the file speaks a lot of being defensive with programming.

WASM is a solution to this, except you're not supposed to write WASM yourself. I want web development to be more straightforward, like the old days, where you didn't have to "compile" or "package" anything, and you just did your thing, and that worked.

--

[0]: https://brython.info/

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

#48

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,…

If you can only see the churn and froth, that doesn't mean there aren't great waves to surf; you might just need to paddle out to a better spot. https://remix.run is a prime example. It's new, and better, and simpler.

It's better for new people joining, each cycle brings some improvement over the last typically.

It also equalizes the playing field every few years, you become an expert in the latest new thing as there isn't an old guard. Some new web framework comes along, you can invest in that and become leet, where its very difficult to start new in react today and achieve that.

This isn't to say past experience isn't valuable or helps you adopt things more quickly, can make you cynical about the new shiny and sometimes miss out on the actual improvements, even if small. I

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

#49

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.

I do dearly hope Blazor works out - I would be so happy to never have to deal with the Javascript/Typescript tooling hell ever again - but I'm not holding my breath. Political shifts inside Microsoft could leave it dead and unsupported like Silverlight tomorrow...

Well now it's all on GitHub tho, ain't it? So at least you could in theory pay someone else to maintain it or do it yourself.

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

#50

I don'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!

for liveview, it's not at all about "fat servers"; the overhead of maintaining a socket over erlang is not that much (maybe a few K -- the base erlang process overhead is ~400 words), so you're going to almost certainly be doing better than, say ruby (via hotwire) which isn't really designed from the ground up to hold onto the websocket. By persisting the connection with a stateful system, you're going to be avoiding a whole ton of computation that just gets thrown away with stateless HTTP requests. So it's probably in the end a lighter server than most web backends.

This is the irony, Erlang/Elixir, despite being functional language with less and highly restricted access to stateful side effects, is really FANTASTIC at safely holding onto state and persisting it for the user, and making that model digestible for the developer.

Post reply on HN