Live data from Hacker News

The Frontend Treadmill

polotek.net

281–290 of 722 posts

Re: The Frontend Treadmill

#282

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.

> Newbies should read MDN and ignore everything else. I think people forget how inaccessible it is for a newbie to start writing pure javascript directly from the API reference. People need tutorials and walkthroughs, and need to build a an internal understanding of how these all work. Frameworks help them abstract all that

MDN has exactly those kinds of tutorials and walk throughs! It’s not all API documentation

Re: The Frontend Treadmill

#283

Earlier quoted context omitted.

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

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 group compliments each other very well and brings extreme expertise. No one on such a team ever goes "I can do what that guy does", because it's not a run of the mill mass market team.

I think in the age of AI we'll see more concentrated teams since everyone can hit up AI and do anything. It's going to be very important to build tight teams, and I don't think it's going to happen by continuing our factory farm level recruitment.

Re: The Frontend Treadmill

#284
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.

So you're just jumping on the backend treadmill.

Re: The Frontend Treadmill

#285
post #194

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

VanillaJS is a worse solution. When the JS framework benchmark first came out, VanillaJS was the fastest. After some of the vdom frameworks came out (especially InfernoJS), VanillaJS was slower. How did they make VanillaJS faster? They studied the output code paths of InfernoJS and copied them. Each time InfernoJS would release new, faster versions, they'd backport those optimizations into the VanillaJS. Then SolidJS…

You have to define "worse". What is actually "worse" is paying developer time to sit there in a never-ending upgrade and deprecation cycle when your core product is elsewhere.

Re: The Frontend Treadmill

#286
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's your Create React App support in 2025? Are you still keeping your app on React 15?

It takes ten minutes to switch from CRA to Vite.

Re: The Frontend Treadmill

#287

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…

Can we make something like a “non-deprecation” pledge for libraries? Just make a public commitment on the top of your readme file saying that you will maintain backwards compatibility in your API for at least a couple years. This will make me choose your library over others.

Re: The Frontend Treadmill

#288
post #171

Earlier quoted context omitted.

That's fascinating, and I had no idea web dev influencers were so big. I checked, and there really are people with millions of followers doing development. Personally, the idea of learning anything related to coding through a video is extremely frustrating. It's a text medium. I want to look at things, take time, think it over, compare code, follow references, look up functions. That people like video formats isn't r…

> That people like video formats isn't really surprising to me since it's everywhere That’s because those “people” are either larping students or kids that want to become programmers. I have never in my 10 year career met a person who said “yeah, I learn my craft from Fireship videos”.

I've learned most of what I know about database internals from MCU lecture course on YouTube. It's great.

Re: The Frontend Treadmill

#289

Earlier quoted context omitted.

Imagine someone made Deno with a corresponding course to go along with it. I would consider that a grift. https://frontendmasters.com/courses/remix/ That was the end goal for this whole thing. I do look at the pricing page (what are you trying to sell constantly?) on anything people put up on the internet and judge from there. You can have the last word and put in a testimonial for Remix, since I won't be budging on…

I'm not interested in writing a testimonial for Remix, merely commenting on the absurdity of calling a project of this scale as nothing more than a grift to sell educational content. There's no reference to these paid courses anywhere on the landing page, there's no callout for paid courses in the main navigation. The only mention of tutorials at all is buried in the community section which leads to: https://remix.gu…

No personal vendetta. We sit here and punch the mysterious air as to why things are the way they are. I thought maybe we'd punch up at something that is plausibly a culprit. I'll admit it may be punching down, since this is just one dude. But then again, it's one dude who influenced a lot of people ...

We can't just keep sitting here and blaming developers for being

1) New

2) Dumb

3) FOMO

4) Dumb

5) Unqualified

You understand? It's worth looking at what content they are consuming and where the mindshare is being promoted from. It's worth asking who is selling them the idea of these frameworks.

Re: The Frontend Treadmill

#290
> If your product is still around in 5 years, you’re doing great and you should feel successful. But guess what? Whatever framework you choose will be obsolete in 5 years.

Frontend guys crack me up. The browser is an extremely advanced environment and ES6 is an extremely powerful language. You don't need a framework. You haven't for 10 years now, which is probably why they're so easy to replace, they're wrappers of very thin technology and very thick opinions.

The only reason to use one is if you want to share code between the web and a native app, otherwise, it's a complete and total waste of your engineering efforts.

Post reply on HN