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

91–100 of 328 posts

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

#91

Post by rafale »

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 don't consider myself very opiniated on tech. But if there is one thing I am adamant about is that strongly typed languages are a must in any project that's meant to grow and last. It's a must to explore, understand and refactoring the codebase while maintaining your sanity. The tooling for dynamic languages is just not there yet.

So it's not a rift as much as the fact that one camp is just plain wrong.

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

#92

Post by mstef9 »

stavros wrote: post #78
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…

PHP, Django, Rails, whatever generates HTML, basically. I also slightly prefer Unpoly.com, because it takes whole pages instead of fragments. This means that if JS is disabled the site just keeps working, though with reloads.

You can achieve full support with JS disabled using HTMX as well. It takes a little more work but HTMX provides headers[0] which you can evaluate on the backend to determine if you should return a partial or not. If JS is disabled, the HTMX headers will be missing and you know it's not an HTMX request.

[0] https://htmx.org/reference/#request_headers

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

#93

Post by hnfong »

rafale wrote: post #91
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 don't consider myself very opiniated on tech. But if there is one thing I am adamant about is that strongly typed languages are a must in any project that's meant to grow and last. It's a must to explore, understand and refactoring the codebase while maintaining your sanity. The tooling for dynamic languages is just not there yet. So it's not a rift as much as the fact that one camp is just plain wrong.

Which camp is plain wrong?

The side that insists on using strongly typed languages for a weekend throwaway project?

Or the side that insists on using dynamic languages for 2000 file projects?

I always see "rifts" as a lack of perspective. One solution is obviously the only best way because they only see their narrow sets of use cases.

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

#94

Post by skocznymroczny »

funcDropShadow wrote: post #79
gumby wrote: post #33

Why not just deploy X windows and run the browser on the server as well? (Pun semi-intended)

Let's take this question serious for a moment. Modern X applications render bitmaps which get shipped over the compositor and the X server to the graphics card driver. That is not a good model for the web, because it would mean the web server has to produce rendered bitmaps, specific for the fonts, window size, and display panel led configuration over the web. The browser cannot even select text or provide a search d…

> because it would mean the web server has to produce rendered bitmaps, specific for the fonts, window size, and display panel led configuration over the web. The browser cannot even select text or provide a search dialog. That is almost VNC.

So not much different than "modern" based apps.

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

#95

Post by bsuvc »

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.

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

You're wrong about this.

You and I see things differently.

You see things as never being new and "plain old X and Y again".

I try to see things with fresh eyes, yet still with the benefit of my 25+ years in the industry. I try not to make assumptions that limit my thinking about something. Some might call it a beginner's mindset, and it has served me well.

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

#96

Post by PaulDavisThe1st »

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.

> I've been doing web dev for 30 yrs

That would be impressive, since Mosaic is only 29 years old at this point :)

I don't thinking people are reinventing server side rendering. Rediscovering it, perhaps. It has always been here, along with plain old HTML and PHP. The modern toolbox of JS-based toolboxes exists for a reason: all the things that you can't do (or can only do very clunkily) with server-side implementations. That hasn't changed.

What people wanted from a web page in 1994 is so utterly different than what many web pages are expected to do now. If it's a spiral, it's one that is spiralling out, not in, as the scope expands significantly.

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

#97

Post by Zababa »

lucasyvas wrote: post #86
Zababa wrote: post #83

Earlier quoted context omitted.

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.

That makes a lot of sense, thanks for the explanation.

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

#98

Post by kevinmgranger »

hnfong wrote: post #93
rafale wrote: post #91

Earlier quoted context omitted.

I don't consider myself very opiniated on tech. But if there is one thing I am adamant about is that strongly typed languages are a must in any project that's meant to grow and last. It's a must to explore, understand and refactoring the codebase while maintaining your sanity. The tooling for dynamic languages is just not there yet. So it's not a rift as much as the fact that one camp is just plain wrong.

Which camp is plain wrong? The side that insists on using strongly typed languages for a weekend throwaway project? Or the side that insists on using dynamic languages for 2000 file projects? I always see "rifts" as a lack of perspective. One solution is obviously the only best way because they only see their narrow sets of use cases.

Indeed. Every single technical choice has tradeoffs. It's just that some tradeoffs are non-issues for narrow use cases.

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

#99

Post by stavros »

mstef9 wrote: post #92
stavros wrote: post #78

Earlier quoted context omitted.

PHP, Django, Rails, whatever generates HTML, basically. I also slightly prefer Unpoly.com, because it takes whole pages instead of fragments. This means that if JS is disabled the site just keeps working, though with reloads.

You can achieve full support with JS disabled using HTMX as well. It takes a little more work but HTMX provides headers[0] which you can evaluate on the backend to determine if you should return a partial or not. If JS is disabled, the HTMX headers will be missing and you know it's not an HTMX request. [0] https://htmx.org/reference/#request_headers

Ah, that's a great idea, thanks!

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

#100

Post by rafale »

hnfong wrote: post #93
rafale wrote: post #91

Earlier quoted context omitted.

I don't consider myself very opiniated on tech. But if there is one thing I am adamant about is that strongly typed languages are a must in any project that's meant to grow and last. It's a must to explore, understand and refactoring the codebase while maintaining your sanity. The tooling for dynamic languages is just not there yet. So it's not a rift as much as the fact that one camp is just plain wrong.

Which camp is plain wrong? The side that insists on using strongly typed languages for a weekend throwaway project? Or the side that insists on using dynamic languages for 2000 file projects? I always see "rifts" as a lack of perspective. One solution is obviously the only best way because they only see their narrow sets of use cases.

"in any project that's meant to grow and last"

I specified what I am talking about. Weekend projects are not even a contention point. People code them in Brainfuck and we all have a laugh about it. It's the stuff that end up at the job that frustrate us where you end up assigned to a 100k (or even just 10k) lines of javascript inferno hell. Because some dev thought he can develop "faster" in Javascript.

Post reply on HN