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

241–250 of 722 posts

Re: The Frontend Treadmill

#241

Post by rpmisms »

bob1029 wrote: post #80
antirez wrote: post #9

To jump off the treadmill is not using a fronted framework: at all, and not using a random one and not rewriting the code later. Server side rendering, JavaScript only when needed, no separation between backend and frontend folks in the company.

> no separation between backend and frontend folks in the company. This is the biggest gain available anywhere. When you have one engineer who is empowered to write SQL specifically crafted to pull the exact columns required to SSR a web view (which they are also responsible for), you don't need to spend a single second thinking about APIs or ORMs or whatever. You just need to know SQL and modern vanilla HTML/CSS/JS.…

Does writing HTML into database entries count? Because certain large entertainment companies are ahead of the curve if so.

Re: The Frontend Treadmill

#242

Post by tajd »

anthropodie wrote: post #140
0x000xca0xfe wrote: post #120

Earlier quoted context omitted.

And the craziest part is that it is built on top of JS/HTML which is an extremely stable technology at heart. 15 years ago I wrote a small (5KLOC) vanilla JS webapp that is still in daily use by around 10 people without a single line changed. It held up better then my Win32 applications! Almost all of the front end churn is simply a political/organizational failure.

I build simple applications for personal use like issue tracker, day planner, etc,. By default if you ask Claude it will generate React for frontend but I ask it to use HTML/CSS/JS instead. Because as a backend developer that makes sense to me. I find it hard to read the react code and want to avoid having dependency on npm. It's surprising how well the core technology works without fancy front end frameworks. Claude…

Yes, 100% this. I’ve seen this idea before somewhere, but I wouldn’t be surprised if people started to basically develop more of their own software from first principles like this.

I was doing it today to create a gantt chart from mermaid.

I’ve built other applications inside react components as react seems relatively stable - I don’t really care about react though, only that it has a lot of training data for it.

Re: The Frontend Treadmill

#243

Post by evantbyrne »

divan wrote: post #195
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…

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.

Re: The Frontend Treadmill

#244

Post by guybedo »

LLMs are a huge win in that regard.

I delegate most of my frontend tasks to Claude Code, no need anymore to waste hours understanding why the latest version of framework xyz isn't compatible anymore with library abc.

Also, it feels like there's way more boilerplate code, repetitive tasks in frontend land, once again my buddy Claude Code can generate UI components html and typescript code 100x faster that i can

Re: The Frontend Treadmill

#245

Post by emseetech »

ninininino wrote: post #208
Aurornis wrote: post #161

Earlier quoted context omitted.

> It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc. I’m amazed at how much of this is driven by the FE influencers. The FE world has embraced social media, YouTube, and even Twitch to a degree that I haven’t seen in other domains. Influencers in these areas need to have a constant stream of fresh material to stay relevant, so they’re always…

I'm only recently getting into some of the dev influencer stuff (and enjoying watching some!), I've discovered Primeagen and Theo but that's about it. Are you willing to name some names? I am trying to still form my mental model about these people and what I should pay attention to and what I should ignore.

They're just entertainment. Like throwing on a movie or tv show.

I found value in a handful of Primeagen's videos (he inspired me to relearn C programming in a roundabout way) but the vast majority are fluff and I skip them based on the title or within the first 5 minutes.

A couple exceptions are Low Level Learning and Tsoding, who both generally stay technical, and any guest appearance by Casey Muratori will be worthwhile.

But even those, you're better off with a book or your own project to work on.

Re: The Frontend Treadmill

#247

Post by hajile »

zero_shift wrote: post #128
ForTheKidz wrote: post #19

Why does FE development have such churn? Desktop toolkits from 30 years ago work just as performantly today; what is so difficult about the browser that demands constant framework updates?

It doesn't. It's just a meme. React has been around for eleven years now, and complaints about frontend churn started with the Angular 2 announcement (in late 2015)

Churn complaints are older than Angular 2. We'd gone through an entire cycle of churn around templating engines (mustache, handlebars, ejs, jade/pug, nunchucks, underscore, lodash).

Gen 1 wars (up through 2010-ish), we had: jQuery-UI, Prototype, SproutCore, YUI, MooTools, Google Web Toolkit, Dojo, ExtJS, BackboneJS, etc. There were no survivors.

Gen 2 wars (up through 2015-ish): Angular, KnockoutJS, Ember, Enyo, React, Vue, Meteor, Polymer, Aurelia, Elm, Mithril, etc.

Gen 3 wars (up through today): React, pReact, Vue, Angular 2, Svelte, SolidJS, AlpineJS, InfernoJS, Lit, etc.

We're actually more stable than we have been in a long time. The difference in performance changing frameworks could often get 10x or sometimes even closer to 100x performance increase. Today, even the slowest framework is generally within 20-30% of hyper-optimized VanillaJS. You really can't go wrong with any of them anymore.

Re: The Frontend Treadmill

#248

Post by gmueckl »

wolvesechoes wrote: post #237
hombre_fatal wrote: post #181

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. Then you'd make a more sensible comparison like React versus something like SwiftUI which is constantly changing, constantly breaking, and still basically in beta mode for 10 years, yet it only runs on specific versions of Apple hardware and software. And usually it's so insuffi…

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

Just to reinforce how stable the desktop environment can be:

- Qt has had a mostly stable interface since Qt 4.0 and that was twenty years ago.

- Win32 has had barely any breaking changes since it was introduced with NT 3.1 in 1993 or so.

Most of the UI/UX churn in that space comes from fashion changes in UI design.

Re: The Frontend Treadmill

#249

Post by homebrewer »

numinoid wrote: post #216
bloomingkales wrote: post #215

Earlier quoted context omitted.

Here's one: https://remix.run/ These grifters sell entire courses on the product, that's their game. So when you find an unmaintained Remix app at your company, well, the grifters got the ears of your junior devs :( And they just promote it and promote it: https://kentcdodds.com/blog/a-review-of-my-time-at-remix https://kentcdodds.com/blog/why-i-love-remix https://kentcdodds.com/courses Pure grift. But since most peo…

Not sure it's fair to characterize a repo with 6k + commits and the last being 10 hours ago as "pure grift".

E.g. react-router was ready 5990 commits ago. It is a grift, they keep rewriting it and reengineering the API over and over and over again just to be able to sell more training.

Look at wouter for what is possible if your motivation isn't selling training material. It was written and left alone, it works just as well, it's stable and doesn't change for no reason.

Re: The Frontend Treadmill

#250

Post by bloomingkales »

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.

The thing is brilliant UI engineers will stun you with incredible UI. It's almost like not investing in AI, you will get blind sided by products that just look and feel better. Your backend engineers are never going to cut it. This is true for backend engineers too, if you try half ass it with "full stack" devs, brilliant backend devs will stun you with things and your products will be inferior.

For example, we all got stunned by the machine learning people. We have to pay attention to everyone.

Post reply on HN