Back-end languages are coming to the front-end • Hacker News Board

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

#271

Post by Heyso » Thu, Feb 10, 2022, 10:49 PM UTC

skydhash wrote: post #228

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…

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…

Well, that is my experience too. My background is game programming school, after first learbing flash, second trimester was about making a game using html/css/js (no pixijs or phaser here). I did find MDN hard to read and preferred W3School. Today however I tend to prefer MDN.

MDN is richer, more exact, more complete. But being minimal is better when you already unfamiliar with basics.

TLDR : MDN pair well with W3School, imo both are fine as they are.

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

#272

Post by addaon » Thu, Feb 10, 2022, 10:59 PM UTC

AprilArcus wrote: post #195

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…

> the second group has managed to compile more-and-more of it's langs to JS and WASM The second group is incentivized to do so, because they still have value to bring. JavaScript 2022 has sucked all the air out of the room in terms of dynamic dispatch, untyped PLs. Compared to Python, Ruby, and Lua, it has better startup time and throughput, and at the end of seven years of pilfering every good idea any of those lang…

Isn't front end software almost defined by latency sensitivity, though? It seems that after logical correctness, there's nothing more important for user experience than bounded and low latency.

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

#273

Post by josephg » Thu, Feb 10, 2022, 11:01 PM UTC

Philip-J-Fry wrote: post #266

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…

How does your framework handle re-rendering large components? E.g. a table with 1000 rows. I can't see any obvious mention of virtual DOMs so I assume you're not using them. You might say virtual DOMs are exactly what you're talking about when you talk about the design choices of popular frameworks. It fundamentally comes down to the idea of writing functional components. I declare exactly what I want my UI to look l…

Virtual doms are a cute idea, but virtual dom diffing will always leave a lot of performance on the table. It’s complex, slow, and entirely unnecessary - especially now we have frameworks like svelte.

It can still work well enough when developers don’t go crazy with divs, and when they use shouldComponentUpdate. But nobody uses that stuff; and modern pages are bloated like crazy.

For my money I think the problem is cultural. Theres a community and culture around frontend engineering now which seems to entirely disregard performance to the throne of closing tickets as fast as possible. Lots of frontend devs I meet at conferences and meet ups have no idea how the browser works, and no real desire to learn. The result is disasters like the new reddit homepage - which needs more horsepower to render smoothly than AAA video games did a few years ago.

The GP is right. There’s an insane amount of performance being left on the table. I don’t think it’s a technical problem. It’s a cultural problem.

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

#274

Post by threeseed » Thu, Feb 10, 2022, 11:04 PM UTC

austincheney wrote: post #259

threeseed wrote: post #254

Earlier quoted context omitted.

> because people don't know how to do it efficiently Of course we do. We just choose not to bother because delivering features efficiently is often more valuable than shaving off a few seconds of download time. Especially when it's typically once off and then cached.

> Of course we do. Apparently not. A few seconds is a really big deal, but that is just download time while you are also clearly not accounting for execution time. Caching code will not save on execution time.

There are always edge cases e.g. running Amazon.

But in most cases execution time is negligible and a few seconds isn't a big deal compared to having more features.

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

#275

Post by deckard1 » Thu, Feb 10, 2022, 11:12 PM UTC

jillesvangurp wrote: post #112

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…

Agreed. Javascript is increasingly something that is optional. You can use it but you no longer have to use it. And even if you are using it, you are more than likely transpiling it. Browser side Javascript is just a compiler target at this point. There are a minority of people not doing any transpilation of course. But at this point that really is a minority (and by no small margin I'm guessing). Nothing against tha…

> Browser side Javascript is just a compiler target at this point

you're a decade late to this observation. CoffeeScript came out around 2009. The world has largely been transpiling to ES5 for at least eight years now.

The fact of the matter is, JavaScript post-ES6 is a solid language. Many of those people that were using ClojureScript/CoffeeScript/etc. have moved back to JS.

2007 JavaScript has almost nothing in common with 2022 JavaScript. I think this needs shouting from the moon, based on the comments I keep seeing on HN. We used to have to use Firebug. On IE we were totally blind. JavaScript was designed to crash silently while still allowing a web page to function. Today, JS is a critical part of most pages and has sophisticated tooling.

> There might still be valid reasons to use DOM + CSS like we have been for the last two decades.

If you care at all about accessibility and general browser standards, then you're stuck with the DOM. You have to reinvent the world each time you decide to make the canvas your entire UI. It's hard enough getting browser history and URLs working and creating the illusion of "pages" in a SPA. I can't imagine the pain in the ass this would be in a WASM blob.

> But it won't be the only choice for doing UIs.

It was never the only choice. Not even in 1996. Macromedia Flash, Java applets, etc. For niche applications, the canvas is great. But the majority of the world will continue using the DOM.

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

#276

Post by mickael-kerjean » Thu, Feb 10, 2022, 11:17 PM UTC

LAC-Tech wrote: post #241

pphysch wrote: post #230

Earlier quoted context omitted.

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

In less than 10 years, being able to recompile a modern projects will be a new kind of jobs, going around legacy version of webpack with legacy version of babel that support some syntax that would have never been made a standard with a spaghetti of deprecated library like axios who only became popular because their users was too lazy to look at the standard.

That will all become very interesting if we start to find some XSS issues in today's major frontend framework

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

#277

Post by Shared404 » Thu, Feb 10, 2022, 11:30 PM UTC

hbn wrote: post #245

mostertoaster wrote: post #239

Earlier quoted context omitted.

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!

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

w3schools style "Let me walk you through every step of the process" probably.

It has it's place, I know I've found it useful in the past, but definitely not a place you want to stay in very long.

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

#278

Post by samhw » Thu, Feb 10, 2022, 11:31 PM UTC

erik_seaberg wrote: post #234

samhw wrote: post #167

Earlier quoted context omitted.

Oh, nice! No, Ada doesn't seem ever to have achieved the same mainstream adoption, or at least awareness, that Rust has. Which is startling to me, because it's comparable to Rust in performance while being far far greater in safety, including inbuilt support for design-by-contract (honestly I feel like I'm shouting at a brick wall trying to get people to understand the benefits of DbC; Rust's type system is only a fi…

Back when I learned Ada it didn’t have a solution for use-after-free, does DbC fix that by expressing ownership and sharing?

There was a thread a while back which covered the various variants of Ada and how their memory management contrasts with that of Rust: https://news.ycombinator.com/item?id=14210258

Basically: no, it likely hasn't changed much since you learned it, unless that was genuinely decades ago. But there are various solutions (or, at least, ideas which are considered solutions, depending on what you consider the problem to be) that you might have missed!

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

#279

Post by polyrand » Thu, Feb 10, 2022, 11:33 PM UTC

ledgerdev wrote: post #231

polyrand wrote: post #214

Earlier quoted context omitted.

The thing about HTMX is that the mental model about state should tend towards "the server is aware of everything". With the added benefit that you can achieve better RESTful URLs that respect the navigation actions. Without having tried this (but having used HTMX quite a lot), I would try the following (let me know if I didn't understand the problem correctly): Checkout has the following URLs, one for each step: * pa…

> 2) If there's a form input at each step, the server needs to store that info and be aware that the user has an incomplete checkout. Now the user is at step=2 and presses the back button, or clicks on the step=1 link. In that case, the server should know the information stored in the point no. 2 above, and return an HTML form with the data pre-filled based on the last state. The problem is that when you press back b…

I see...

What about using hx-trigger="load" for the form? Maybe that makes the browser reload it even after hitting the back button? (Sorry I can't check this right now, just a random idea).

Edit: I quickly tried it (mixing hx-from="#some-other-element" and hx-trigger="revealed", and it seems to be doing the request, but I haven't looked a lot.

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

#280

Post by samhw » Thu, Feb 10, 2022, 11:36 PM UTC

patrec wrote: post #232

ecnahc515 wrote: post #168

Earlier quoted context omitted.

To be fair, there's a bound how much the JIT/interpreter can do for a given language. Lua is a lot simpler, and a lot easier to optimize as a result, compared to JS.

I don't buy that. If you squint a bit, Lua and Javascript are basically the same language. Lua shares many of javascript's peculiarities and warts (strings you can do arithmetic on, all numbers are doubles (originally), arrays are objects are hashtables of sorts, global scope by default etc). Now it's of course true that Lua is less of a mess than javascript, but a) the complexity explosion of javascript postdates V8…

No offence, but have you written any compilers or interpreters? The points that you discuss (all numbers are doubles, strings have arithmetic methods) may be performance concerns for application developers, but they have very little to do with the optimisations you can make as a compiler/interpreter writer.

The only one that's somewhat relevant is 'global scope by default', but this doesn't touch the surface of the issues that make JS hard to optimise, such as the fact that your, say, memoisation of an object property or method may be broken by an `eval` call of an arbitrary runtime value somewhere else in the code (which, due to asynchronicity, could take place at more or less any time from the point of view of your given 'peephole').