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

231–240 of 722 posts

Re: The Frontend Treadmill

#231

Post by koito17 »

mlboss wrote: post #223
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…

Are you using the same version of React that you started 10 years ago? More importantly can you use the React version that was 10 years ago ? Can you even build a 10 year project ?

At a previous job, the frontend was a ClojureScript codebase dating back to around 2013, with a React-based UI. The codebase survived a decade of major upgrades to ClojureScript and React, and many chunks of code in git blame dated back to 2013 - 2014. For reference, ClojureScript's first public release was in 2011, and the React wrapper the codebase used dates back to December 2013.

I think the strong focus on backwards compatibility is what helped ClojureScript (and CLJS libraries we used) stay largely unchanged, but we had plenty of "React code" that wasn't changed at all between 2013 and 2022 since it met business requirements and "just worked".

Unfortunately, I don't work there anymore, but I don't see why it'd be impossible to build the early version of that frontend today. Recently, I've been using TypeScript for frontend, and the codebase is still surviving major upgrades to React, TypeScript, and the various libraries we use.

However, I will admit that the pace at which libraries release is extremely fast compared to other ecosystems I'm familiar with (Clojure, Java, Rust, etc.).

Re: The Frontend Treadmill

#232

Post by barrell »

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…

This has been the most amazing thing about ClojureScript - finding libraries that are 10+ years old without an update still work perfectly. Using reagent and over time learning more and more of the internals (instead of the runaway treadmill in js land).

I do miss some of the dynamism of the JS ecosystem from time to time but it’s really nice to step off the proverbial treadmill.

Re: The Frontend Treadmill

#233

Post by qudat »

mangodrunk wrote: post #45
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.

Well said. The BE / FE split has been a really bad experiment. It has exasperated the issue where the FE is overly complex because there are people on a FE team, so they toil away and just add complexity. It is also problematic that we have so many people who only know web development and nothing else.

This comment is steeped in bias. The front end is not complex for its own sake, it’s complex because APIs are needlessly rigid: https://bower.sh/front-end-complexity

Re: The Frontend Treadmill

#234

Post by numinoid »

bloomingkales wrote: post #220
numinoid wrote: post #216

Earlier quoted context omitted.

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

I think that adds to my point. How does that have so many stars on github? The customers "star" it. Who uses this on a real app? It's alright to slowly accept the bitter truth that grifting scales.

Not really sure that's relevant. Grift implies an intentional value extraction without providing anything. Using your example: I'm confident that the time spent working on remix and courses related to it resulted in far less monetary gain than spinning out courses on React. If you think Remix is misguided or a bad framework etc... that is very different from grifting. A corollary: Is Deno a grift because it shares the same creator as Node and has a paid product attached to it? In my opinion no but you might disagree... I'm mostly opposed to the idea remix in particular exists purely as a grift - love it or hate it there are far easier ways for someone with the influence of Kent to make money.

Re: The Frontend Treadmill

#235

Post by porterehunley »

hombre_fatal wrote: post #181
mplanchard wrote: post #92

Earlier quoted context omitted.

I agree you can avoid it with care, but I do think it's a JavaScript problem, at least moreso than in other languages. The culture is one of acceptance of churn. It seems like everything from minor libraries to major frameworks is much more likely to introduce a breaking change in JS than in Rust, C++, or even python. I've never written any emacs lisp that I had to change when upgrading emacs, and the third-party lib…

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…

This is strange to hear because I switched over to SwiftUI/Native from web-based(react native) because I was so frustrated with the JS UI ecosystem. I would be stuck for a long time from conflicting package dependencies after updating/adding a new library. JS seems like the only ecosystem where adding a few simple libraries results in hundreds of added packages.

Re: The Frontend Treadmill

#236

Post by jchw »

endemic wrote: post #224
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…

It's not just React, but all the other rando packages that your co-workers installed.

Yes, exactly. Please stop doing that! It's not only bad for maintenance to install random packages that get maintained for a couple years (or sometimes barely any time at all,) it's also bad for your bundle sizes. It is annoying having to do a lot more stuff by hand, but it's really not that bad.

If you're going to choose third party packages for something, at least vet that they have good support, are backed by a developer or entity that has been around for a while, and that the library itself is sufficiently mature.

Re: The Frontend Treadmill

#237

Post by wolvesechoes »

hombre_fatal wrote: post #181
mplanchard wrote: post #92

Earlier quoted context omitted.

I agree you can avoid it with care, but I do think it's a JavaScript problem, at least moreso than in other languages. The culture is one of acceptance of churn. It seems like everything from minor libraries to major frameworks is much more likely to introduce a breaking change in JS than in Rust, C++, or even python. I've never written any emacs lisp that I had to change when upgrading emacs, and the third-party lib…

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 release?

- Win32, and frameworks built on top of it like MFC, WinForms, WPF?

Yeah, we are SO lucky we've got JS ecosystem. It is impossible to think how people lived without it.

Re: The Frontend Treadmill

#238

Post by fourneau »

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've been working on a small side project on-and-off for the last year and some. The state-of-the-art decisions I made last year are already dead. There's a new version of everything, and everything was a breaking change, nothing is backwards compatible.

How do people live like this?

Re: The Frontend Treadmill

#239

Post by bloomingkales »

numinoid wrote: post #234
bloomingkales wrote: post #220

Earlier quoted context omitted.

I think that adds to my point. How does that have so many stars on github? The customers "star" it. Who uses this on a real app? It's alright to slowly accept the bitter truth that grifting scales.

Not really sure that's relevant. Grift implies an intentional value extraction without providing anything. Using your example: I'm confident that the time spent working on remix and courses related to it resulted in far less monetary gain than spinning out courses on React. If you think Remix is misguided or a bad framework etc... that is very different from grifting. A corollary: Is Deno a grift because it shares th…

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 this. It's a rabbit hole for both you and me to keep going at this, as I've seen enough of this pattern. Consider me a neural net on this front (end).

Re: The Frontend Treadmill

#240

Post by bob1029 »

koakuma-chan wrote: post #211
bob1029 wrote: post #80

Earlier quoted context omitted.

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

> I think the end game is doing SSR of web content inside the RDBMS OR just embed the RDBMS into your application!

SQLite is certainly a very good option. You could bind a handful of UDFs and turn it into a poor man's Oracle stack.

https://www.sqlite.org/appfunc.html

Post reply on HN