Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Frontend Treadmill

polotek.net

Post reply on HN
Print view View original

411–420 of 722 posts

Re: The Frontend Treadmill

#411

Post by adamtaylor_13 »

squidsoup wrote: post #399
adamtaylor_13 wrote: post #385

Earlier quoted context omitted.

Step 1: Resist the urge to overcomplicate. Step 2: Don't build multiple applications that need shared components. Step 3: Profit I slightly tease here, but really these are all leadership decisions that you can simply decide against. I would never implement those things because they're largely profit-less decisions. Having 2 apps that operate slightly differently is okay—even under the same brand.

> Having 2 apps that operate slightly differently is okay—even under the same brand. Perhaps if you those two apps are in completely different domains, but if you have a suite of apps that are all related, maintaining consistent styling and behaviour provides a much better user experience. Essentially what you're saying is rails isn't capable of solving that problem, and if you're talking about efficiencies/profit, i…

Rails can certainly handle those issues. I’m commenting on your example which isn’t a problem anyone _needs_ to solve.

I’ll also point out, sure, better UX, but again—not profitable. Look at Microsoft, one of the largest software companies in the world and people still use their awful products despite no consistent UX.

This isn’t a Rails problem, it’s a leadership problem.

Re: The Frontend Treadmill

#413

Post by bobthepanda »

evantbyrne wrote: post #243
divan wrote: post #195

Earlier quoted context omitted.

The worst thing is that it's a cultural aspect. This deprecation and breaking stuff hell is a result of millions of micro-choices. "Why not rename MultiselectDropdown into MultiSelectButtonDropdown! And maybe replace the API of that component to a completely new one! Sounds like a cool idea!". Thousands of person-hours are spent daily for fixing results of such 'extremely important'™ breaking changes. There is simply…

I suspect the cultural issues with JS primarily boil down to the fact that every org needs JS, which in turn results in 1) a glut of junior/mid devs and 2) it naturally being ground zero for hype cycles. At this point I honestly wonder if most orgs should even hire for JS skills, or if they would be better served by hiring backend engineers and training them to write progressively enhanced UIs.

I've also experienced the other end. As a pithy saying goes, "it takes a lot of skill to write Java in every language."

Re: The Frontend Treadmill

#414

Post by [deleted] »

nullpoint420 wrote: post #408
uhoh-itsmaciek wrote: post #336

Earlier quoted context omitted.

It does. It bridges a purely server-rendered architecture with a SPA really nicely, and does it mostly with web standards. You don't need to run any client-side JS with a Remix app. It's not perfect, but there are a lot of benefits to its approach. I won't try to argue there's no front-end treadmill: there absolutely is, and I had to laugh reading the current top comment because I just had to migrate off Apollo CLI a…

> mostly with web standards IMO, the pain from "mostly" starts to show when integrating React Router v6 with legacy frameworks and applications. I'm sure if you go all in on React Router v6 it's great. At my $DAYJOB we are migrating to Remix w/ GraphQL Federation. It's been a pain. Especially because we haven't finished any of these migrations: * ExtJS -> JQuery * JQuery -> React class components * React class compon…

[deleted]

Re: The Frontend Treadmill

#415

Post by bobthepanda »

cxr wrote: post #295
mplanchard wrote: post #2

I have recently been doing some upgrades to the build system for our FE code to swap out yarn for pnpm. I’m normally a backend engineer, but I’ve spent plenty of time in the JS mines. The most frustrating thing about dipping in to the FE is that it seems like literally everything is deprecated . Oh, you used the apollo CLI in 2022? Bam, deprecated, go learn how to use graphql-client or whatever, which has a totally d…

> Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. And by "in JS", you really mean, "in NPM land". So long as folks keep remaining seemingly (almost willfully) ignorant of the source of their pain and/or running right back into the fire the next time the opportunity presents itself, that pain is going to continue. NPM sucks. It's not the way to do JS. Everyone who h…

the problem is that as with everything else in FE it is kind of hard to tell what successor framework will "win" and not do this to you.

Svelte and Vue were nice and stable until they were not, Deno as an alternative to NPM kind of never got any traction, and unfortunately no one has come up with a better sandbox that works the same everywhere other than the web.

Re: The Frontend Treadmill

#416

Post by pcthrowaway »

8n4vidtmkvmk wrote: post #156
fragmede wrote: post #33

Earlier quoted context omitted.

Wait, we're supposed to use pnpm now? What happened to yarn? What's wrong with npm? I stop paying attention for six months and even the installer has changed. What's an npx?

No, we're past pnpm and on to bun now

Bun may be fine for people using it to replace the javascript runtime

As a dependency management toolchain I recommend reading: https://dev.to/thejaredwilcurt/bun-hype-how-we-learned-nothi...

I had some issues with it using it briefly (though it was way faster than other installers I've used)

Re: The Frontend Treadmill

#417

Post by [deleted] »

skydhash wrote: post #380
aaronbaugher wrote: post #121

Earlier quoted context omitted.

Absolutely. It took me a while to realize that I hated web development and why: because of all the layers of stuff you have to deal with on top of that document fetching platform. Something as simple as maintaining a login session is a complicated problem, even before you get into validating users, single sign-on, etc. You can put a lot of that out-of-sight/out-of-mind by letting a framework deal with it, but it's st…

But most web apps are actually web sites and they do fit the document model. If we consider the web as a UI layer, it's capabilities are more than just sufficient. The issue is when you want to bring business logic into it, or fighting the document model to bring in your own abstractions.

[deleted]

Re: The Frontend Treadmill

#418

Post by acdha »

thaumasiotes wrote: post #407
acdha wrote: post #384

Earlier quoted context omitted.

I did that a few years ago and it was fascinating: not only did it remove near-weekly React dependency churn, it produced significant performance improvements (multiple orders of magnitude better update speed - and yes, I did the usual incantations), and the total lines of code in our repo actually went down and it was easier code because it just did what was necessary without having to deal with layers of abstractio…

> but a lot of younger developers only ever really learned React and are stuck the IE6 era it was designed around Last release of IE6: 2008 Concerted campaign to make everybody stop using IE6: 2009 Microsoft joins that campaign: 2011 First release of React: 2013

It may be hard to remember now that we’ve had frequently-updated browsers for so long but not everyone updated promptly. That lead to a lot of now-vestigial frontend culture where developers would build around the oldest browser they couldn’t afford not to support.

That colored a lot of low-level decisions about how events were implemented, false claims about virtual DOMs being fast or efficient, and especially the culture of adding dependencies because you need a feature which wasn’t in Internet Explorer. Once that trend is established, it’s hard to change without breaking compatibility and so you end up with people in 2025 using slower code based on the support matrix set over a decade earlier.

(And to be clear, I’m not saying that React has no redeeming values - only just it’s healthy to reconsider decisions made in previous decades to see whether the cost/benefit ratio has changed. I think we’re going to see some really interesting shifts as funding for open source shifts in a non-boom economy, but also as LLMs adjust the working style & relationship many people have to maintenance.)

Re: The Frontend Treadmill

#419

Post by divan »

edwinjm wrote: post #410
divan wrote: post #195

Earlier quoted context omitted.

The worst thing is that it's a cultural aspect. This deprecation and breaking stuff hell is a result of millions of micro-choices. "Why not rename MultiselectDropdown into MultiSelectButtonDropdown! And maybe replace the API of that component to a completely new one! Sounds like a cool idea!". Thousands of person-hours are spent daily for fixing results of such 'extremely important'™ breaking changes. There is simply…

What are you talking about? Websites from ten or twenty years ago are still working. If there's one technology with good backwards compatibility, then it's JavaScript.

Definitely not talking about vanilla js.

Re: The Frontend Treadmill

#420

Post by tonyhb »

cmgriffing wrote: post #372
tshaddox wrote: post #259

Earlier quoted context omitted.

I think you're mistaken. I can't comment on the quality of Kent C. Dodds' educational content, but his formal affiliation with Remix was short-lived. The courses that he sells have no apparent affiliation with Remix (the open source project or the company). Incidentally, Remix is an open source project started by the React Router devs to create more framework features around React Router. React Router is probably one…

While his formal affiliation may have been short-lived, do you think he got a cut of the sale to Shopify? If so, not disclosing that when he promotes Remix is a bit shady. Nice dude and all, but that is one thing I take issue with still.

There are only a few popular, promoted alternatives to NextJS right now (that I know of): Remix and TanStack. That is, if you're fully React focused, ofc. I dont see promoting Remix as a red flag.
Post reply on HN