TechTakes

1489 readers

31 users here now

Big brain tech dude got yet another clueless take over at HackerNews etc? Here's the place to vent. Orange site, VC foolishness, all welcome.

This is not debate club. Unless it’s amusing debate.

For actually-good tech, you want our NotAwfulTech community

founded 2 years ago

MODERATORS

dgerard@awful.systems

A Rant about Front-end Development (blog.frankmtaylor.com)

submitted 5 months ago* (last edited 5 months ago) by fasterandworse@awful.systems to c/techtakes@awful.systems

47 comments fedilink hide all child comments

A masterful rant about the shit state of the web from a front-end dev perspective

There’s a disconcerting number of front-end developers out there who act like it wasn’t possible to generate HTML on a server prior to 2010. They talk about SSR only in the context of Node.js and seem to have no clue that people started working on this problem when season 5 of Seinfeld was on air2.

Server-side rendering was not invented with Node. What Node brought to the table was the convenience of writing your shitty div soup in the very same language that was invented in 10 days for the sole purpose of pissing off Java devs everywhere.

Server-side rendering means it’s rendered on the fucking server. You can do that with PHP, ASP, JSP, Ruby, Python, Perl, CGI, and hell, R. You can server-side render a page in Lua if you want.

you are viewing a single comment's thread
view the rest of the comments

[–] self@awful.systems 12 points 5 months ago (1 children)

facebook used to lie about react being faster than native on first load and navigation, in spite of that being impossible by both lived experience and as measured by benchmarks. supposedly templating is just too heavyweight for servers to handle at the mythical Amazon scale literally nobody reaches except Amazon but every shitty manager needs us to be ready for

and now that react can do server-side rendering I guess we’re doing templating again, but in node and much less efficient and with extremely unclear semantics around when it switches to client rendering, and also weird bugs when things render differently under SSR

also it’s still measurably much slower than old school server templating

[–] V0ldek@awful.systems 9 points 5 months ago (1 children)

the mythical Amazon scale

Ah yes, Amazon, the company with literally the shittiest front-end of all in existence. AWS is downright unusable outside of the CLI, but hey, at least they scale??

[–] self@awful.systems 7 points 5 months ago (1 children)

you know, for as much poison’s been poured into my ear about how everything must be Amazon scale, there’s no way in fuck they use react for their storefront or AWS, is there? I think the only reason react is considered an Amazon-scale frontend (besides Facebook, which also has a shitty UI, though not as bad as Amazon, and notoriously uses PHP for everything) is how hard they push it as part of AWS Amplify, a toolchain they say will help you reach their scale (but from experience: it absolutely will not, it’s just a set of technologies that increase your AWS bill and perform like shit, which is why Amazon doesn’t use it for anything of value themselves)

the only case I can immediately think of of a very major site going from server rendering to react is GitHub (which used to use Ruby on Rails and Erlang, apparently) and it’s been an unmitigated disaster — none of the new features that supposedly require react are good, the performance fucking sucks now, and the thing keeps breaking (I get weird renders with broken styling every few refreshes and apparently I’m not the only one). the fucking thing even hijacks the keyboard shortcuts I use and has become an accessibility nightmare, all in the name of pointlessly turning it into a react SPA and vscode wannabe.

[–] V0ldek@awful.systems 7 points 5 months ago

Hey, GitHub might be shitty in the browser, but did you consider that it's also shitty as an Android app?