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

101–110 of 328 posts

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

#101

Post by lucasyvas »

funcDropShadow wrote: post #70
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.

Of course, this is true. But I prefer architectural patterns that are flexible for future use cases, especially when there's no logical reason why it shouldn't be supported.

You can start this way, but if you have a new requirement, you might reach a technological crossroad and ask yourself "why do I have to add a new paradigm? If the thing I'm already using could just do X, I'd save a shit load of time and/or money."

You can always add, yes. But why do I have to?

The world has treated web and native as separate for far too long. We're really just squabbling over UI toolkits, so why can't we come up with something that just says "Fuck it, we're supporting both native and web as first class in every server framework because that's how it should be. And we're also going to let you use any language in the browser because that's how it should be"

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

#102

Post by wanderer_ »

girvo wrote: post #5

Funnily enough, PHP (like, old school PHP) is a surprisingly neat fit for this style of programming when combined with htmx[0] Tiny amount of glue HTML attributes, a heap of partials that are your PHP files and you’re good to go. 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. I’ve been working on some personal tool…

Call me a heretic: I love PHP.

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

#103

Post by tluyben2 »

cestith wrote: post #51

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

We wrote a framework 15 years ago (almost exactly) that took rendered snippets from the servers and plugged them into the DOM; https://flexlists.com is 15 years old and uses that. It's really fast and was far easier to build with than all the manual jquery stuff. Fun times :) I should rewrite it in Liveview, seems a good fit.

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

#104

Post by hoistbypetard »

tifadg1 wrote: post #32

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

With a similar outlook to yours, I landed on django, htmx and tailwindcss.

I had started down the path of fastapi, svelte and tailwindcss, but when I figured out that htmx let me use server-rendered templates, getting rid of the api and the packaging toolchain felt more ergonomic.

And if you're doing server-rendered things instead of APIs, django has a few more batteries included. (But I really like fastapi for APIs.)

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

#105

Post by rileyphone »

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

Maybe once we lift the abstractions from the clutches of the Von Neumann architecture and reintroduce spatial and sensory mechanisms to our programming environments? Especially with server-client applications, the underlying topologies are often ad-hoc and brittle, which contributes to the complexity in sneaky ways. Jaron Lanier, a pioneer of VR, has a concept of "phenotropic programming" which is almost like OOP taken to the extreme - objects can only sense and act on each other in a virtual world akin to the real one [0].

If you want to really fall down a rabbit hole, Alan Kay has been espousing similar themes for years. He of course was the driving force behind Smalltalk, which did things in the 70s that still seem hard to do. Look at the examples built by middle schoolers in [1] - super impressive stuff! I personally believe OOP got a really bad rap by the bastardizations of C++ and Java, and a principled reframing of it may be what takes us to the next level of programming.

[0] https://www.edge.org/conversation/jaron_lanier-why-gordian-s...

[1] https://www.dgsiegel.net/files/refs/Kay,%20Goldberg%20-%20Pe...

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

#106

Post by sanitycheck »

alisonatwork wrote: post #11
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,…

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…

20+ years here too, and I agree to a large extent.

The conclusion I've come to is that we're making expensive sandcastles. I don't know when I start a project how big the sandcastle will need to get, or exactly what it will end up looking like. I also don't know when the tide is coming in. Some of them were pretty good, others were disasters, but they've all washed away now.

I do quite like building sandcastles though, so I don't worry too much about it.

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

#107

Post by kuon »

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.

The javascript is minimal (like to manage selection in text field or to handle copy/paste). Everything else is in elixir. Tailwind is used for CSS.

Having the full client state available on the backend is really incredible. It is so much easier, no more ajax/graphql... You just have all your backend data "under your fingers".

I can only recommend giving it a try.

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.

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

#108

Post by jvanderbot »

cies wrote: post #77

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. TypeScript is not native. Is it then also a BE lang? What is happening here is a big rift in the programmers community between the "I'm productive in it so it is great" and the "I prefer to use strong typing and proofs to ensure it does not break at runtime". And the second g…

I actually appreciate domain-specific programming languages. It's fine (for me) that JS is the native front-end language. It's fine that Rust targets systems and embedded. I love that Python is a middle ground, and really great backends are built on it. I'm great with C being a really low level language that forces me to think about the machine.

Taking "I'm productive in it so it is great" to an extreme, we end up seeing precisely the kind of domain crossover TFA hints at. Somehow, since Rust is cool, it should be the future of web / in-browser[1]. Somehow, since JS is popular and easy to use, it should be on the james web space telescope[2]. Somehow, since browsers are well accepted, node.js is a reasonable benchmark for embedded systems performance [3]

GTFO with that. That is how we get language bloat and the many overlapping frameworks that creep into the language and make it unrecognizable. I'm looking at you, Tokio and D3.

1. https://leerob.io/blog/rust

2. https://old.reddit.com/r/programming/comments/bglvey/the_9bn...

3. https://jaycarlson.net/embedded-linux/

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

#109

Post by dsego »

ivanmontillam wrote: post #67
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 l…

Agreed, no reason couldn't be . And then all the native APIs would be exposed in a lowest common denominator kind of way.
Post reply on HN