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

431–440 of 722 posts

Re: The Frontend Treadmill

#431

Post by makeitdouble »

divan wrote: post #195
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…

The worst thing is that it's a cultural aspect. This deprecation and breaking stuff hell is a result of millions of micro-choices. "Why not rename MultiselectDropdown into MultiSelectButtonDropdown! And maybe replace the API of that component to a completely new one! Sounds like a cool idea!". Thousands of person-hours are spent daily for fixing results of such 'extremely important'™ breaking changes. There is simply…

I think that culture will happen somewhere anyway, and FE being the battle ground is probably because it's the most visible part of the experience.

I mean: some people will want to reinvent the wheel, and preferably carve their name in some monument while doing so. And there will also always be an impulse to create busywork as it's the tide that rises all the boats, inflating the workforce in the field.

The staggering costs of breaking APIs is to some a feature, not a bug, and the field will attract more and more like-minded people who then accelerate that trend.

To note, BtoB focused startups usually go for a completely different FE stacks, including long deprecated ones, or even plain staticly generated sites wherever they can get away with it.

Re: The Frontend Treadmill

#432

Post by ryan-duve »

krainboltgreene wrote: post #14

Giving up on that treadmill after investing 3 insanely intense years consuming everything about it was the best thing I ever did. Now I write elixir (phoenix liveview), sometimes I write javascript (phoenix hooks), sometimes that javascript uses Alpine. Zero pain. I have never felt more vindicated understanding HTTP, Hypermedia, and HATEOAS than I have in the last three years.

I've only used Elixir/Phoenix as the backend with Elm as the frontend. If you're familiar with that, can you TL;DR what Phoenix Liveview does differently than a Phoenix/Elm/GraphQL stack?

Re: The Frontend Treadmill

#433

Post by DangitBobby »

jf22 wrote: post #133
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.

Then you aren't doing what the author is talking about.

The new insight then is if you do things then bad things will happen?

Re: The Frontend Treadmill

#434

Post by eddythompson80 »

divan wrote: post #195
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…

The worst thing is that it's a cultural aspect. This deprecation and breaking stuff hell is a result of millions of micro-choices. "Why not rename MultiselectDropdown into MultiSelectButtonDropdown! And maybe replace the API of that component to a completely new one! Sounds like a cool idea!". Thousands of person-hours are spent daily for fixing results of such 'extremely important'™ breaking changes. There is simply…

> Which somehow affects Go library developers stance on compaitbility and breaking things. The code written 10 years ago perfectly compiles and work on latest Go version, and it's such a wonderful experience.

I'm assuming you mean against go stdlib? Because sure as hell that's not my experience upgrading random go dependencies. Mostly use go in the Kubernetes/cloud ecosystem and upgrading the dependencies is an extremely painful exercise as most libraries seem to keep renaming and shuffling their APIs.

Re: The Frontend Treadmill

#435

Post by tshaddox »

cmgriffing wrote: post #372
tshaddox wrote: post #259

Earlier quoted context omitted.

I think you're mistaken. I can't comment on the quality of Kent C. Dodds' educational content, but his formal affiliation with Remix was short-lived. The courses that he sells have no apparent affiliation with Remix (the open source project or the company). Incidentally, Remix is an open source project started by the React Router devs to create more framework features around React Router. React Router is probably one…

While his formal affiliation may have been short-lived, do you think he got a cut of the sale to Shopify? If so, not disclosing that when he promotes Remix is a bit shady. Nice dude and all, but that is one thing I take issue with still.

I don't think it's weird to like a piece of software and have that lead you to work at the company that builds the software and also to develop an educational course about that software.

Re: The Frontend Treadmill

#436

Post by worik »

whatamidoingyo wrote: post #83

I had this same mindset when React started gaining popularity. "Vanilla JS all the way". Then I saw the power of React, and fell in love with it. Then I landed a position that uses jQuery and Vanilla JS for everything a few years later... and oh my. It's absolutely awful. I know, I know, vanilla JS is most likely going to work in 5+ years as opposed to the React codebase, but damn. Wretched.

> but damn. Wretched

I am curious.

I know no React. I am neck deep in vanilla TS (not JS, small mercies)

What is "Wretched"?

My needs are simple (nobody at my org gives a single care about beautiful pages, it is an interface to an industrial process - big, feature-full interface, but not public nor a selling point)

Re: The Frontend Treadmill

#437

Post by throwaway92432 »

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…

Many bring the same mindset to backend as well. In my small team of less than 10 developers we use C#, Java, Kotlin, Rust, Elixir, Go, Javascript, Typescript, and Python to worry about and maintain because developers have been allowed to pick what they want.

I have stopped caring about how incredibly short sighted this is, and just think of it as experience that improves my resume

Re: The Frontend Treadmill

#438

Post by Kerrick »

Eric_WVGG wrote: post #210
Kerrick wrote: post #136

Earlier quoted context omitted.

I also left out Qt, Swing, etc. on the desktop. I'm comparing a direct lineage of replacements, not showing diversity of choice.

Hi, I've been a web front-end dev for 25+ years. I have no idea what Backbone is/was. There's no direct lineage there, I think that's a sort of forced reading. Also the whole notion of a "front-end vs back-end" division only covers part of the web's history. imo a real "lineage" would be something like… - pre-AJAX, server-rendered sites (PHP, JSP, ASP, ColdFusion; no division of front/back-end) - the monolithic frame…

Backbone sat right between the jQuery sprinkle and reactive frameworks era. It popularized a bunch of important concepts that quickly led to the next era:

- storing data in JavaScript, not in DOM elements

- separate models and views before JavaScript even had the class keyword

- decoupling from your back-end through a RESTful API

- templates that would be filled with data in the browser

- client-side routing

However, it was not in the same league as reactive frameworks like Angular.js or Ember. It was missing two big things, which destined it to be a bridge from the jQuery era to the present.

- Reactivity that stretches to the DOM. Backbone's views had a `render` hook you had to implement that expected you to either replace the HTML wholesale or go fiddle with the DOM yourself.

- Partials or Components. Backbone didn't support subviews at all.

Re: The Frontend Treadmill

#439

Post by [deleted] »

tonyhb wrote: post #420
cmgriffing wrote: post #372

Earlier quoted context omitted.

While his formal affiliation may have been short-lived, do you think he got a cut of the sale to Shopify? If so, not disclosing that when he promotes Remix is a bit shady. Nice dude and all, but that is one thing I take issue with still.

There are only a few popular, promoted alternatives to NextJS right now (that I know of): Remix and TanStack. That is, if you're fully React focused, ofc. I dont see promoting Remix as a red flag.

[deleted]

Re: The Frontend Treadmill

#440

Post by [deleted] »

koakuma-chan wrote: post #314
homebrewer wrote: post #249

Earlier quoted context omitted.

E.g. react-router was ready 5990 commits ago. It is a grift, they keep rewriting it and reengineering the API over and over and over again just to be able to sell more training. Look at wouter for what is possible if your motivation isn't selling training material. It was written and left alone, it works just as well, it's stable and doesn't change for no reason.

Do you know anyone who bought courses on react-router? The documentation is right there for free.

[deleted]
Post reply on HN