I love using ai tooling to make frontend engineering trivial. Needs only a minor patch or two but that's enough for me as a dumbass backend/data/distributed systems/site reliability engineer
The Frontend Treadmill
381–390 of 722 posts
Re: The Frontend Treadmill
#382Just write vanilla JS, CSS and HTML. Web standards have improved so much over the past 10 years. You don’t need any of the junk people talk about—not even Tailwind. Not even Svelte. Just KISS.
Re: The Frontend Treadmill
#383> 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…
React today looks very different from React from 10 years ago. Easily as different as being a different framework. So, there is some nuance, but the logic isn't dead quite yet.
Re: The Frontend Treadmill
#384I 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…
And the craziest part is that it is built on top of JS/HTML which is an extremely stable technology at heart. 15 years ago I wrote a small (5KLOC) vanilla JS webapp that is still in daily use by around 10 people without a single line changed. It held up better then my Win32 applications! Almost all of the front end churn is simply a political/organizational failure.
I did that a few years ago and it was fascinating: not only did it remove near-weekly React dependency churn, it produced significant performance improvements (multiple orders of magnitude better update speed - and yes, I did the usual incantations), and the total lines of code in our repo actually went down and it was easier code because it just did what was necessary without having to deal with layers of abstractions designed to work around earlier problems created by the framework.
One of the things I realized while working on it was that it was easy because I’ve learned the web platform over the years and was able to use builtin features rather than reaching for more libraries, but a lot of younger developers only ever really learned React and are stuck the IE6 era it was designed around. That allows them to be productive, of course, but it often means that people take on layers of dependencies because once they’ve invested a lot in that path the cost of switching is really high.
Re: The Frontend Treadmill
#385I have fallen in love with the simplicity of Rails recently. Sprinkle a bit of stimulus where you really need it. Hell slap a turbo here or there. And other than that? Pure HTML. It’s downright lovely. And it’ll still work fine 20 years from now.
Sure, but then your company grows large enough to want its own design system, and you have multiple applications that need shared components. How do you implement that in rails?
Step 1: Resist the urge to overcomplicate.
Step 2: Don't build multiple applications that need shared components.
Step 3: Profit
I slightly tease here, but really these are all leadership decisions that you can simply decide against. I would never implement those things because they're largely profit-less decisions.
Having 2 apps that operate slightly differently is okay—even under the same brand.
Re: The Frontend Treadmill
#386Earlier quoted context omitted.
> it seems like literally everything is deprecated I know you mentioned a company-backed example, but bear in mind most open source libs are given away and maintained for free. After a certain point people move on, so basically what do you expect to happen. I created and maintained a couple libraries for 5+ years and it didn't really help my career or life in any way - no job offers, didn't matter to interviewers, so…
but it doesn't seem to happen the same way in other parts of the programming world. Even in Django, yes, there are squillions of libraries for different things, and many of them haven't been updated in years, but the long-lived ones don't tend to have breaking changes in (at least in my experience). It just seems to be front-end stuff where people will make breaking changes in some long-lived package, and for no obvi…
I mean the browser and security does change somewhat often so there's that.
> Make a new package, or a distinctly different version of the original package that won't get imported by a simple upgrade.
Maybe some of this is cultural or habits, but I've seen projects that do like import "react-router": "latest", and with no package-lock... and I'm like WTF are you doing? That is a recipe for disaster pulling in latest major versions which by semver can and do have breaking changes.
That so many libs take advantage of semver is both good and bad.
Re: The Frontend Treadmill
#387Earlier 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.…
Plain HTML and plain CSS (well, maybe with SASS) are pretty great. Plain JS loses much to plain Typescript though, to my mind.
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.
Re: The Frontend Treadmill
#388> 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…
React today looks very different from React from 10 years ago. Easily as different as being a different framework. So, there is some nuance, but the logic isn't dead quite yet.
I think it's fair enough that libraries and frameworks change in ways that require your project to do some maintenance. I do not get mad when this happens with e.g. Qt. You may argue it happens a lot less frequently with Qt. Fair point, but Qt is very old compared to React. React 10 years ago wasn't even considered stable.
If you keep your dependency list short and make boring choices, your app may not still build with modern dependencies after 10 years of neglect. However, it will almost certainly not need to be entirely rewritten, either.
I think learning the fundamentals is good and people should learn to acquire less dependencies, but going as far as to say you may as well not use a framework because it will be gone in five years... I think that is hyperbolic.
Re: The Frontend Treadmill
#389Just use Angular and stop worrying. Batteries included, it works and works well. Yes there was a big change from v1 to v2, but we are at v19 now I think and upgrades are pretty painless IME (I generally don't even really notice them happening, and there is even a tool to help know what changed: https://angular.dev/update-guide ) I've been using it at BigCos now for years and it's really just totally fine, and importa…
Upgrading to standalone components and the new signal API right now, not sure I’d say this avoids the frontend treadmill
standalone for us was piecemeal - just do it one by one line of code here or there when you are already in the component making other changes.
Likewise signals it was trivial to just change @Input() to input (ok slight simplification but not by much - I think there are automated scripts to do it anyway if you want to do it in one fell swoop?) when already in a component making changes.
But you didn't have to, which is nice. You could take your time doing it but by bit if you wanted, no rush etc. I don't think the old ways are even fully gone yet anyway?
Re: The Frontend Treadmill
#390Earlier quoted context omitted.
Javascript doesn't have a good enough standard library to execute on this. You need frameworks just to patch up the runtime (or otherwise avoid the holes). Last time I checked they didn't even have decent hashmap or set implementations (let alone decent serde support).
Alright, I've been in the industry a very long time but moved to backend when it got complex. I am wondering why you need a decent hash map or set implementation. This is supposed to be done on the backend. The frontend is for presentation. Your backend should not give you elements with duplicates (why you don't need set). "Decent hash map" sounds like you just don't like the hash map implementation because you are t…
[deleted]