The Frontend Treadmill • Hacker News Board

Re: The Frontend Treadmill

#391

Post by folago » Thu, Mar 20, 2025, 9:19 PM UTC

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.

Maybe hire BE devs and use htmx.

Re: The Frontend Treadmill

#392

Post by H1Supreme » Thu, Mar 20, 2025, 9:19 PM UTC

Considering all the advancements that Vanilla JS and CSS have made in recent years (plus exciting features like animating "display: none" that are almost fully adopted), I think templated HTML on the server + JS where it's needed, makes more sense than ever. And, that's coming from someone who largely makes their living from React.

Like the author, I've been doing frontend in one way or another for 20 years. The ecosystem, churn, and the absolute juggling act of sync'ing state between the frontend and backend is batshit crazy.

I recently started a proof of concept project using Go templates and HTMX. I'm trying to approximate building a UI with "components" like I would with React. There's still a lot of rough edges, but it's promising. I'm still not sure I need HTMX tbh. I've started managing event listeners myself, and I think I prefer it.

Interestingly enough, managing complex UI state that's based on user roles and permissions is so much easier on the server. Just send the HTML that the user is allowed to see. Done.

That said, React, Vue, et. al has sooo much steam. I don't know how a collective shift in thinking would even begin. Especially considering all the developers who have never known anything but frontend frameworks as a way to build a UI.

Re: The Frontend Treadmill

#393

Post by bloomingkales » Thu, Mar 20, 2025, 9:20 PM UTC

mplanchard wrote: post #92

diggan wrote: post #86

Earlier quoted context omitted.

> Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. It’s bananas. The thing is, it's totally possible, but it requires restraint and properly caring about what you pull into your project. Back in the vanilla JS/jQuery days, when I got started, our "dependency management" was basically copy-paste .js files into a `vendor/` directory. Then nodejs/npm appeared (and bowe…

I agree you can avoid it with care, but I do think it's a JavaScript problem, at least moreso than in other languages. The culture is one of acceptance of churn. It seems like everything from minor libraries to major frameworks is much more likely to introduce a breaking change in JS than in Rust, C++, or even python. I've never written any emacs lisp that I had to change when upgrading emacs, and the third-party lib…

People have a lot of opinions of javascript because it really is the Statue of Liberty. You really can know a subset of Algol and have portable apps in the browser asap.

Well gosh darnit, then everyone and their mother is going to come to America

It's an age old envy.

Re: The Frontend Treadmill

#394

Post by wolvesechoes » Thu, Mar 20, 2025, 9:26 PM UTC

cyberax wrote: post #296

wolvesechoes wrote: post #237

Earlier quoted context omitted.

"Well, you should compare the JS UI ecosystem to other UI ecosystems like Android and iOS, not ecosystems that run on one machine with no UI." "People who have never touched any UI tech until HTML/JS have no clue how good they have it" Tech like: - Delphi/Free Pascal, where usually code from 20 years ago compiles today with minor adjustments? - Qt, developed and maintained for over 30 years, currently at 6th major re…

On the other hand, I can write a very complicated graphics-related app in React+tons_of_libs within _days_. It took me months to do that in Win32 API in 2005. The developer velocity enabled by React is insane.

Yes, saying that calling Win32 APIs is not the most ergonomic approach to writing UIs would be an understatement, but if any software can be called stable, this is it.

Re: The Frontend Treadmill

#395

Post by schindlabua » Thu, Mar 20, 2025, 9:33 PM UTC

mplanchard wrote: post #339

schindlabua wrote: post #110

Earlier quoted context omitted.

And I think the Javascript problem exists because frontend/UI is just a very complicated domain, in the sense that frontend is a big messy ball of side effects. If you've been around and saw the web grow up, and saw all the new ideas all those libraries brought to the table (jQuery deferreds becoming async/await, 960 grid slowly morphing into flexbox and css grid, etc etc) then all the breaking changes make sense, we…

I’ve been writing JS since the PHP and jquery days, so I’m not unfamiliar. I understand these libraries are doing complex things, but they also seem to love churning for churn’s sake (react hooks is an example, svelte v5 is another, eslint entirely deprecating their old config format is yet another). I don’t mind learning or using a framework to do complicated things. I mind when the ecosystem as a whole makes it so…

Hooks were great. But yeah eslint flat config is probably also better than the old format but we could have easily done without that breaking change you're right.

The churn is part of why I try to do mostly backend these days, especially with the current state of tooling. Like when react came out it was immediately clear it was going to be a mainstay, I can't imagine nextjs in it's current form to be around in a few years because it's very terrible and I want the metaframework dust to settle a bit before diving back in.

Re: The Frontend Treadmill

#396

Post by meshweaver » Thu, Mar 20, 2025, 9:37 PM UTC

> New developers are having an extremely hard time learning enough skills to be gainfully employed. They are drowning in this complex garbage and feeling really disheartened.

> We need to relearn what the web is capable of and go back to that.

> And it [the web] has only gotten better over time while retaining an incredible level of backwards compatibility.

I would suggest that "retaining an incredible level of backwards compatibility" might be one of the sources of this "complex garbage" the web world is drowning in.

The fact that so many people feel the need to reach for a framework makes me wonder if the web doesn't do nearly as much as it needs to do. Maybe the web will always just be too big, too slow to change, and too bad at pruning out all of the bad ideas that accumulated over the years.

"But what about backwards compatibility? Don't we want all the old web apps to continue to work forever?" Yes, so ship the renderer with the app.

Sure, the current web is probably beyond being able to this, but I'm sure we'll eventually find a far better way to distribute software than the web, a way that makes fewer assumptions about the environment our code will run in.

Re: The Frontend Treadmill

#397

Post by koakuma-chan » Thu, Mar 20, 2025, 9:38 PM UTC

breadwinner wrote: post #151

> Whatever framework you choose will be obsolete in 5 years. The mistake here is the assumption that you need a "framework". I challenge this notion. What does code that does not use a heavy framework look like? It is very maintainable and easy to use and will not become obsolete. Here's an example: https://github.com/wisercoder/eureka/tree/master/webapp/Clie... It uses two 500-line libraries, hardly a "framework". O…

React is not a framework.

Re: The Frontend Treadmill

#398

Post by jongjong » Thu, Mar 20, 2025, 9:41 PM UTC

It is kind of gaslighting to say that frontend frameworks don't last more than 5 years when React has been around and popular for more than 10 years and the vast majority of FE jobs today are React.

When I read comments suggesting that frameworks keep changing, it sounds like the kinds of articles which were written 7 to 10 years ago. It made sense to say that back then, the top frameworks DID keep changing. Nowadays it just sounds very strange... It's like complaining about something which is no longer a reality... But which actually turned out to have been a good thing all along.

I actually liked that different companies used different frameworks. It mirrored the reality that no framework is inherently superior to every other framework for every use case. I hate the pretense that React is the silver bullet while simultaneously pretending that it's an underdog struggling for relevance in a world of relentless framework-churn...

Re: The Frontend Treadmill

#399

Post by squidsoup » Thu, Mar 20, 2025, 9:49 PM UTC

adamtaylor_13 wrote: post #385

squidsoup wrote: post #354

Earlier quoted context omitted.

Sure, but then your company grows large enough to want its own design system, and you have multiple applications that need shared components. How do you implement that in rails?

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, implementing a component _once_ is a better strategy, and actually less complicated than two similar implementations of the same component.

Re: The Frontend Treadmill

#400

Post by evantbyrne » Thu, Mar 20, 2025, 9:49 PM UTC

bloomingkales wrote: post #283

evantbyrne wrote: post #267

Earlier quoted context omitted.

backend and frontend engineers aren't as distinct from each other as they are from ML or something like embedded development. It is very normal to be able to build a web interface end-to-end, and frankly something I expect of every competent developer in that space. Someone who is a high-performing frontend engineer should also be able to perform at a high level in backend, and vice-versa. I'm talking about the indus…

I totally get your point. I'll just give you a little color about where I'm coming from. Most products don't need a team of over five frontend/backend devs (so imagine a team of 10 people). Most teams have been over staffed. When you are overstaffed, that's when everyone needs to be cookie cutter with cookie cutter expectations (e.g backend should do ui, frontend should backend). On non-overstaffed teams, the core gr…

That's an interesting point about team composition. Companies originally split frontend from backend to scale up the number of developers they could put on projects. The idea was that each system could be a black box to the other team, and you may only need one person that understands it all end-to-end. The problem was that by splitting monoliths into multiple services they basically lost most of the advancements the industry had made to increase developer velocity. If your org was trending towards hyperscale, then you would have been transitioning to a multi-service architecture anyways, but for everyone else the move to SPAs resulted in a massive loss of productivity.

Listen, how impactful LLMs will be largely depends on the type of code teams are writing. If you're already building in a highly declarative manner, where your libraries are automatically handling most of the glue for you, then you may not have much of a need for writing code more quickly. These are the teams that are actually fast. Teams that already spend a bunch of time writing glue code will likely see significant improvements in velocity, because LLMs are good at regurgitating existing patterns. What they probably won't do is refactor your project so that your team starts operating on the level of the formerly described one.