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

111–120 of 722 posts

Re: The Frontend Treadmill

#111

Post by aaronbaugher »

rambambram wrote: post #95

Good read and I agree fully. Also been doing webdev for 20+ years now and I'm still very happy with the CHAMP stack. CHAMP of course standing for: CSS, HTML, Apache, MySQL and PHP. As you can see, there's no J in CHAMP. I have been doubting my choice in the past, because everybody was using (frontend) frameworks and the like and I'm just a social animal like everybody else. I'm happy I stuck with the stuff I already…

If you want to include some dynamic elements without getting into the whole frontend framework thing, HTMx is pretty great for that.

Re: The Frontend Treadmill

#112

Post by _fat_santa »

> Product teams that are smart are getting off the treadmill. Whatever framework you currently have, start investing in getting to know it deeply.

I've been working on a SaaS product for a couple of years and when I first started I picked up MUI as my FE framework. Since then on at least 5 different occasions I looked into replacing it and have always landed back on "no lets keep it".

MUI is far from a perfect FE framework but for me I realized it worked really well because it helped me create pretty professional looking UI's without any designer assistance. And over the years I've learned many of the quirks around the framework and have implemented various tooling to mitigate any shortcomings.

I'm still looking for an eventual replacement though, for a while I thought I was going to jump on Google's official material design spec but then they stopped working on the web version. At this point I'm probably going to gradually adopt TailwindCSS (probably over the course of a year or more) and eventually move my FE to an entirely custom build solution.

But even thinking about this change I still come back to "what's the point?". Customers like my product and use it ever day, MUI has it's shortcomings but it's not something terrible I need to jump ship from. I'm sure I will eventually replace MUI but so far it's been chugging along just fine.

Re: The Frontend Treadmill

#113

Post by romellem »

wbobeirne wrote: post #44
ForTheKidz wrote: post #26

Earlier quoted context omitted.

Javascript doesn't have a good enough standard library to execute on this. You need frameworks just to patch up the runtime (or otherwise avoid the holes). Last time I checked they didn't even have decent hashmap or set implementations (let alone decent serde support).

This was true in the lodash and jquery as essential days, but hasn't been the case for years. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

> hasn't been the case for years

For 10 years, actually. ES6 - otherwise known as ECMAScript 2015 - did in fact come out 10 years ago.

- https://en.wikipedia.org/wiki/ECMAScript_version_history#6th...

It truly did improve the JS landscape by an order of magnitude.

For those unfamiliar with the extensive features this brought to JS, here is a good list:

- https://rse.github.io/es6-features/

Re: The Frontend Treadmill

#114

Post by conorbergin »

only-one1701 wrote: post #57
conorbergin wrote: post #27

When I made my first website I read things online like "svelte is better than react" and "solid-js will be the next big thing", and I thought this was an important part of web development. Newbies should read MDN and ignore everything else.

React's been around long enough and is dug in deep enough to have decent ROI on knowing fairly well, but the recent obsession with Next.js and SSR...maybe not. Privately I think this might be their undoing.

I agree with learning React, it pops up in all sorts of places, vscode extensions, the windows start menu apparently.

But yes, mixed-rendering, server functions, meta-frameworks, etc. You are in real danger of spending years learning all this stuff and still not being any closer to knowing how computers work.

Re: The Frontend Treadmill

#115

Post by Kerrick »

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?

Hmm...

React, Backbone, jQuery.

SwiftUI, AppKit, Cocoa, Carbon, Toolbox.

WinUI 3, UWP, WinRT XAML, WPF, WinForms, Win32 GDI.

---

Of course this is misleading, because React has had so much internal churn. But desktop toolkits also have churn.

Re: The Frontend Treadmill

#117

Post by liminal »

We're trying to hire an Angular design engineer, so now the recruiter is the person trying to get management to switch to React to make his search easier. The tech doesn't matter too much, but the market forces do.

Re: The Frontend Treadmill

#118

Post by rambambram »

aaronbaugher wrote: post #111
rambambram wrote: post #95

Good read and I agree fully. Also been doing webdev for 20+ years now and I'm still very happy with the CHAMP stack. CHAMP of course standing for: CSS, HTML, Apache, MySQL and PHP. As you can see, there's no J in CHAMP. I have been doubting my choice in the past, because everybody was using (frontend) frameworks and the like and I'm just a social animal like everybody else. I'm happy I stuck with the stuff I already…

If you want to include some dynamic elements without getting into the whole frontend framework thing, HTMx is pretty great for that.

Oh, I do include some JS, just a little bit. A little sprinkle on top, that's enough for my use cases. But CHAMPj just doesn't sound that nice. ;)

Re: The Frontend Treadmill

#119

Post by sherdil2022 »

If someone new to FE development were to start today, what would the process be?

A) If they are on their own (one-person team), they will do a web search and pick the most popular framework/library etc. Or do some POCs in a few of these frameworks/libraries and pick one.

B) If they are part of a team, they will go with whatever the team has decided

If someone has been doing FE, they either will stick to whatever they are doing or search for what else is out there. Yes. This sounds like a treadmill - but that is part of software development and continuous improvement, right?

Building a website in plain/vanilla JS or no JS is possible.

It all boils down to what is moving the product development forward. And this isn’t always simple or possible with FEs.

There are many choices for BEs and cloud providers as well - and sometimes a combination of those.

In short, there are no right or wrong answers. It is always - “it depends” - on what scenarios you are targeting and what features you want to build

Re: The Frontend Treadmill

#120

Post by 0x000xca0xfe »

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…

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.

Post reply on HN