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

271–280 of 722 posts

Re: The Frontend Treadmill

#271

Post by nine_k »

wiseowise wrote: post #204
ewzimm wrote: 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”.

Likely these videos did not exist when your reference / age group was acquiring these skills.

Videos are sort of easier to produce (via screen capture), and are much easier to show the effect of FE things: look, we write code like this, now we can click here, and the page reacts that way. No need to muck with JSFiddle or something.

I'm not a fan of videos as a reference medium, but they can be elucidating to those who needs more hand-holding, literally "click here, see the result". Back in the day, a few short videos about Blender helped me quite bit to grasp certain things that were not obvious from descriptions.

Re: The Frontend Treadmill

#272

Post by numinoid »

bloomingkales wrote: post #239
numinoid wrote: post #234

Earlier quoted context omitted.

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…

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.guide/ which seems to be unaffiliated with the Remix team, and has no section advertising paid courses anywhere. You're talking about a framework that has been acquired and subsequently used in production by a global company in Shopify - clearly there is something to the framework beyond being a vehicle for tutorial sales.

Again, I want to be clear: This is NOT an endorsement of Remix. Your line of thinking seems to be conspiratorial and not grounded in reality. You mention repeatedly about pricing and the end goal of funneling noobs toward course purchases... One would assume that in conspiring to sell courses the team behind Remix might actually advertise that they have courses for sale on their website.

I have to be honest as a third party that a. doesn't work with remix, b. doesn't know anyone who works on remix, c. doesn't know you - it seems like you have a personal vendetta.

Re: The Frontend Treadmill

#273

Post by lo_fye »

I once read an article that promoted putting all of your business logic in the database, in the form of stored procedures, functions, etc. I thought the author was completely insane, until I kept reading. "You can change frontends any time you want, or you can run multiple frontends simultaneously. Everything important, including validation, is handled by the database." Have I done it? No... but that opened my mind to a new way of thinking.

Re: The Frontend Treadmill

#274

Post by [deleted] »

flufluflufluffy wrote: post #266
bloomingkales wrote: post #215

Earlier quoted context omitted.

Here's one: https://remix.run/ These grifters sell entire courses on the product, that's their game. So when you find an unmaintained Remix app at your company, well, the grifters got the ears of your junior devs :( And they just promote it and promote it: https://kentcdodds.com/blog/a-review-of-my-time-at-remix https://kentcdodds.com/blog/why-i-love-remix https://kentcdodds.com/courses Pure grift. But since most peo…

I find Remix really nice to work with, it’s a framework that embraces and utilizes web standards (what the article is arguing we should get back to doing more), and I’ve learned everything I know about it (and the majority of everything else I know about front end dev) for free. It’s not like you need to purchase courses to learn. At the same time, I don’t think there’s anything wrong with selling courses to teach pe…

[deleted]

Re: The Frontend Treadmill

#275

Post by metalforever »

hajile wrote: post #247
zero_shift wrote: post #128

Earlier quoted context omitted.

It doesn't. It's just a meme. React has been around for eleven years now, and complaints about frontend churn started with the Angular 2 announcement (in late 2015)

Churn complaints are older than Angular 2. We'd gone through an entire cycle of churn around templating engines (mustache, handlebars, ejs, jade/pug, nunchucks, underscore, lodash). Gen 1 wars (up through 2010-ish), we had: jQuery-UI, Prototype, SproutCore, YUI, MooTools, Google Web Toolkit, Dojo, ExtJS, BackboneJS, etc. There were no survivors. Gen 2 wars (up through 2015-ish): Angular, KnockoutJS, Ember, Enyo, Reac…

Gen 1 wasn't Gen1. Gen1 for dynamic websites was a lamp stack with yolo javascript in the php header. Then people really started using jQuery because targeting a bunch of browsers at the time was a huge incompatible mess, along with other tools like modernize.js . Then your gen 1 started in earnest, if I remember correctly.

I remember the divisions slightly differently . There seemed to be a core movement from Ember.js and backbone onto Angular. Then from angular to react. Now I am seeing some movement off of react onto alternatives like Vue and Svelte, but almost everyone still is using react. Most shops have issues with the React part of their stack. It's still hard to get buy in for the alternatives in production. No one is using web assembly or even knows what a web component is.

I disagree about the comment about not going wrong with either. This assumes you or your team have the time to maintain the stack with the large amount of dependencies, as there are security patches often and deprecations often. It's a waste when it seems like a large portion of the actual market is just creating dashboard products. You can handle this with a much lighter frontend if you can get buy in (you can't).

Re: The Frontend Treadmill

#276

Post by lars_francke »

guybedo wrote: post #244

LLMs are a huge win in that regard. I delegate most of my frontend tasks to Claude Code, no need anymore to waste hours understanding why the latest version of framework xyz isn't compatible anymore with library abc. Also, it feels like there's way more boilerplate code, repetitive tasks in frontend land, once again my buddy Claude Code can generate UI components html and typescript code 100x faster that i can

My experience is very very different. LLM code is often useless for Frontend stuff for me while it's okay for things like Java and Rust etc.

For frontend stuff the churn seems to be so big that I almost never get valid code because the LLM only know about some old versions or combinations of versions. The "statistical average" they learned is seldom correct for me.

I wonder what we do differently.

Re: The Frontend Treadmill

#277

Post by azemetre »

jchw wrote: post #251
mlboss wrote: post #223

Earlier quoted context omitted.

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 ?

Well, that's just moving the goal posts. I never said you wouldn't have to do any maintenance at all, just that the floor doesn't just fall from under everyone every 5 years. Even outside of frontend, most ecosystems move fast enough that projects from 10 years ago would be in pretty bad shape. That's long enough that even many C/C++ projects will not compile, if nothing else, as a result of improvements to compilers…

I don't think it's moving the goal posts. It's a very reasonable thing to ask. I have Go projects that are now 10 years old that require zero maintenance on my part.

I also do frontend as my day job, and it's extremely hard to get any old react project to work with current tooling. The migration work basically amounts to a total rewrite and that's the issue with react.

Sure if you were using just react that is okay, but how many frontend projects are JUST using react? The issue with react has always been the community surrounding it. Library recommendations that use to be "best practices" get churned into the next thing marketers want to push.

It's very wasteful in our community because we are just tilting at windmills rather than focusing on the harder problems we have to collectively sell. We should start shunning tools that enable this churn, not all frontend communities are like this either but the popular ones seem to be.

Re: The Frontend Treadmill

#278

Post by homebrewer »

rcleveng wrote: post #222
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'm still using npm and wasn't sure if I should use yarn or pnmp, is there a clear winner here on this one? Is there an authoritative place to know which ways the winds of change are blowing on this? I ask since both of them (yarn and pnpm) have recent releases within the last days and weeks.

pnpm saves a lot of disk space by reusing packages and hardlinking (or reflinking if your filesystem supports that) from a single global directory. It's fully transparent for you.

Optionally, it can also use a strict mode (or whatever it's called) where you can only access packages that are explicitly mentioned in your dependency list. Really helps with preventing you from accidentally creating unexpended ties to your transitive dependencies.

Yarn doesn't really have major upsides compared to modern npm if you can't/won't use their package format (which allows for reading files directly from compressed archives, but it comes with a bunch of downsides and doesn't work with all text editors and frameworks).

tldr: I'd recommend pnpm.

Re: The Frontend Treadmill

#279

Post by megous »

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…

As someone who developed web apps since the DHTML days when DOM was not yet standardized,... :)

I'd add another major category and that's ExtJS and friends (large integrated MVC GUI component frameworks), which successfully replicated the [developer] feel of desktop GUI toolkits in the browser, somewhere between your last two categories.

Re: The Frontend Treadmill

#280

Post by frank00001 »

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 is why I stopped doing front end.
Post reply on HN