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

81–90 of 328 posts

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

#81

Post by Zababa »

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…

> 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".

I think the opposite, the rift has been healing. It seemed that it was pretty big in the 2010's (Python/Ruby/Perl vs Java/C#/C++) but these days we have TypeScript, Rust, Kotlin; Java and C# are getting better too (type inference), Python and Ruby are getting typechecking.

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

#82

Post by nopcode »

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…

This is what Strada (COMING SOON) is aiming to solve.

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

#83

Post by Zababa »

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…

It's surprising to me that you want to user native UIs for mobile but are fine with web UIs for desktops/laptops. What's your reasoning behind this?

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

#84

Post by lawik »

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.

LiveView? It lets you not write JavaScript. Or depending on your needs, very little Javascript.

Less need for an API-layer and related contracts.

You can still use Tailwind CSS. Works quite nicely.

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

#85

Post by harryvederci »

mstef9 wrote: post #15
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…

I was going to say that I was surprised htmx wasn't mentioned in the article. It's backend-agnostic and extremely easy to use. Drop in Alpine.js and I think you have a really powerful setup without writing any JS. I've been using this with Go[0] and enjoying it. [0] https://github.com/mikestefanello/pagoda

Same here, big fan of htmx!

I use it with lisp-like languages (Clojure, Janet). Those have html libraries that transform datastructures into html.

So it doesn't feel like I'm writing html, while I'm pretending not to use JavaScript. It's glorious.

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

#86

Post by lucasyvas »

Zababa wrote: post #83
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…

It's surprising to me that you want to user native UIs for mobile but are fine with web UIs for desktops/laptops. What's your reasoning behind this?

I think this is just poor phrasing on my part since mobile was top of mind. I'd like to see this work with any native UI that supports an online feature set.

I'd like to see the technology work with HTML or server driven native UI, and let developers decide which UI toolkit is best for their app market.

Since it would theoretically support both, you could incrementally transition as well.

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

#87

Post by lostcolony »

rkangel wrote: post #68
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…

I'll also say, one of the key lifts for LiveView is specifically (unsurprisingly) live updates. That is, server pushes.

Websockets don't really make sense to use as a broad bidirectional communication tool; they're overly complicated for situations you can just open a plain TCP socket to communicate over, and making them a requirement for clients that have no need of them is a poor ask. So as soon as you're supporting a client other than a browser, while still supporting a browser, you already are going to likely want to support two APIs.

Good design will allow you to share your model for bidirectional communication regardless of the connection type, and you can then bake in any updating JS into the Websocket connection via LiveView or similar, while exposing a more normalized socket endpoint for other servers, mobile clients, etc. Even if you end up having to support multiple connection assumptions at a later point (i.e., a Websocket connection for your web client that contains JS, a Websocket connection for a web client being developed by a different team that should just return data, and a plain socket connection for non-browser based connections), the lift should be pretty small.

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

#88

Post by anhner »

ihateolives wrote: post #62
bsuvc wrote: post #10

Earlier quoted context omitted.

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.

If you think this is the same as "old html and php again" then you haven't understood the article.

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

#89

Post by lawik »

DerArzt wrote: post #45
Tarucho wrote: 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…

There is also a bundle of clever implementation which means the templates are aware of what parts are static and what parts are dynamic. So they can send optimized changes, essentially small diffs, for the dynamic parts as they change. Often this means only sending the values for your text input field, not any of the markup for the field.

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

#90

Post by ensignavenger »

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…

I am currently developing sites with Django and DRF, where the client requests what format it wants and the server sends it in the format of the clients choice- a browser would request HTML, in which case the server sends HTML- using htmx. A mobile app might request JSON, or XML or CSV or any other supported format. No need to develop a separate API for web and mobile- its all the same API. DRF makes it very easy.

Now, I haven't dug into Apple iOS dev yet, I know they have some artificial limitations on what an app can receive, but thats an Apple limitation, not a technical one. I'm pretty sure Apple allows an iOS app to receive data over the Internet and render that data within the app? I just need to figure out what format it can be sent it for the app to render it.

Post reply on HN