Live data from Hacker News

Back-end languages are coming to the front-end

github.com

51–60 of 328 posts

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

#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, frontend-refreshed display model.

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

#52
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…

If someone took blazor away from me tomorrow, I'd probably consider PHP for a while. The most important part of the programming model is very similar in my experience. I could take a Razor component and convert it directly to a PHP partial pretty quickly.

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

#53
post #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.

Hm.. Good point, My bad.

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

#54

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

The churn keeps me employed :)

[deleted]

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

#55
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…

> 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 used to do the same with PHP + Prototype.js back in 2006-2007 before jQuery existed, including pretty weird hacks for non-AJAX supported browsers (using JS to append from server-side to the DOM).

Surely what is old is new again...

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

#56

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

> Political shifts inside Microsoft could leave it dead and unsupported like Silverlight tomorrow...

I honestly don't see this happening. Beyond the open source arguments, blazor server-side mode is uniquely compelling specifically for organizations like Microsoft where there are thousands (tens of thousands?) of internal business systems that need some way to interact with, but don't necessarily need to serve 4k video traffic to the entire planet.

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

#57
post #41

Earlier quoted context omitted.

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.

Hm.. Good point, My bad.

It's all good. Everything being said, I appreciate efforts like ClojureScript. There is just so much power in being able to use the same language and share the same models on the front and back end, but not all of us want to use JavaScript/Typescript.

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

#58
post #29

Earlier quoted context omitted.

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.

I'd say I Vued my frontend.

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

#59
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):

https://www.youtube.com/watch?v=XhNv1ikZNLs&list=PLqj39LCvnO...

The programming model (in liveview, don'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.

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

#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?

Post reply on HN