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

281–290 of 328 posts

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

#281

Post by deckard1 »

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…

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

Right. The group that came up with the concept of a REPL and live in Emacs doesn't care about tools.

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

#282

Post by rglover »

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…

I do use a virtual DOM but I only use it to patch the HTML in the browser (no synthetic events or anything like that). The meat of it starts here: https://github.com/cheatcode/joystick/blob/development/ui/sr....

My focus for v1 is on developer ergonomics and solidifying an API (this will be frozen after v1 with the only changes being additions if absolutely necessary—a component you write today will look identical to one you write in 10 years).

All future major versions will be solely focused on performance and security (my way of saying: I haven't stress-tested renders, but for the time being it will work well for the majority of use cases).

Edit: the lack of mention of how I do it is intentional. The last ten years saw brilliant inventions turned into mush because all of the leading project devs got into an unacknowledged dick measuring contest with one another (i.e., passive-aggressive jockeying for dominance that was ultimately a distraction from building software that was usable).

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

#284

Post by anitil »

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!

MDN documentation and Sqlite documentation stand out to me as some of the best around. The Cloudflare how-tos would be up there, if you stretch the definition of documentation

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

#285

Post by unleashit »

josephg wrote: post #273
Philip-J-Fry wrote: post #266

Earlier quoted context omitted.

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

I love how the new Reddit gets frequently used as a straw man in arguments of front end developers are bad, the state of front end is a mess, etc. If you care to look at the actual reasons that Reddit and so many modern websites really are terrible, you'll see that it comes from the top and in many cases is on purpose.

Reddit (and many others) don't want you to use their website. Especially on a mobile browser. They want you using their app where they have access to more of your data and generally keep you longer. And also where the initial payload of advertising and analytics cruft feels faster to you because you probably are more inclined to be patient with the mobile install/update lifecycle than you'd be with a browser. The GUI changes too were much more likely to come from product management than your lowly front end bootcamp graduate.

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

#286

Post by amatecha »

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.

For real? MDN's documentation is some of the best I've ever seen... Complete, frequently-updated documentation of all Web APIs including comprehensive examples of typical usages with clearly-worded explanations! It also links directly to the actual ECMAScript specs that define what the documentation is describing. I mean, how could it get any better?

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

#287

Post by giantrobot »

mavelikara wrote: post #233
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…

> I realized just how disconnected JavaScript developers—yes, the "big boys" are especially off in CS la-la land—were from web development fundamentals. HTTP distilled down to its absolute essence is brilliant, but for some reason gets absolutely ignored in the JS world. Can you please elaborate what these areas of disconnect are? I looked at Joystick documentation hoping to find more of your thoughts this topic, but…

> Can you please elaborate what these areas of disconnect are?

I'm not the OP but something I have noticed is the JavaScript wünderkind seem to want to completely reinvent web browsers but in JavaScript. They seem to not actually know HTML, CSS fundamentals, or even HTTP. So you end up with frameworks that reinvent everything a browser already gives you (for free) but entirely inside their JavaScript monstrosities.

I might just be grouchy and uncharitable but it's certainly the feeling I get looking at any of the big JavaScript frameworks. It's infuriating to see frameworks reinvent something like a button with a bunch of anchors, divs, and spans when HTML gives them a perfectly functional button with a bunch of built-in events including touch events.

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

#288

Post by bsder »

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…

> That rendering some HTML, CSS, and interactive JS in a browser has been turned into what it has is staggering.

I think you are probably ignoring the fact that we have basically converged back to a web monoculture again.

A lot of the current frameworks were born out of "Chrome is shitty this way. Firefox is shitty that way. Internet Explorer is shitty this other way. This framework elides over all that."

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

#289

Post by 9935c101ab17a66 »

rglover wrote: post #256
mavelikara wrote: post #233

Earlier quoted context omitted.

> I realized just how disconnected JavaScript developers—yes, the "big boys" are especially off in CS la-la land—were from web development fundamentals. HTTP distilled down to its absolute essence is brilliant, but for some reason gets absolutely ignored in the JS world. Can you please elaborate what these areas of disconnect are? I looked at Joystick documentation hoping to find more of your thoughts this topic, but…

I've tried writing a response to you a few times but realizing how complex it is—the real answer to your question is worthy of a long blog post. The core problem is the blurring of the lines between a framework and the underlying technologies of the web (HTML, CSS, and JavaScript). To me, it seemed like a lot of unnecessary complexity was being added just to achieve the common goal of rendering some HTML, styling it…

You say that JSX adds complexity and plain HTMl is simple and obvious, and yet, when I look at joystick, I see a render functions, and non-obvious helpers like `each, when, component`, etc. JSX is really simple to understand for basic use cases and it provides so many benefits: - support for Javascript expressions - transpilation - better error reporting

I'd also argue that JSX is overall a LOT more readable than some of the more advanced examples you provide in the Joystick docs, especially because you don't get syntax highlighting in javascript template literals.

> The one consistent theme was confusion about how X framework mapped back to HTML in the browser.

I'm not saying you're lying, but in the case of JSX, I find this very hard to believe.

I do 100% emphasize with a new developer approaching react who starts with `create-react-app` and has to figure out which routing package to use, etc. But projects like `next.js` reduce the complexity of the mental model significantly IMO (file system routing, sane defaults for compilation, great local dev experience, etc).

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

#290

Post by austincheney »

threeseed wrote: post #274
austincheney wrote: post #259

Earlier quoted context omitted.

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

If it takes seconds to execute more features you are doing it extremely wrong.
Post reply on HN