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

491–500 of 722 posts

Re: The Frontend Treadmill

#491

Post by HJain13 »

jrajav wrote: post #469
datagram wrote: post #387

Earlier quoted context omitted.

It's not too difficult to use the TypeScript type checker on JS files, so it's possible to reap most of those benefits without having to introduce a compilation step.

In my experience, most of the benefits of Typescript come from type-checking across call boundaries, the point where type-related bugs are most likely to be introduced due to each side of the call often being in different locations and contexts. And you can't get those benefits without explicitly typing function parameters.

If you really don't want the compilation step; you can use JSDoc and get almost the best of both worlds (not everything in TS is supported by JSDoc but most essentials are)

Re: The Frontend Treadmill

#492

Post by DidYaWipe »

Jcampuzano2 wrote: post #196
localghost3000 wrote: post #148

> And if you’re an engineer, you will be able to retain much higher market value over time if you dig into and understand core web technologies Been working in FE for nearly 20 years and lived through several major paradigm shifts. I think I am qualified to have an opinion here: I definitely think that you will be a more well-rounded engineer if you know all the core web tech. So strongly agree there. I am skeptical,…

Knowing basic web technologies to a deep level are very important and highly valued, especially so at larger companies where they know that the framework itself is a minor detail for skilled engineers who can pick up and be productive in any framework in less than a weeks time, so I do think you can command high market value with very deep knowledge of the platform itself. However, that said I agree with you. Especia…

Lots of reference in these comments to "core" or basic Web technologies. What would you say they are? What's the highest-level thing that's still "core?"

Re: The Frontend Treadmill

#493

Post by tylerchurch »

DidYaWipe wrote: post #492
Jcampuzano2 wrote: post #196

Earlier quoted context omitted.

Knowing basic web technologies to a deep level are very important and highly valued, especially so at larger companies where they know that the framework itself is a minor detail for skilled engineers who can pick up and be productive in any framework in less than a weeks time, so I do think you can command high market value with very deep knowledge of the platform itself. However, that said I agree with you. Especia…

Lots of reference in these comments to "core" or basic Web technologies. What would you say they are? What's the highest-level thing that's still "core?"

I always interpret “core” as “no libraries”. What can you do with just your browser and an HTML file?

Poke through MDN and see what you find.

Do you know about dialog? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...

MutationObserver? https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...

URL? https://developer.mozilla.org/en-US/docs/Web/API/URL_API

Re: The Frontend Treadmill

#494

Post by sgarland »

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

The odds that that person will also understand or care about normalization, let alone the performance characteristics of their RDBMS and how their schema decisions affect it, are close to zero.

I’ve spent enough time watching devs have access to the DB that I know it’s a dead end. For a group that loves to talk about DSA, you’d think a B+tree would be second nature, and yet…

Full Stack is a lie, as is DevOps. We need to return to highly specialized roles. You want a new view? Submit your proposal to the DB team. They shot you down with a list of reasons why? Go learn everything they complained about; next time, the list won’t be so long.

Re: The Frontend Treadmill

#495

Post by default-kramer »

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

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

A million times yes!

> I think the end game is doing SSR of web content inside the RDBMS

That feels like one step too far for me. I think things like authorization and HTML rendering belong in a separate layer.

But I do believe that more than 90% of today's "server side code" actually belongs in the RDBMS, and I blame the weakness of SQL as the reason no one wants to do this.

Re: The Frontend Treadmill

#496

Post by beders »

> Whatever framework you choose will be obsolete in 5 years.

Reagent was born in 2013 and still works just the same in 2025. And it adapted to React changes quite nicely. You won't have to refactor Reagent code from 10 years ago.

Technology and programming language choice matters.

Re: The Frontend Treadmill

#497

Post by [deleted] »

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…

[deleted]

Re: The Frontend Treadmill

#498

Post by ricardobeat »

Swizec wrote: post #477
koreth1 wrote: post #463

Earlier quoted context omitted.

> That people like video formats isn't really surprising to me since it's everywhere, but I still don't fully understand the appeal. Me either, but I have a hunch about why. Are you a fast reader? I am, at least compared to the population at large. And one of the reasons I can't stand video as a format for learning about coding topics is that it is so frustratingly slow compared to my reading speed. To get anywhere c…

Alternatively: you can listen to audio while commuting or driving or cleaning or working out. I love audio for higher level things and to get an overview of the topic. Then text to dive into the details.

It can be quite difficult to follow programming topics over audio only, so it's not interchangeable with video in this case.

Re: The Frontend Treadmill

#499

Post by jwr »

TimTheTinker wrote: post #134
jwr wrote: post #70

Earlier quoted context omitted.

None? I use it from ClojureScript. I've been maintaining a React-based app with Semantic UI for 10 years now.

Do you mean your package.json literally has no dependencies declared (or you don't even have package.json)? If so, you're not using frontend tooling like 98% of development teams.

I don't have a package.json. I don't use npm. But I do use React. Yes, I am not like [insert scientifically determined very very high percentage] of teams out there — but that's exactly my point. There are ways to do frontend development without the treadmill.

Thing is, we are the reason for the treadmill being there: we love the new shiny, we call software that is stable "dead", we actively mock software that doesn't have a lot of churn as "not being developed". So I guess we deserve what we get.

Re: The Frontend Treadmill

#500

Post by nullpoint420 »

koakuma-chan wrote: post #465
nullpoint420 wrote: post #408

Earlier quoted context omitted.

> mostly with web standards IMO, the pain from "mostly" starts to show when integrating React Router v6 with legacy frameworks and applications. I'm sure if you go all in on React Router v6 it's great. At my $DAYJOB we are migrating to Remix w/ GraphQL Federation. It's been a pain. Especially because we haven't finished any of these migrations: * ExtJS -> JQuery * JQuery -> React class components * React class compon…

Remix already has data loading, why add GraphQL? It's a pain in the ass to work with from my brief experience.

That's my point exactly. I have the same questions from leadership.
Post reply on HN