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

581–590 of 722 posts

Re: The Frontend Treadmill

#581

Post by gr4vityWall »

Doesn't seem to be a popular opinion here, but I think FE can be ok. A typical React application feels easier to reason about than HTMX-based code that I looked at. I never had a hard time picking up an app that used React/Preact + Tailwind + some simple state management library like Preact Signals.

Maybe never having had to deal with GraphQL or Server Components helped.

Tooling, OTOH, does feel like it gets insane from time to time. I don't know why we needed such a painful migration to go from CommonJS to ES Modules in Node.js. They always just 'worked' in Bun, and even Node.js has a flag these days to allow you to use both of them together. ESLint changed their configuration format and instantly made every existent tutorial/configuration available out of date. I fail to see how anyone benefited from that.

It's not as popular these days, but I appreciate how Meteor always made an effort to be backwards compatible to the extend it was possible. The only __major__ migration was going from Fibers to Promises - and I don't blame them for picking the wrong 'horse' 13 years ago.

But yeah I feel very comfortable doing FE these days. Meteor for bigger fullstack apps, or just Vite for a simple FE, and things just work. TypeScript tooling is better than ever. AI helps automating lots of the simpler but tiring tasks like generating Zod schemas.

Re: The Frontend Treadmill

#582

Post by theknarf »

eximius wrote: post #383
jchw wrote: post #145

> Whatever framework you choose will be obsolete in 5 years. I am predominantly not a frontend dev, but when I do do frontend work, (and I don't avoid it by any means,) I have been using React for the past... 10 years now? And while some sentiment has been moving towards Svelte, by the time Svelte overtakes React, it will have been in production for just as long probably. And Angular might eventually run out of steam…

React today looks very different from React from 10 years ago. Easily as different as being a different framework. So, there is some nuance, but the logic isn't dead quite yet.

React Hooks have been out for 8 years. Idiomatic React code haven't changed much in the last 8 years, mostly it has just been a slow move away from using Redux.

Re: The Frontend Treadmill

#583

Post by theknarf »

dpcx wrote: post #355
Illniyar wrote: post #313

I love it when people phrase this as a frontend problem. It's not a frontend problem. It's just a "it's a huge ecosystem with new players" problem. I've seen this in Java 15 years ago when it was the front of innovation (I can name dozens of frameworks, and a half dozen build systems coming out in as many years). React 17-18 is quite a minor change then perl 5->6 or python 2->3 For backend instead of "let's use this…

React has been around for 11 years. The amount of stuff that's online that tells you to do something with it one way when the react devs tell you to do it another is _astonishing_. And that's just from the last few years. Or take webpack that's been around for 13 years. The way things are set up even within the last few years have changed dramatically. If Apache configs moved as much as these systems did, no one woul…

No one is using Apache... Almost everyone moved to Nginx years ago xD

Re: The Frontend Treadmill

#584

Post by theknarf »

TimTheTinker wrote: post #29
ng12 wrote: post #5

> Whatever framework you choose will be obsolete in 5 years. I've been writing React professionally for over a decade at this point. I don't know what this guy's on about.

How many dependencies does your package.json file declare? Which versions of node/npm does your team use? If you're on recent-enough versions and are using any popular libraries, you will have seen the deprecation notices pile up during npm install for downstream dependencies.

Java and .net developers also uses dependencies, and they too need to upgrade their dependencies (and sometimes switch out deprecated stuff). Definitely not a Frontend issue.

Re: The Frontend Treadmill

#586

Post by brabel »

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…

I work mostly on the JVM world, with Java/Kotlin. Two comments:

In Java: I can build stuff from the early 2000's without changing a line, most likely, if it's using Maven or Ant to build. If it's Gradle, we may have trouble with the JVM version even if Gradle wrapper is used, and if it's not, well good luck as Gradle has evolved hugely since the early days (I think early 2010's if my memory is any good).

In Kotlin: has been a wild ride for me... not like JS, maybe... more like what you describe from Rust. I mean, in 4 years you've had a breaking change, that's horrifying for someone used to Java :D. Kotlin does require a lot of upkeep compared to Java, specially when combined with said Gradle. More if you use KTest... much more if you use KTor... and a hell of a lot more if you use Kotlin MP, which we do on one of our projects (though I acknowledge we were early adopters).

Re: The Frontend Treadmill

#587

Post by michaelsalim »

dogcomplex wrote: post #476
jchw wrote: post #145

> Whatever framework you choose will be obsolete in 5 years. I am predominantly not a frontend dev, but when I do do frontend work, (and I don't avoid it by any means,) I have been using React for the past... 10 years now? And while some sentiment has been moving towards Svelte, by the time Svelte overtakes React, it will have been in production for just as long probably. And Angular might eventually run out of steam…

Yeah but we also got lucky there - like picking the right altcoin. React was just one of many then, and the rest all crumbled. And like OPs said, modern react is quite different than it was 10 years ago

I believe there's an art in choosing the right tools and frameworks. A big one i think is whether it solves a problem that no other tools have solved - rather than just an improvement.

React had that which I believe is the reason why they won. There are other "better" iteration after that but they don't inherently solve a big problem.

Re: The Frontend Treadmill

#588

Post by acdha »

Izkata wrote: post #511
acdha wrote: post #418

Earlier quoted context omitted.

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

The major turn for the average user was actually 2009/2010. IE6 usage seems to have dropped below 1% by 2012, still before React's public release: https://www.theverge.com/2019/5/4/18529381/google-youtube-in... That said, I was on a team that was still supporting IE6 around 2014. We had clients, mostly in China from what I heard, that were required to use it because internal tooling had developed around it and their…

Yeah, I worked on things geared towards the general public so we had to support, say, a senior citizen who was using old computers at the underfunded library or senior center. They weren’t a high percentage of total traffic but it was still millions of people.

It was definitely frustrating knowing that a better world was possible but not quite there.

Re: The Frontend Treadmill

#589

Post by sfn42 »

edwinjm wrote: post #574
sfn42 wrote: post #569

Earlier quoted context omitted.

Well I've never worked much with python aside from using it for some math and ML classes in uni, but it's always been pretty close to JS near the bottom of my mental system programming language tier list. If you want to throw together some quick thing or toy project or whatever sure, knock yourself out. But I'll honestly never respect people who write large "serious" applications using Python or JS for their backend.…

JavaScript is perfectly capable to run on the backend. Many people/companies do it with great satisfaction.

Yeah I'm aware that it works. I'm just saying it's a bad choice. It's slower than most other languages, the language itself is just plain bad, the standard library is poor, npm isn't great, there's really just no good reason to use it other than "our devs don't know anything else".

Re: The Frontend Treadmill

#590

Post by pjmlp »

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.

Calling Win32 directly was already old fashion when Windows 95 came out in 1994, let alone 2005 when .NET was four years old.

The only folks already doing Win16 development with pure C code, instead of a C++ framework (OWL, MFC, VCL), VB or Delphi, were stuck in jurassic park.

The only valid reason for raw Win32 applications are games.

Post reply on HN