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

241–250 of 328 posts

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

#241

Post by LAC-Tech »

pphysch wrote: post #230
rglover wrote: post #223

What's incredibly frustrating about the knocks on JavaScript is that it's not a shortcoming of the language that creates the problems hinted here, but the poorly-considered engineering choices of the popular frameworks. After building my own framework [1] last year, I realized just how disconnected JavaScript developers—yes, the "big boys" are especially off in CS la-la land—were from web development fundamentals. HT…

> Though, not surprising, when you realize a lot of the momentum in JavaScript the last decade or so was perpetuated by venture capital (and the inevitable fast and cheap nature of that world) being pumped into inexperienced teams. Yep. Frontend frameworks get you a slick looking responsive GUI with not much effort (you are outsourcing most of the design work). This wows the average VC. The VC funds you rather than t…

> Yep. Frontend frameworks get you a slick looking responsive GUI with not much effort (you are outsourcing most of the design work). This wows the average VC. The VC funds you rather than the team with an architecturally simple frontend, and the framework flywheel gains momentum.

And it will stay working as long as you never need to update any of the packages. And then the rapidly changing, highly co-dependent nature of the FE npm ecosystem will bite you in the ass unless you were really careful with your choices - which you weren't because giant megacorps said it was 'best practice'.

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

#242

Post by throw10920 »

I would like something explained to me.

When webapp logic happens on the client side, that results in slow applications (n.b. for normal users on low-end hardware, not developers on high-end hardware) due to CPU costs.

When webapp logic happens on the server side, that results in slow applications (n.b. for users on unreliable residential, mobile cellular, or rural connections, not those living with fiber) due to network latency.

Doesn't Liveview (and related techs) simply make the slowness a stronger function of internet quality (as opposed to available processing power), instead of actually making the application less dependent on either of those factors for performance?

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

#243

Post by austincheney »

throw10920 wrote: post #242

I would like something explained to me. When webapp logic happens on the client side, that results in slow applications (n.b. for normal users on low-end hardware, not developers on high-end hardware) due to CPU costs. When webapp logic happens on the server side, that results in slow applications (n.b. for users on unreliable residential, mobile cellular, or rural connections, not those living with fiber) due to net…

> When webapp logic happens on the client side, that results in slow applications (n.b. for normal users on low-end hardware, not developers on high-end hardware) due to CPU costs.

Its not CPU. Its bad software written by people who are poorly trained and have no leadership.

Do you really need 10mb of JavaScript and 10 seconds of load time to dynamically put a few lines of text on the screen? Yes, absolutely you do, because people don't know how to do it efficiently. This is a people problem, and not a technology problem. Hardware does not solve that problem. The actual technology is actually insane fast. As a counterpoint my personal app loads an OS GUI with state restoration using 2mb of JS code (unminified) in about 150ms.

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

#244

Post by yumraj »

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…

> 1. Both an API for mobile and LiveView for web.

Is that really that hard a problem?

In the other/current model you're building total 3 components: web frontend, mobile frontend and the API and in the liveview model you're again building total 3 components: LiveView for Web front/backend, and mobile frontend and API for mobile backend.

If done properly, the LiveView backend can share a lot of code with the API backend. Moreover, an added advantage is that the Web codebase and Mobile codebase can be different depending on the requirements of the two platforms, except where, as noted above, it makes sense to abstract it out and share. So, IMvHO better software engineering in general.

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

#245

Post by hbn »

mostertoaster wrote: post #239
skydhash wrote: post #228

Earlier quoted context omitted.

Most languages are quite tough to get into. And they require some real learning if you want to do anything trivial. JS is easy to get started (only the browser you already have) and you can do quite a lot without understanding anything about computer science. But it catches to you anyway. I've seen on Twitter someone repelled by the MDN documentation, describing it as not intuitive. I realized that the documentation…

That seems crazy. I feel like MDN documentation is done so well. It balances well between giving good examples, and yet still remaining exhaustive in what it describes. Most extensive documentation ends up being less than useful and I have to fall back to just search results.

I'm legitimately curious what that person expects out of documentation. MDN has basically everything you could want.

Simple explanation, examples in an an editor that can be played with and executed, argument names and explanations, browser compatibility, etc etc etc

Compared to the amount of languages where their documentation is a table auto-generated from code, it's everything I could dream of!

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

#246

Post by lpghatguy »

2ion wrote: post #184

Ha. WASM with QtCreator and Qt w/ C++ would have put a decade of web developers out of a job had it launched in 2010. Most amusing about front end is that stuff like flexbox, nice animations and GPU-accelerated graphics based on web tech get praised and hailed as innovation yet we had that stuff on the desktop for years and years already way before the web bros rediscovered everything 2010-2020.

C++ is not nearly as productive a language for most programmers in the world as JavaScript. Qt is not a panacea, even for desktop apps. The condescending tone to web developers is very strange and not very nice.

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

#247

Post by oraphalous »

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

This. So much this. Futhermore - does it all really matter that much when most of us are stuck with delivery managers screaming: FEATURE, FEATURE, FEATURE in our faces, such that there is never enough time to use any toolset in an optimal way.

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

#248

Post by erik_seaberg »

serverholic wrote: post #170
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…

That rift has existed for a long time. There are some programmers who don't really care what tools they use as long as they feel productive. They shy away from things like types because it feels like it slows them down. Then there are programmers who care a lot about tools because it feels like the wrong tools hold them back and cause undue stress in the long-term. Hot take: The first type are less mature programmers…

I do think some people feel productive writing more code, while others feel productive by finding ways to write less code (with the compiler mostly inferring and generating the error-prone and uncreative work).

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

#249

Post by threeseed »

AzzieElbab wrote: post #217

I do not usually write front-end but when I do I use https://www.scala-js.org/

Best used with any of the following.

Slinky React: https://slinky.dev

Laminar: https://laminar.dev

Diode: https://github.com/suzaku-io/diode

ZIO: https://zio.dev

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

#250

Post by di4na »

throw10920 wrote: post #242

I would like something explained to me. When webapp logic happens on the client side, that results in slow applications (n.b. for normal users on low-end hardware, not developers on high-end hardware) due to CPU costs. When webapp logic happens on the server side, that results in slow applications (n.b. for users on unreliable residential, mobile cellular, or rural connections, not those living with fiber) due to net…

No because network latency is not that big on unreliable connections if the exchange are "small" and relatively "rare".

Which is most applications on the web, particularly with these techniques.

Post reply on HN