23 ms·

The Frontend Treadmill

• mplanchard 2y ago
  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 different configuration and doesn’t support all the same options. Okay, so we just keep the old one and disable the node engine check in pnpm that makes it complain. Want to do a patch upgrade to some dependency? Hope you weren’t relying on any of its type signatures! Pin that as well, with a todo in the codebase hoping someone will update the signatures. Finally get things running, watch the stream of hundreds of deprecation warnings fly by during the install. Eventually it builds, and I get the hell out of there. It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc. I’ve been working on a large rust project for nearly four years and in that time there have been a few minor breaking changes in or of third party libraries, but only one major breaking change that required significant changes to our application. Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. It’s bananas. Okay, rant over.
  • __loam 2y ago
    GraphQL is such an exciting addition to the front end stack. Imagine, an entire new system you need to learn that cargo cult proponents love and also sucks ass to use.
  • SamuelAdams 2y ago
    I agree, it seems like popular packages really need an LTS release channel or something. Enterprises do not have budget or time to continuously invest in their front end tools. Meanwhile, compared to something written in dotnet or go. I bet there’s a very strong chance those projects will continue to work in 3-5 years.
  • fragmede 2y ago
    Wait, we're supposed to use pnpm now? What happened to yarn? What's wrong with npm? I stop paying attention for six months and even the installer has changed. What's an npx?
    • mplanchard 2y ago
      Right??? I started out the process trying to stick with yarn and upgrade it to use plug and play for better CI caching, but svelte apparently just does not work with it and will not do so, so I started looking into pnpm.
      • fragmede 2y ago
        Meanwhile, I had to do some backend thing yesterday, and ended up using the LD_LIBRARY_PATH trick, which was introduced in 1988. I'm grateful that LLMs are great at writing frontend code for me, though the broader implications are a bit scary.
        • soco 2y ago
          But can a LLM help writing code for a library released or updated a few months ago, covering the implied breaking changes? With the way they work today, probably not.
    • genuine_smiles 2y ago
      Yarn is still great. npm is ok. pnpm is a little faster than Yarn but has less features.
      • evrybdygonsrfin 2y ago
        Hardly a deal-breaker; presumably I can just pipe the output to less.
    • chrisldgk 2y ago
      Main difference between all of them is speed. There’s some differences in how npm, yarn, pnpm or bun handle workspaces and hoisting (and stuff like dependency overrides) but if one of them works for you, you rarely have to switch between them. Edit: also npx is just an alias for npm exec, allowing you to run scripts in npm packages
  • gtsop 2y ago
    This is exactly why I am a huge fan of ember.js Unfortunatelly it fell behind in popularity mostly due to some unimportant reasons (eg not being able to render 1M rows faster than react) and some important ones (load times), but boy did they build a stable ecosystem! I haven't seen such a commitment to stability and guardrail upgrades to this day on any other piece of front end library.
    • jmnicolas 2y ago
      I'm thinking of building a long term living app (say an app that I will use the next 30 years). It has to be a web app so I was thinking of going pure JS. With that requirements in mind would you recommend ember.js?
      • vijaybritto 2y ago
        Go for web components. It's guaranteed to last 30 years
      • whism 2y ago
        If you are designing for that kind of long term I suggest looking into SmallTalk. A lot changes in 30 years.
      • solid_fuel 2y ago
        I know this is kind of the contrarian opinion and I'm not trying to be "that guy", but if you want a web app that works in 30 years you would probably be best off building a server-side rendered application. You need a server, HTTP, HTML, and CSS for any web application, but you don't always need a lot of client side javascript. The fewer things you have in your stack, the fewer things can change under your feet.
      • gtsop 2y ago
        If you MUST use a framework, then yes i would go with ember because they have a prooved commitment to following the web standards rather than creating their own custom standards that they throw away the next year. Having said that, 30 years are very VERY long time in web development. Maybe pure js isn't a bad call, but it depends on how large it is going to be. Someone else mentioned considering sever rendering, not a bad cinsideration either.
  • fridder 2y ago
    This is why I have been so pumped for LiveView. It just removes so much javascript from the equation
    • paradox460 2y ago
      And when you need to use JS, you can do so in a clean and controllable way. Using Liveview to mount and unmount custom vue components can give you an extremely nice workflow, where you can just treat a complex select (akin to select2) as another type of input Be sure to check out surface-ui. Marlus is a great guy, and surface really feels like the missing piece of liveview https://surface-ui.org/ https://surface-ui.org/
  • diggan 2y ago
    > Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. It’s bananas. The thing is, it's totally possible, but it requires restraint and properly caring about what you pull into your project. Back in the vanilla JS/jQuery days, when I got started, our "dependency management" was basically copy-paste .js files into a `vendor/` directory. Then nodejs/npm appeared (and bower, which FE used before using npm), and suddenly the advice became to just not program those things yourself, download the module. But already at that point, a lot of us questioned the idea of owning thousands of hidden lines, rather than explicitly owning those, and outsourcing everything to volunteers who basically do FOSS for fun. Even today, it's possible to care about your project enough to not bloat the invisible parts too much, if you want to be able to continue to work on the project. Again, requires restraint, and going back to the "I only need a function from this library so instead of depending on the entire library, lets just copy-paste this function into our codebase and add some tests" way of dealing with minor things. So I guess what I'm ranting about, is that this is a people and process problem, not a JavaScript problem, because there are a lot of us JS developers who don't suffer from this problem, while large parts of the ecosystem does.
    • mplanchard 2y ago
      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 libraries I use there also tend to deprecate things rarely and carefully. But, if we stop working on a JS codebase for more than a few months, there's a very real chance that it will no longer build with current tools or that an upgrade to fix e.g. a security vulnerability will turn into a gordian nightmare.
      • schindlabua 2y ago
        And I think the Javascript problem exists because frontend/UI is just a very complicated domain, in the sense that frontend is a big messy ball of side effects. If you've been around and saw the web grow up, and saw all the new ideas all those libraries brought to the table (jQuery deferreds becoming async/await, 960 grid slowly morphing into flexbox and css grid, etc etc) then all the breaking changes make sense, we're still in a discovery stage in the frontend. Though now that I'm not doing much FE these days I get a feel for how frustrating it is to keep up to date. The current metaframeworks also solve interesting problems (that I'm not sure I had tbh) and no doubt new web standards will follow from them. But yeah if you're a new developer who doesn't have all those years of context it must be insanely confusing to swim in a sea of libraries and frameworks without having a good grip on the core web platform.
  • hajile 2y ago
    There's a disconnect between how a computer wants to do things and how a human wants to do things. This disconnect isn't so noticeable on the backend where the problems are generally related to scaling (as there isn't a generalized solution). On the frontend though, this disconnect is everything. This leads to a tension between devs wanting to abstract and everything constantly breaking the abstraction rules. This leads to a loop of unrealistic optimism. 1. Library X promises to abstract everything away in an easy-to-use way 2. Devs adopt X and it makes work fast and fun. 3. The human element forces in tons of edge cases. 4. Devs hit the abstraction limit and start needing elaborate workarounds to do simple things. 5. Devs start looking for an abstraction that works and goes back to the first stage. I'd note that a decent portion of this loop is powered by the explosion of FE devs. There were probably just a couple hundred thousand frontend people when Chrome launched in 2008 (and most of them were design guys rather than programmers). Today, there are millions and most of them have been programming for just a couple of years. Devs (especially senior devs who make architecture/library decisions) and their managers need to realize that there is no panacea. Fast time to market followed by slowing development speed is expected. It seems like every blog brags how "we rewrote 80% of our app in 3 months" but seldom mentions that they are still at just 95% done 3 years later. If you started with React in 2013, you'll still be using it 12 years later (11 years if you were using Vue). If you stuck with Redux, you'll still be using it 10 years later. If you used basically any of the abstractions layered on top of these basic libraries, you have probably been through several rewrites none much better than the previous. The key is not abstracting too much. Repeat yourself just a little more and you'll find the edge cases easier to deal with and changing something basic in 5 files is easier and faster than trying to wade into a single very complex component and change something. You'll find that lots of those abstraction libraries you were using aren't actually buying you much at all. I should also mention Typescript. Basic types are a great resource. When you are spending hours wrangling your complex type soup to fix something you know can be solved with just one simple change, this is an indicator your types are hurting your project. These types are almost always a reflection of your abstraction and indicate that you are abstracting too much. These types also indicate your code is highly polymorphic and will have terrible performance on modern JITs. DRY is a means to an end rather than an end in itself.
    • skydhash 2y ago
  • blueflow 2y ago
    laughs in C99
  • gedy 2y ago
    > 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 why would I bother?
    • mplanchard 2y ago
      Ya for sure, I’m not ragging on the small library devs. Mostly that’s not where the problem is anyway, because they tend to do a small subset of things reasonably well and so there’s not a lot of reason to change.
    • niccl 2y ago
      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 obvious reason. Make a new package, or a distinctly different version of the original package that won't get imported by a simple upgrade. Or am I missing some reason that it's not as simple to do this in front-end stuff as it is in other areas?
      • gedy 2y ago
        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.
  • 0x000xca0xfe 2y ago
    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.
    • anthropodie 2y ago
      I build simple applications for personal use like issue tracker, day planner, etc,. By default if you ask Claude it will generate React for frontend but I ask it to use HTML/CSS/JS instead. Because as a backend developer that makes sense to me. I find it hard to read the react code and want to avoid having dependency on npm. It's surprising how well the core technology works without fancy front end frameworks. Claude does most of the grunt work related to CSS/JS allowing me to focus on more interesting things. I only have to do few minor changes here and there which I am happy to do.
      • 0x000xca0xfe 2y ago
        Yeah it's surprising how easy many things really are. I asked Claude to spice up another vanilla JS/HTML app with a Material UI like touch ripple effect and... it simply did. Was just around 100 lines of CSS/JS. No need to rewrite everything.
      • tajd 2y ago
        Yes, 100% this. I’ve seen this idea before somewhere, but I wouldn’t be surprised if people started to basically develop more of their own software from first principles like this. I was doing it today to create a gantt chart from mermaid. I’ve built other applications inside react components as react seems relatively stable - I don’t really care about react though, only that it has a lot of training data for it.
      • ericmcer 2y ago
        Of course it works without frontend frameworks, but if you develop a frontend application using plain JS your core problem is still the one frameworks solve: syncing your application state with the DOM. At first you can do this manually using selectors, but a complex app will need to be capable of doing this to hundreds of elements whenever state changes. At that point you will build some kind of abstraction because manually updating every element would be insanity. That abstraction might be a simple virtual DOM, and now you are halfway to building your own React.
  • locallost 2y ago
    decides to swap out a working package manager for another for no apparent reason "Why do JS people keep doing something new for no apparent reason?"
    • koakuma-chan 2y ago
      I'd gladly swap out any piece of tooling if it's written in JavaScript.
    • mplanchard 2y ago
      The reason was that I was trying to use a newish feature of yarn (plug and play) to improve CI caching. However, it refuses to play nicely with svelte. pnpm provides similar benefits but works with svelte.
  • uoaei 2y ago
    My conspiracy theory is that FE engineers do this on purpose for job security. Otherwise there simply wouldn't be enough work to justify headcount and salary. Of course there's very few actually devious people who do this on purpose, but who among us hasn't thought "tickets are light this week, how about if I upgrade xxx or yyy?"
  • taeric 2y ago
    Fully agreed that the amount of "that was last year's answer" is obscenely frustrating. Would be one thing if there were minimal boilerplate for the options, but so many patterns are quite involved.
  • Aurornis 2y ago
    > It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc. I’m amazed at how much of this is driven by the FE influencers. The FE world has embraced social media, YouTube, and even Twitch to a degree that I haven’t seen in other domains. Influencers in these areas need to have a constant stream of fresh material to stay relevant, so they’re always driving toward something new that they can produce content about. This is in addition to the very active conference circuit. FE and JS conferences feel like one big competition to present on some hot new topic. There’s also a huge market for selling FE courses. These course creators need you to convince your boss to approve a $700 (limited time price!!!) video course to learn the new hot thing, but they can only do that if they get the industry to move away from the old thing that everyone knows already. So they push hard to drive the new thing and deprecate the old thing.
    • ewzimm 2y ago
      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 really surprising to me since it's everywhere, but I still don't fully understand the appeal. Even if you were raised on video content and started coding that way, at some point you have to reference text documentation, right? At that point, I would think you would just stick to the text and not go back to the video, but maybe it's just more entertaining the other way.
      • wiseowise 2y ago
        > 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”.
        • 2y ago
  • pmarreck 2y ago
    It's more or less always been like this. It's why I moved to mainly backend (where feasible). Because someone has to maintain that crap at some point.
  • sergiotapia 2y ago
    one wonder how this liability of a tech stack became so popular. i have a theory it was VC dollars pumping up a ton of saas tools and they all came out with one-click integrations. this is one house of cards that may never really be fixed.
  • divan 2y ago
    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 no culture of understanding the staggering costs of breaking APIs. This is especially frustrating after working for a decade with Go, that has backwards compatibility promise. 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. One of the ways of escaping this JS/web hell for me was switching to Flutter. It worked great, most of the web-stack accidental complexity was happily forgotten. But this culture of "breaking package is fine" creeps in into Dart ecosystem as well, and it's annoying as hell.
    • wiseowise 2y ago
      > But this culture of "breaking package is fine" creeps in into Dart ecosystem as well, and it's annoying as hell. It’s almost like this has nothing to do with technology and is more result of a barrier of entry that is one step about nocode solution.
    • evantbyrne 2y ago
      I suspect the cultural issues with JS primarily boil down to the fact that every org needs JS, which in turn results in 1) a glut of junior/mid devs and 2) it naturally being ground zero for hype cycles. At this point I honestly wonder if most orgs should even hire for JS skills, or if they would be better served by hiring backend engineers and training them to write progressively enhanced UIs.
      • bloomingkales 2y ago
        The thing is brilliant UI engineers will stun you with incredible UI. It's almost like not investing in AI, you will get blind sided by products that just look and feel better. Your backend engineers are never going to cut it. This is true for backend engineers too, if you try half ass it with "full stack" devs, brilliant backend devs will stun you with things and your products will be inferior. For example, we all got stunned by the machine learning people. We have to pay attention to everyone.
  • emseetech 2y ago
    Ironic that FE dev is built on HTML and CSS, two specs that are so painfully backwards compatible that the original Space Jam website from 1996 still works. A web app written with HTML and CSS and a sprinkling of no-build Javascript will likely work as intended in 30 years.
  • powersnail 2y ago
    That matches my experience as well. Google something, find the documentation, go to the documentation, and "We have moved our documentation to a brand new experience", and the link is to the home page of their new website, so you need to redo the search. X has been deprecated; Y is the replacement; and they provide the same functionality with a completely different API. It just does not make sense to me why Y is created, rather than having X's implementation replaced. A lot of documentations/discussions are also written with the assumption that you are migrating from the previous approach. So if you just dive in and don't have the context of what used to be the way, it's sometimes difficult to understand what they are talking about.
  • rcleveng 2y ago
    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.
    • homebrewer 2y ago
      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.
      • rcleveng 2y ago
        Cool, thanks! I've not anything this succinct between them before.
        • mplanchard 2y ago
          I agree with their assessment. It uses some nifty storage tricks and I really appreciate the ability to know when packages are accidentally depending on dependencies they haven’t declared.
  • barrell 2y ago
    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.
  • fourneau 2y ago
    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?
    • DidYaWipe 2y ago
      They don't. They say fuck it and learn a trade.
  • skeeterbug 2y ago
    I recently had the opposite experience. App was built in older version of React/MUI/CRA/tsc (project started in 2020). I upgraded everything to latest, removed CRA for vite, and it just worked for the most part (vite has some docs for upgrading from CRA). MUI had a few things deprecated, but it didn't break. Removed the yarn lock and switched everything over to vanilla npm now that it has package locks. Took < 1 hour.
  • frank00001 2y ago
    This is why I stopped doing front end.
  • golergka 2y ago
    Can we make something like a “non-deprecation” pledge for libraries? Just make a public commitment on the top of your readme file saying that you will maintain backwards compatibility in your API for at least a couple years. This will make me choose your library over others.
  • cxr 2y ago
    > Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. And by "in JS", you really mean, "in NPM land". So long as folks keep remaining seemingly (almost willfully) ignorant of the source of their pain and/or running right back into the fire the next time the opportunity presents itself, that pain is going to continue. NPM sucks. It's not the way to do JS. Everyone who has ever experienced it and then written a complaint about it should be more than willing to accept this. For whatever reason, though, they aren't. (My hypothesis? They like being able to write about their pain because it gives them something and someone to kvetch about/to. See Aurornis above/below on the role of social media and influence in "FE" (i.e. browser-focused software development), and Alex Danco's "Making is Show Business Now" <https://alexdanco.com/2020/10/08/making-is-show-business-now/ https://alexdanco.com/2020/10/08/making-is-show-business-now...>.)
    • bobthepanda 2y ago
      the problem is that as with everything else in FE it is kind of hard to tell what successor framework will "win" and not do this to you. Svelte and Vue were nice and stable until they were not, Deno as an alternative to NPM kind of never got any traction, and unfortunately no one has come up with a better sandbox that works the same everywhere other than the web.
      • deleted 2y ago
        [deleted]
      • rollcat 2y ago
        I understand why they had to EOL Vue 2 and make Vue 3 - I'm still facing migrating a couple of projects at some point, and I will keep putting it away x) But is upgrading Vue 3 across minor versions that much of a pain? Actually curious about people's real world experience.
    • wruza 2y ago
      Also by “npm land” you mean “react-webpack-based bloated build- and eco-systems”. NPM sucks. It's not the way to do JS ${X}PM is absolutely the way to do $X. You can’t survive without the PM part. You just have to know cancer when you see it and call it out rather than praising.
  • jdauriemma 2y ago
    Hi there - I work at Apollo and I'd be happy to help you migrate off our old CLI. That utility was sort of a hodgepodge of tools that we ended up either replatforming to our `rover` CLI or, in the case of code generation, recommending that folks use GraphQL Code Generator. It's a testament to that utility's sprawl that I can't guess your use case just by your name-drop of it. I realize the irony in my saying that since it sort of plays into this narrative, but FWIW all the functionality (and then some) of `apollo` is still actively maintained, just not in that particular codebase or form factor. Let me know if there's anything I can do to assist. FWIW Apollo Client is actively maintained, has a lot of new features, and is preparing a v4 release (currently in Alpha). We'll be celebrating 10 years next year :)
    • mplanchard 2y ago
      I appreciate this! It is the codegen part, but because it’s in a repo that mostly is just getting bugfixes until we eventually subsume it all with something newer, it’s hard to justify the time spent to migrate to a different tool. The issue I was having with pnpm was that it wouldn’t install the apollo CLI tool due to its having set a required node version that is now quite old in its package.json. I was hoping the graphql codegen options would be more similar, but after about an hour of trying to figure out how to get it to generate approximately the same output I gave up. I’ve worked around it for now by using `pnpm dlx` to use the old apollo CLI without having it as part of the actual package dependencies.
      • jdauriemma 2y ago
        That's a start! Forgive me, I'm heading into a meeting but I want to share some resources with you. It's close to the end of my day so I'll check back in the morning. If you prefer to continue the conversation on another platform, I'm happy to exchange emails or Discord handles. Also consider posting at community[.]apollographql[.]com, the Apollo Client team tries its best to respond to everyone who asks for help there. Any code snippets would be helpful to illustrate observed vs. ideal state when migrating.
      • jdauriemma 2y ago
  • KronisLV 2y ago
    The other day, I needed to quickly whip up an internal dashboard with some dynamic logic. Being somewhat lazy, I just imported jQuery and some additional scripts for it, one of the small CSS-only libraries for basic styling, put all of the custom code in a single JS file and that's it. No toolchains. No build process. No learning about any particular way of doing state managing or rendering or what have you. Just some files and some code. It was delightfully simple. For bigger projects I do think that the likes of Vue strike a nice balance between features and usability, but I've also seen a lot of messing around with toolchains and package versions (or even stuff like needing to migrate away from AngularJS), sometimes it's nice to avoid all of that when you don't need that complexity.
    • cosmic_cheese 2y ago
      > No toolchains. No build process. No learning about any particular way of doing state managing or rendering or what have you. Just some files and some code. To me this experience was once upon a time the single biggest selling point for the web as a development platform, and yet everyone is so eager to wade neck-deep into ever-changing library and build chain cruft instead. It’s mystifying.
  • 230nanometers 2y ago
    One of many reasons I left FE jobs. I'm tired of spending my evenings discovering what refactor I'm gonna have to do next.
  • jongjong 2y ago
    Part of the problem is that React monopolized the entire space and most other frameworks became legacy; not able to maintain even a tiny community. The sad thing is that React's success, much like its parent company (Meta) is due primarily to network effects and not to merit. This is why frontend development is so bad these days.
  • squidsoup 2y ago
    You could make exactly the same complaint about python packaging. We've gone from setuptools, to pip, to poetry and now uv.
  • zeroq 2y ago
    This. I have a pet project (let's call it home brew Plex) that I've started some 10 years ago and every 2 years I come back to it with the same experiment - let's see what do I have to change to be in line with the current javascript trends. And every time it leads to a complete rewrite. And I'm not talking about changing Angular to React -- I'm talking about fundamental shifts in paradigm, tooling that falls apart, and a brand new feature that everyone has to use this season. The paradox is that I've started my career 25 years ago doing frontend - in flash, as JS was almost noexistent in it's current form back then - and still when I have to do small eyecandy or experiment I like to use plain old ES3/ES5 JS that I can author in a notepad and run directly in a browser without needing a tooling pipeline that would put a blush on most game developers. I think it partially comes from the fact that JS as a modern, full fledged programming language came out of the blue, with sudden demise of flash, catching everyone by surprise. I remember when companies started shifting to js and asking for senior frontend programmers back in the days. I was thinking to myself - hey, if you want someone with 5 yoe with JS in 2013 then most people in the market will be experts on jquery plugins, not serious programming. And I think that's the reason why the community as a whole keeps reinventing the wheel and trying to prove themselves so hard.
  • throwaway92432 2y ago
    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
    • switch007 2y ago
      > because developers have been allowed to pick what they want. That's a technical leadership failure first and foremost
  • graynk 2y ago
    I fully agree, _but_ it's not just frontend, it's the entire NPM ecosystem. Meaning it's not much better in NodeJS (or Deno/Bun/whathaveyou)
  • cosmic_cheese 2y ago
    Meanwhile, I can go dig up some open source Objective-C/AppKit Mac app project that hasn’t seen any activity in 20 years and probably get it compiling and running in an evening. Cleaning out warnings might take a weekend. I wonder what it’d take to achieve that kind of stability over time in the web front end world…
  • deleted 2y ago
    [deleted]
  • kamaal 2y ago
    >>The most frustrating thing about dipping in to the FE is that it seems like literally everything is deprecated. I build a lot of FE stuff for internal company tooling. Production, monitoring, dashboards etc. Its crazy how the React ecosystem works. Like you can come back after two years to add a feature and realise you now face weeks/months of migrations tasks before you even begin to add the features. I always compare this to something like say Java. Imagine if Java deprecated and broke everything every 2 years or so. Imagine the omni present migrations projects in the backend. Sometimes I think this is why banks, and other places that need long term stability are still on php+jquery+LAMP stack.
    • Auracle 2y ago
      I’m getting back into development after being a photographer for the last 10 years and after reading your comment I thought “maybe I should apply at a bank…”
  • brightball 2y ago
    This experience is one of the reasons people love Phoenix LiveView so much.
  • deleted 2y ago
    [deleted]
  • johnfn 2y ago
    As a primarily frontend engineer who has "spent plenty of time in the Python mines", I feel exactly the same way. Oh my god, Python is a horrific mishmash of deprecated and impossible-to-upgrade libraries and dependencies. Honestly, I think it's significantly worse than the frontend - at least with the frontend, the scope of the damage is limited by TypeScript and the language limiting you to doing relatively sane things. In Python, you can do LITERALLY EVERYTHING, which leads to library authors doing LITERALLY EVERYTHING. Want to change how modules are imported? Go for it! Want to make a metaclass and break all assumptions about how a class operates? Have fun! Think your static typing will help you? Good luck - you can't even do trivial things like `Partial<T>` or statically assert that two objects have the same type. All this kvetching about libraries changing makes me laugh. The Python 2 -> 3 transition was so horrific that the last place that I worked at had a 100M Python monolith with no plans of EVER upgrading to 3. SqlAlchemy 1 -> 2 is an 8 step migration that requires a TOTAL rewrite, and if you break anything, YOUR SITE GOES DOWN. And then people complain because React optionally added hooks or something! The weird thing is that the internet is full of posts about "The Frontend Treadmill", but no one ever seems to gripe about the converse.
    • sethammons 2y ago
      I am back at a python shop and (again) pushing, successfully, Go. Python is molasses for teams for all the reasons you state and more.
      • wruza 2y ago
        What does “molasses” mean here? Search says it’s “slow”, but that makes little sense.
        • sethammons 2y ago
          that's exactly what I mean. At the three python shops I've been at, teams reach across boundaries and add abstractions. This gets something out fast at first, but as the organization grows, if you are not diligent, the code organically grows and the ability to ship new things becomes increasingly tied to how other things are implemented. What should take 1 team 1 sprint takes a dozen teams a dozen sprints. Code that shouldn't seemingly otherwise do so can get called in unexpected ways and take down your application. All this "you can do anything" ability leads to abstractions to solve niche issues that makes everything harder to reason about. A great example: In django, a property on a model object might not be a property. This isn't limited to django, but that is where it bit me. So "customer_record.billing_type". Having loaded the customer_record, one might assume that you could access a property on it with little to no issue. Nope. Python lets you treat that property as a method, and now a hot loop in our code is making a network request to load load more data from a different databases. To prevent this requires mental load, knowing what properties are properties and which are not. Because in Python, it could be anything, even a boat, and you know how much we've wanted one of those --Peter G.
  • guappa 2y ago
    > It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc My theory is that they do it because they don't have enough to do.
  • brabel 2y ago
    I work mostly on the JVM world, with Java/Kotlin. Two comments: In Java: I can build stuff from the early 2000's without changing a line, most likely, if it's using Maven or Ant to build. If it's Gradle, we may have trouble with the JVM version even if Gradle wrapper is used, and if it's not, well good luck as Gradle has evolved hugely since the early days (I think early 2010's if my memory is any good). In Kotlin: has been a wild ride for me... not like JS, maybe... more like what you describe from Rust. I mean, in 4 years you've had a breaking change, that's horrifying for someone used to Java :D. Kotlin does require a lot of upkeep compared to Java, specially when combined with said Gradle. More if you use KTest... much more if you use KTor... and a hell of a lot more if you use Kotlin MP, which we do on one of our projects (though I acknowledge we were early adopters).
• pwdisswordfishz 2y ago
  > But our current framework layer is working against the grain instead of embracing the platform. Said the person with this bullshit in their page code, which will not deactivate when JavaScript fails to run: <style>body{visibility:hidden;opacity:0}</style> Guess who just saw it happen.
  • breckenedge 2y ago
    That comes from the theme they’re using, and there’s a noscript directive immediately after it. https://github.com/Mitrichius/hugo-theme-anubis/blob/main/layouts/partials/head.html https://github.com/Mitrichius/hugo-theme-anubis/blob/main/la...
    • pwdisswordfishz 2y ago
      Doesn't make it any less stupid or hypocritical. Dependencies you made a choice to use don't absolve you from responsibility.
      • krainboltgreene 2y ago
        Actually, it doesn't matter at all.
    • move-on-by 2y ago
      Which is now deprecated and no longer receiving updates! Haha, that’s hilarious in context of the post. It’s also maddeningly frustrating as someone who regularly has to update things on awful frontend projects no one else is willing to touch. Frontend work is cursed.
      • PaulHoule 2y ago
        If they weren't in that morass they'd be writing about how happy they are with Common Lisp or Pony or something.
• zwnow 2y ago
  Based on the first paragraph alone, almost all devs I know think that a complete rewrite will solve all the issues, thats not only frontend but backend too. Web development in its current form is a beast and if we want true change we need to fix the biggest issue there is for all of webdev: Forcing everything into Javascript and incompetence. I wont claim I am competent, but at least I acknowledge that SvelteReactVueSolidNextNuxt is not the solution but rather trying to patch up some symptoms... The Web needs true change.
  • incrudible 2y ago
    > The Web needs true change. Here's how that works: Make something better and get people to adopt it. "The web" isn't set in stone, it's a series of tubes. Be warned though, odds are you will fail to gain traction because while we all agree that the web sucks, we all disagree on what the change should be. I for one have the complete opposite take regarding Javascript. Just give up on the web as a declarative document platform and embrace it as an application platform. Use an actual programming language instead of adding yet another feature to the Rube Goldberg machine that is HTML+CSS. That's not solving any real problems, it's just making it incrementally less feasible to have multiple browser implementations and anyway it's not like you'll want to use the feature until years down the line when it's gone through the whole standard and adoption phase.
    • zwnow 2y ago
      How will you scale your take on this? We are currently facing incredible scaling issues and complexity in web dev because of js based systems. Meanwhile companies that ditch js have great success (whatsapp, discord, ...) Js in the browser is fine, but with node and Nuxt or Next we now have it where it doesn't belong.
      • hajile 2y ago
        The big problem with scaling JS on the server is threading. There's simply no way to do it. You can spin up multiple processes, but then the communication overhead gets you. The spec committee needs to bake in actors and they need to add tuples/records so sharing data across actors is easy and free. Finally, Typescript needs to bake in a warning to tell you when your code is going megamorphic so you can change it so the JIT can actually optimize for you (I think most JS devs would be shocked to find out just how much of their code is incapable of ever getting advanced optimizations).
• ng12 2y ago
  > Whatever framework you choose will be obsolete in 5 years. I've been writing React professionally for over a decade at this point. I don't know what this guy's on about.
  • olliepop 2y ago
    Component lifecycle methods to hooks and HOCs, does that ring a bell?
    • ng12 2y ago
      Yeah, and I'm not anywhere near as distressed about it as this article implies I should be.
      • figassis 2y ago
        As a BE engineer when that happened, I had just started to become proficient in it, coming from Angular. I threw in the towel and went back to my backend world of peace and happiness. So he's not alone, these deprecations are insane.
        • the_other 2y ago
          Front-end dev here. I hear from the b/e people about containers, serverless, lambdas, ORMs, queues, schedulers, caches, pipelines (ok, I use these too), databases, API gateways. Oh, but it's podman now, not Docker. And they're moving everything off AWS to Azure. And there's three versions of the API my f/e needs to talk to still in production. And every micro-service depends on a different version of Node. Apart from the one that's in Ruby and the stuff from that department who only use .NET. I don't believe this promised land of clarity, comfort and purity exists. It's just mess on both sides of the internet connection trying to solve different parts of the problem of turning user needs into money.
          • lezojeda 2y ago
            [dead]
• rjmill 2y ago
  Great advice, but my case is different because our framework is REALLY hurting us. /s It's wild how easy it is to fall into this trap. IMO, if you're considering switching frameworks (especially for perf reasons), your time would be better served by getting parts of your app off framework completely (assuming there's truly no way to get the results you want in your current framework.)
• antirez 2y ago
  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.
  • klysm 2y ago
    No separation between backend and front end is hard. I’m not good at front end, and we don’t have a designer. I’m miles better on backend though and other team members are more talented than me for front end design.
    • mmaurizi 2y ago
      Design shouldn't be part of front end engineering - there is a reason there is a separate role for that, designer.
      • klysm 2y ago
        Yeah I agree, but we don't have a designer so what am I to do? I think I'm good at the frontend engineering as in breaking down component structure, passing data around etc. but I can't make something look good enough to meet my own standards.
    • singron 2y ago
      You would probably be decent at frontend if you did it at least 20% of the time. Obviously you can't be an expert at everything, but there is enormous value in being able to work on most things end to end instead of having to handoff every time.
      • klysm 2y ago
        I do it about 40% of the time - I'm just straight up not good at it, which is okay. I can get by, but it would be better for the company for somebody else to be doing it. Specialization can be good!
  • 2y ago
• havkom 2y ago
  Amen!
• krainboltgreene 2y ago
  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.
  • ryan-duve 2y ago
    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?
    • paradox460 2y ago
      Liveview nearly eliminates the boundary between backend and frontend. Your forms, inputs, outputs, whatever, just become another GenServer with a few special callbacks. You no longer have to worry about an API and syncing data from client to server. The transport layer becomes invisible
      • krainboltgreene 2y ago
        It's not even worth it to talk about GenServer or special callbacks. Any idiot can just think of it as "phx-{binding}" html attribute and "handle_event".
    • krainboltgreene 2y ago
      Yes. You get to drop the javascript compile and the graphql and you speak purely in three languages: 1. elixir: def handle_event("save_customer", params, socket)... 2. html: <form :for={@form} phx-submit="save_customer"> 3. And sometimes rarely javascript: this.pushEvent("reorder_customer_priorities") That's it. No compiler, no type annotations, no graphql layer.
• SamuelAdams 2y ago
  Speaking of front end frameworks, whatever happened to Angular(JS)? It seemed to be required on every other job posting, but now things seem to only ask for React or React Native.
  • ForTheKidz 2y ago
    I see angular postings still. I can't claim I've touched frontend in a half decade, though.
  • TheAceOfHearts 2y ago
    If anonymous posters on HN are to be believed, the guy spearheading Angular as a major frontend framework got his mansion on a hill and he left. And before that the Angular developers burned down their community by breaking compatibility in the transition between 1.X and 2.0.
    • eYrKEC2 2y ago
      Develop on Google -- when you really really really want to refactor your web app every 6 months. Love me some Android version bumps -- who needs compatible API interfaces?? Never did Microsoft or Intel/AMD any favors.
  • 8s2ngy 2y ago
    I still see many job postings for Angular, mainly from government institutions and non-tech companies. In my region, Angular for the frontend and Java with Spring Boot for the backend still account for a healthy number of job postings.
  • eYrKEC2 2y ago
    The difference in speed between Angular 1 and React was like the difference between Python and Rust. Not only was React simpler than Angular and had fewer footguns, but it was so ridiculously fast out of the box compared to Angular. Then Google google'd and left devs high and dry with the need to rewrite their apps from Angular 1 to Angular 2+, whereas React has been relatively stable, despite some incompatibilities -- yes there are new features and new methods, but you can still do React classes.
• ForTheKidz 2y ago
  Why does FE development have such churn? Desktop toolkits from 30 years ago work just as performantly today; what is so difficult about the browser that demands constant framework updates?
  • Raed667 2y ago
    Because web apps you see today were not feasible even 10 years ago (and I'm not talking about simple static websites)
    • yakshaving_jgt 2y ago
      Like what? I think the web looked more or less the same in 2015 as it does today.
      • Raed667 2y ago
        Wasm, WebGPU, a bunch of PWA features etc...
        • yakshaving_jgt 2y ago
          I mean, we had asm.js in 2013, which ran Unreal Engine 4 in the browser. WebGPU is new, but WebGL came out in 2011.
  • aredox 2y ago
    [flagged]
  • Eric_WVGG 2y ago
    I think it’s because, on a fundamental level, we have been trying to wedge an app platform into a document reader. Zoom out and think about how mad this is. Like if we tried to build “Web 2.0” inside Adobe Acrobat Reader. Apple has prescribed front-end frameworks like AppKit and UiKit and now SwiftUI, Linux had Gnome and GTK and whatever (I’m not an expert and my knowledge here is out of date)… there’s never been a Correct Way to build a web app because the browser doesn’t have an Apple Microsoft or Linux Foundation, so we’ve been winging it all along. I’m similarly tired of framework churn, NextJS server components might be the breaking point for me. But there’s no way I’m going back from component driven architecture, and I’m not sure what a vanilla js answer to a static site builder like Next (back when it was good) or Gatsby would be like.
• stackedinserter 2y ago
  > Whatever framework you choose will be obsolete in 5 years. IDK our product is older than 5 years and React is still not obsolete.
• conorbergin 2y ago
  When I made my first website I read things online like "svelte is better than react" and "solid-js will be the next big thing", and I thought this was an important part of web development. Newbies should read MDN and ignore everything else.
  • only-one1701 2y ago
    React's been around long enough and is dug in deep enough to have decent ROI on knowing fairly well, but the recent obsession with Next.js and SSR...maybe not. Privately I think this might be their undoing.
    • conorbergin 2y ago
      I agree with learning React, it pops up in all sorts of places, vscode extensions, the windows start menu apparently. But yes, mixed-rendering, server functions, meta-frameworks, etc. You are in real danger of spending years learning all this stuff and still not being any closer to knowing how computers work.
    • croes 2y ago
      Which version of react? Hooks or classes? Or whatever comes next.
      • Etheryte 2y ago
        You can still write class-based components in React, no problem. It might not be in vogue, but for the most part, you can still write React 18.x roughly the same way you wrote React 0.x.
        • rcarr 2y ago
          You can but are people going to when the first thing you see upon opening the docs is a giant warning telling you not to? https://react.dev/reference/react/Component https://react.dev/reference/react/Component
  • 2y ago
• MrBuddyCasino 2y ago
  Feels like an article from 2015, where churn was still enormous. Today we have more stability: mostly React, Angular is also still around, some novel approaches like Svelte or HTMX, but mostly its the reactive paradigm packaged in different ways (eg Vue.js). No XHTML, no IE6, heck not even IE. CSS converges on Tailwind. What is unsolved is the dependency hell: builds break over time, just by NPM rot.
  • larrik 2y ago
    Meanwhile, my team has been trying to upgrade a large app from vue2/nuxt2 to vue3/nuxt3, which has no real upgrade path at all. Oh, and the time between nuxt3's prod release and vue2's EOL was like 9 months. Vue 3 IS better than 2, but at what cost?
    • MrBuddyCasino 2y ago
      At least when Vue 4 rolls around, you can pay Claude Code to do it for you (for a modest fee). Btw what made you choose Vue over React?
      • whstl 2y ago
        Not GP but if I were to start a project today that needs an SPA I would go Vue rather than React 100%. Or if you want to be trendy, something like Solid or Svelte are also ok. React is okay-ish when done in moderation but it becomes spaghetti too quickly when the team is not made of 10x ninja rockstars from space. It is particularly bad for startups, you either slow down with code reviews or pay the price. The main reason IMO is the reactivity mode. Too many footguns to watch out for. Plus, the quality of third-party React packages is abysmal. What a terrible ecosystem. Using as few dependencies as possible makes it better, but it's hard to push back on larger teams. In the end it's all about opinion of course but after 10 years going back and forth between both (hey I'm trying to stay employable) that's my experience. EDIT: But if I had to do SSR I would avoid Javascript period. Lots of backend languages are better for SSR.
        • 2y ago
• 1GZ0 2y ago
  This really strikes cord with me. I chose early on in my carrier not to use frontend frameworks, precisely because of the added abstraction and inherent complexity they tend to bring to your codebase. Its been tough and limited my prospects significantly as a junior dev. But these days, I'm happy that I chose to steer clear of frameworks. As it really does give you a much more broad understanding of how the web platform works. Tl;Dr for the juniors out there, learn React if you want a job. Learn javascript if you want a good job.
• ThePhysicist 2y ago
  I've seen this so many times already, going from server-rendered web apps to client-side rendered web apps in React, then through multiple generations of state management and component management strategies in React, then back to server-side rendered stuff with Next.js, it is so tiring.
• AlexMoffat 2y ago
  The counterpoint is that if you don’t adopt a framework you end up with a “framework” you built yourselves that people outside your team don’t understand, is generally poorly documented and needs constant work to add features existing frameworks already have. There are common features needed on the FE and common problems to solve, why not at least start with something instead of nothing?
  • metalforever 2y ago
    I am not sure this is true . As I wrote elsewhere, almost everyone wants a web app or thinks that they have a web app, but usually it is just a dynamic website. You do not need to build up a framework to have a dynamic website.
    • agos 2y ago
      "everyone" and "usually" are doing a lot of work here
      • metalforever 2y ago
        I would bet real money that what I am saying is also true at your workplace.
  • ziml77 2y ago
    Yes this is a problem I've seen. It's impossible to find people who can be immediately productive because they've never seen your internal framework before. Even if it's extensively documented, it still takes time to learn and internalize. For long-term hires, it's not the worst, but if you ever temporarily need extra devs, you're SOL.
• deleted 2y ago
  [deleted]
• hnthrow90348765 2y ago
  We have a jquery/Razor front-end that has a ton of global JS state manipulation and a file called 'common.js' which is a dumping ground for almost any function used in two places regardless of what it does. Many things are reinvented wheels (badly) and the previous team left a ton of XSS vulnerabilities in on top of that. Language differences from the previous offshore team mean things are named strangely to me, but even then, there's sometimes bad names for variables and functions. Does it still function? Sort of. But most of our bugs are front-end issues because it's difficult to reason about any of the control flow. It isn't just obsolete or an unpopular framework, it's bad code. There's no way I'm going to stay quiet about rewriting something like that if I want to stay at the company (spoiler: I'm quiet about it) and I don't think anyone else should be quiet about it either. This shit causes stress.
• only-one1701 2y ago
  The biggest problem by far with the frontend ecosystem is that it assumes everyone's been writing perfect frontend code which makes deprecation/migration a breeze. Frontend is much more forgiving then backend, which means you can write absolute dogsh*t and have it not be discovered for years. This compounds, unfortunately, and when it comes time for breaking changes in a new library or framework versions, I think the authors of these versions don't understand how bad it is in the average frontend trenches. So more bad code is written to patch over existing bad code, and the cycle continues. Gets worse, in fact.
• donbrae 2y ago
  I wonder whether AI being the new and shiny thing will lead to a reduction in ‘innovation’ in front-end frameworks. Front-end dev seems to me to have been a solved problem for years now, yet there are still new ways of doing things for marginal gains. I personally just use vanilla JS (having never built anything Facebook-scale which would necessitate using a tool like React) and would be happy if instead of working on yet more front-end stuff, folk will otherwise build something AI-related, both because that is where the hype is but also because it’s genuinely exciting.
• francasso 2y ago
  I think this THE main reason why many people are getting fed up with javascript heavy frontends and switching to technologies like htmx. Personally I stick to json to feed data to my frontends, but I gave up on "frameworks" a while back and just implemented my own abstractions on top of vanilla js and the dom and have been happily using them for years. If you work in large teams with people that don't care so much tough, that would also have drawbacks.
  • jollyllama 2y ago
    Yup. The Frontend ecosystem juice isn't worth the squeeze unless you've got a full time team of software devs on your project. Better to ditch NPM etc. and go with HTMX.
• 8s2ngy 2y ago
  I have given this a lot of thought, and I haven't been able to come up with any reasonable long-term solution that avoids major refactors or swapping out libraries and tools. I am leaning toward pairing React with React Router for creating server-side rendered web apps. My thinking is that React has "won" the JavaScript wars, maintaining its popularity consistently over the past decade, and React Router is one of the most downloaded libraries for React. (At this point, I’ve come to terms with the fact that React Router will likely introduce breaking changes in its next major update, as it has done many times in the past.)
  • only-one1701 2y ago
    So I mostly agree with you, but I think there's some real dissatisfaction with React and Remix/React-Router's emphasis on SSR. If you don't care about SEO, there's really not that much SSR gives you that CSR doesn't. React and Remix seem to have gone all-in on SSR, and I just don't quite understand why.
    • RobKohr 2y ago
      Yeah, I like have an express or python backend that just is the api. I know I can test and validate what comes out easily, and control auth from there. The backend is the real app, and the frontend is the ui peice. With a solid backend, you can yank out the FE and replace it, or have it power some other apps easily. You can identify issues, and not have to traverse much code to get to them. Your browser network tools will quickly help you identify if your problem is on the backend or the frontend regarding data. SSR, well it is like going back to PHP days. The problem could be anywhere in the codebase. If SEO is important, then yeah, it becomes an issue, but in that case I think periodic caching of client side rendered code to make it so that it shows that to the crawlers works best.
• PaulHoule 2y ago
  I think of the strange case of react-router which has been through 7 versions, many of which were complete breaking rewrites. It's hard not to come to the conclusion that since they kept rewriting it, they didn't believe in any of them. Lately they made big changes because they want to support SSR but I couldn't give a flying F because we're not using SSR any more than I care about React Native support because we're not using React Native! [1] I've worked on a lot of code where people tried to use react-router and eventually gave up and have some code where they parse the URL directly and it works just fine. The trouble with react-router is that if you understand it enough to use it, you don't need it that is, you can either write some stupid URL parsing code or you can write some hooks that do 100% of what you want (as opposed to 90% of what you want with their code) with about 25% of the code. For them it's a tiny amount of code that they understand completely and they have no problem tearing it up and rewriting it all because there is very little to it and it doesn't really do very much. [2] For you you either don't understand it in which case you feel like a hostage to their whims or you do understand it in which case you don't need it. I am looking at a React 16 app which uses a huge number of third-party components that I badly want to take up to React 17 because of testing. With React 16 the tests can't ever really know that React is done running callbacks which makes them brittle and slow which is a bad enough situation that I don't want to write any more tests. React could have done something about it before because React knows if it has callbacks left to run but they didn't until React 17. My understanding is that, most likely, all the components I have will work just fine with React 17 or 18 for that matter because the 16 -> 17 and 17 -> 18 transitions caused very little breakage. Their package.json files disagree so I can't just bump to React 17, but rather I have to update all the dependencies to newer version and many of them, like react-router, have a cavalier attitude about compatibility so I'd expect to spend a month at least dealing with all the breaking changes in the dependencies. It's times like this when I wish I could stick an axiom into my package.json that says "Version A of package B is really compatible with React 18" or just fork version A of package B to version A' which has a patched package.json. After all that it is certain that there will be invisible changes in the HTML which will cause us to fail an accessibility audit six months later requiring another month of work to track down. [1] Sure, somebody else is, but I have enough problems to worry about with the modern web and patching up applications written by interns that I don't need the burden of navigating through the docs over and over and over again having to ignore 80% of the content which is completely irrelevant to me. Never mind that older versions of RR, at the very least, support obsolete methods of navigation which is another thing you don't need filling your headspace. [2] So little code that it probably takes up more of their headspace to go to a conference and boast about what they did than it did to actually do it!
• whatamidoingyo 2y ago
  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.
  • worik 2y ago
    > 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)
    • whatamidoingyo 2y ago
      For simple interfaces, vanilla is preferable, of course. But when you're working with mostly dynamic content and huge datasets, it really is a nightmare compared to using something like React. With vanilla, it just takes more effort to build things. A file could easily become 2,000+ LOC.
• throwanem 2y ago
  (2024)
• rambambram 2y ago
  Good read and I agree fully. Also been doing webdev for 20+ years now and I'm still very happy with the CHAMP stack. CHAMP of course standing for: CSS, HTML, Apache, MySQL and PHP. As you can see, there's no J in CHAMP. I have been doubting my choice in the past, because everybody was using (frontend) frameworks and the like and I'm just a social animal like everybody else. I'm happy I stuck with the stuff I already knew from around 2004, but I feel for all kinds of younger developers who got dragged into the trap.
  • aaronbaugher 2y ago
    If you want to include some dynamic elements without getting into the whole frontend framework thing, HTMx is pretty great for that.
    • rambambram 2y ago
      Oh, I do include some JS, just a little bit. A little sprinkle on top, that's enough for my use cases. But CHAMPj just doesn't sound that nice. ;)
  • ludicrousdispla 2y ago
    After developing applications using native windowing toolkits for over fifteen years, I looked at React briefly in 2015 and have avoided it since. Currently working on several HTML+CSS proofs of concept to support interactive UIs.
• obiefernandez 2y ago
  Just use Ruby on Rails. Problem solved.
  • Kerrick 2y ago
    Any chance Addison-Wesley will publish more Professional Ruby Series books? Those were great books, yours especially.
  • xutopia 2y ago
    I can't imagine having to build a frontend in React... I'm doing everything from mobile app to extensive frontend using Rails... no React anywhere. Just plain vanilla Rails and it's been a godsend!
• _fat_santa 2y ago
  > Product teams that are smart are getting off the treadmill. Whatever framework you currently have, start investing in getting to know it deeply. I've been working on a SaaS product for a couple of years and when I first started I picked up MUI as my FE framework. Since then on at least 5 different occasions I looked into replacing it and have always landed back on "no lets keep it". MUI is far from a perfect FE framework but for me I realized it worked really well because it helped me create pretty professional looking UI's without any designer assistance. And over the years I've learned many of the quirks around the framework and have implemented various tooling to mitigate any shortcomings. I'm still looking for an eventual replacement though, for a while I thought I was going to jump on Google's official material design spec but then they stopped working on the web version. At this point I'm probably going to gradually adopt TailwindCSS (probably over the course of a year or more) and eventually move my FE to an entirely custom build solution. But even thinking about this change I still come back to "what's the point?". Customers like my product and use it ever day, MUI has it's shortcomings but it's not something terrible I need to jump ship from. I'm sure I will eventually replace MUI but so far it's been chugging along just fine.
• liminal 2y ago
  We're trying to hire an Angular design engineer, so now the recruiter is the person trying to get management to switch to React to make his search easier. The tech doesn't matter too much, but the market forces do.
  • stickfigure 2y ago
    Management should not be listening to technology advice from recruiters.
• sherdil2022 2y ago
  If someone new to FE development were to start today, what would the process be? A) If they are on their own (one-person team), they will do a web search and pick the most popular framework/library etc. Or do some POCs in a few of these frameworks/libraries and pick one. B) If they are part of a team, they will go with whatever the team has decided If someone has been doing FE, they either will stick to whatever they are doing or search for what else is out there. Yes. This sounds like a treadmill - but that is part of software development and continuous improvement, right? Building a website in plain/vanilla JS or no JS is possible. It all boils down to what is moving the product development forward. And this isn’t always simple or possible with FEs. There are many choices for BEs and cloud providers as well - and sometimes a combination of those. In short, there are no right or wrong answers. It is always - “it depends” - on what scenarios you are targeting and what features you want to build
• ctrlp 2y ago
  Much of the tech churn in frontend is likely attributable to it being an entry door for beginner coders over other pathways. Most of us got started in web dev and made big messes using frameworks we didn't understand. So e of us got better and changed the framework to make it more x, y, or z. Some decided, I'll build my own that doesn't have those x, y, z problems. And so here we are. TBD if HTML standards can ever replace this cycle.
• fitsumbelay 2y ago
  Love a pro-Web Platform post Really every single point made is well taken, even the if-you-gotta-use-a-JS-framework one(s)
• bluGill 2y ago
  As an embedded developer I've long felt the web folks were crazy changing their frameworks all the time. They are not doing anything on the web we haven't done before. Most of the concepts are right out of the mainframe era, and we switched to dumb terminals and PCs for a reason (not always good reasons - there are pros and cons to both approaches)
  • madeofpalk 2y ago
    Which web folks have been changing their frameworks all the time? If anything, I think a valid criticism of modern/current web development is that it's entirely a React monoculture. I'm happy writing react, and have been at countless companies for the past 10 years.
• pandemic_region 2y ago
  If you're in the java world, I feel that Vaadin the "java-only" frontend framework is heavily underused. Yes, http sessions, but no it's not a big deal unless you're scaling beyond 10k+ users and even then so. It's been around for 20+ years, with paying commercial features if needed and they seem to have survived from JSF all the way through the latest version of sveractular.
• synergy20 2y ago
  Frontend has always been a pain for me. Just switched from React to Vue since it's getting harder to stay with React. then I was thinking maybe just the old bootstrap(alpine.js,htmx) with SSR approach? it's simpler and more importantly, can be maintained a few years down the road without a revamp(due to frontend breaking changes). In the end, I still stick to Vue.js, as the SSR approach has its own problems, nothing is ideal.
  • intrasight 2y ago
    Also for the money you save by not having a dozen software engineers to maintain the frontend and its dependencies, you can hire a very talented front end designer and give everyone on the engineering team a 100% raise.
    • synergy20 2y ago
      you mean no SPA just the old fashion frontend? vue.js still needs developers but simpler than react for sure, less money needed with vuejs down the road
• jchw 2y ago
  > 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, but it's been around even longer than React, if you want to count the Angular1 and Angular2+ days together. So honestly I think this is out-of-date logic. While frontend dev moves fast, it really isn't that bad. Pick boring choices and you get boring results.
  • codingdave 2y ago
    Agreed, and I'd add that "obsolete" is a strong word. You can run an older framework for a long, long time. So long as people exist who know your stack and can be hired to work on it when needed, your stack is not "obsolete". "Dated", maybe. "Legacy" is also sometimes an accurate term. But until the day comes when nobody is left who will work on it, it is not "obsolete".
    • 9dev 2y ago
      You can, but at some point things start breaking down. Your dependencies are all outdated and pile up CVEs (which you probably are contractually obligated to do something against.) The dev-tool extension is no longer maintained, and Sentry stops support too. You want to improve things by migrating to the new version or competing framework, but that requires lots of toil, since a lot of things changed in subtle ways or are done differently now, and that has ripple effects. Before you know it, you’ve spent four months playing the zero-sum game of rewriting your frontend. Finally you’ve made it, and then they release Tailwind 4.
      • jchw 2y ago
        Coincidentally, I just migrated something from Tailwind v3 to v4, even though Tailwind isn't really much my cup of tea. The migration tool that they ship was able to do everything. e.g. I ran it, then my project built and worked with v4 instead of v3. Likewise, there haven't really been any major API changes in React lately either, but if you want it to be automated, they ship react-codemods which will handle a surprising amount of edge cases for you when upgrading.
• localghost3000 2y ago
  > 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, however, that it will make you more attractive on the job market. It's not that knowing this stuff doesn't matter, it's that folks that make hiring decisions tend to pattern match. The fact is that if you want to maximize your "market value", you still need to be _very_ good at React. This is table stakes. Everything else is great, but if you don't have that foundation, you're limiting your options. Maybe that is what the author meant and I am just misreading.
  • colordrops 2y ago
    I've been in the market for 30 years, had some of the best jobs on earth doing FE, and only did my first React project last year. Maybe I'm an anomaly but I never felt that not knowing React has been a problem. "table stakes" is too strong a phrase.
    • CognitiveLens 2y ago
      To be fair, "30 years of experience" likely opens more doors than any particular skill listed on your CV - that doesn't reflect the way that a majority of junior/mid-level devs need to present their abilities, where pattern-matching is an unfortunate norm, particularly when there are orders of magnitude more applicants than open roles.
      • colordrops 2y ago
        Everywhere I've worked would have judged heavy emphasis on framework expertise rather than fundamental CS concepts and web standards as a red flag. I don't think it's that rare. Mentioning ability in React is obviously not a bad thing but some people make it their whole resume.
• breadwinner 2y ago
  > Whatever framework you choose will be obsolete in 5 years. The mistake here is the assumption that you need a "framework". I challenge this notion. What does code that does not use a heavy framework look like? It is very maintainable and easy to use and will not become obsolete. Here's an example: https://github.com/wisercoder/eureka/tree/master/webapp/ClientApp https://github.com/wisercoder/eureka/tree/master/webapp/Clie... It uses two 500-line libraries, hardly a "framework". One for MVC/History and one for TSX. The notion that you need React/Svelte/Vue/Angular is what is obsolete. All you need is VanillaJS.
  • hajile 2y ago
    VanillaJS is a worse solution. When the JS framework benchmark first came out, VanillaJS was the fastest. After some of the vdom frameworks came out (especially InfernoJS), VanillaJS was slower. How did they make VanillaJS faster? They studied the output code paths of InfernoJS and copied them. Each time InfernoJS would release new, faster versions, they'd backport those optimizations into the VanillaJS. Then SolidJS and Svelte came out and it copied them. By the time it was done, the VanillaJS code was fast, but not very readable and definitely NOT the type of code a human would write. Additionally, each new piece being hand-written means each is a brand new chance to miss little implementation details that lead to subtle bugs and memory leaks. As your site grows, you'll also develop bugs from accidentally stomping on someone else's piece of the DOM unless you add all the overhead/complexity of shadow DOM. pReact (or something similar if it exists) is a much better type of solution IMO. Here's a link to the whole source code minified. https://esm.sh/preact@10.26.4/es2022/preact.mjs https://esm.sh/preact@10.26.4/es2022/preact.mjs It's not even a whole page on my laptop screen, but it will be faster than an average dev's VanillaJS code 95% of the time. It won't have those potential implementation bugs. It will scale to many components and devs effortlessly. It also provides clean, tested ways to add other features your project may need in safe ways.
    • metalforever 2y ago
      You have to define "worse". What is actually "worse" is paying developer time to sit there in a never-ending upgrade and deprecation cycle when your core product is elsewhere.
• upghost 2y ago
  The article mentions "web fundamentals" and "getting back to the fundamentals". Sounds great! Would anyone care to have a conversation about what this means? Like does the author mean DOM manipulation or TCP stack? I feel like this is pretty broad and even though I've been doing full stack for a bit now I'm suddenly not sure if I know the fundamentals.
  • mystifyingpoi 2y ago
    I think a lot of people are yearning for the "good old days", where you'd install Apache, drop some .php files into /var/www and start hacking around with only static HTML and maybe a sprinkle of progressive-enhancement JS here and there. I think it's totally okay way to build a dynamic webpage. But web application? Not so sure.
    • metalforever 2y ago
      Everyone thinks they have a web application but a lot of the React I get asked to build could have easily just been a dynamic webpage (it is usually a dashboard). I think there is an over-emphasis on what constitutes a "web app".
  • wonger_ 2y ago
    I think "web fundamentals" here might mean DOM manipulation, browser-native APIs, default form inputs. Stuff like <input type=date> and document.querySelector() and appendChild(), which are often abstracted over or replaced with frameworks.
  • proc0 2y ago
    He's missing the bigger picture, IMHO. Nobody goes back to fundamentals because the industry is not allowing the role to do that. FE engineers don't have control over the codebase to this degree, and the expectation from the company is more about business profit, more usage, etc., instead of building something that will not need to be rewritten. In other words, the article misses the huge factor that companies don't care enough to allow FE engineering to be about building things properly, and instead make it something akin to a product owner with technical skills.
• dewcifer 2y ago
  Front-end dev of 20+ years. Plenty of back-end and full stack work in there too. While I definitely agree with the sentiments in this article, I feel it is a bit more nuanced a conversation than this. While you can truly swap out the UI and ultimately the front-end doesn't matter if the back-end isn't solid long-term - you can equally swap out/automate/just install a rock solid back-end framework, just like you can a front-end. Furthermore, the front-end is the single thing that customers/users typically interact with - which makes it drastically more important than is let on in the article. We were recently doing a book study on measuring UX and I am pretty convinced that the way people feel about a thing is more important than how well it functions. I don't really even call myself front-end or back-end anymore.. to be honest I'm not sure it's as useful of a distinction as it has been in the past. Both aspects of an app need to be solid and also bespoke to a degree imo.
• porterehunley 2y ago
  As a developer just starting to get into frontend, I'm wondering how learning core-web technologies has helped frontend developers vs just going all-in on on something like React.
  • LocalPCGuy 2y ago
    As someone with 15+ years of experience, a lot of that FE specific, that is the advice I always give newer devs if asked. Learn the fundamentals of Javascript, HTML, CSS (it's like a 3 legged stool, even if the JS leg is oversized in the days of web apps). If you know how to program, and you know the fundamentals, you can work in whatever framework is thrown your way. Now, practically speaking, that's actually probably better advice for someone with a job and 1-2 years in. To get an initial foothold in the industry, people often need to specialize in one specific thing (React at the moment most likely), in order to be able to demonstrate enough competence to get that initial job and so I understand how fundamentals can be backburnered initially. But I recommend devs don't let that initial success lock them into that framework - that's the time to get back and learn all the fundamentals, go wide, learn a couple other frameworks even so it's easy to compare and contrast the strengths/weaknesses of each. And you will want to be well-versed in the framework you currently use day to day, knowing best practices, architecture patterns that work and those to avoid, etc. Knowing the fundamentals will help, but there will be framework specific things that will change from framework to framework, even code-base to code-base sometimes. So it's always going to be a bit of a balance. But long-term, IMO, being well-versed in the fundamentals affords you the most flexibility and employ-ability long-term.
• adamtaylor_13 2y ago
  I 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.
  • bibstha 2y ago
    I maintain an app that was originally written in 2011 in Rails, and a lot of old code looks very similar to what we have in Rails 2025. It's very easy to dig into existing code. Feels really good.
  • dmix 2y ago
    100%, Turbo and stimulus will save projects from React/Vue hell for 95% of cases. The other 5% you can make isolated fancy JS stuff without it eating the entire frontend.
    • pier25 2y ago
      Or maybe HTMX
      • nop_slide 2y ago
        Hotwire is basically a higher level HTMX
  • squidsoup 2y ago
    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?
    • anonzzzies 2y ago
      Never had those issues. It is just frontend job protection blah. No one should listen to it really.
    • 2y ago
• TacticalCoder 2y ago
  [dead]
• pc86 2y ago
  > If you feel strongly about what framework you want to use, please make that a criteria for your job search. Please stop walking into teams and derailing everything by trying to convince them to switch from framework X to your framework of choice. It’s really annoying and tremendously costly. We try to screen for this mentality pretty thoroughly in interviews. Few things are more tiresome than having a product that has been around for years, and that has lots of users, tech debt, edge cases, and business considerations baked into it and having to explain to someone who's been with the company for 2 months that no we probably shouldn't throw out the entire React app and rewrite it in Svelte. An few things are more aggravating than someone who has that idea shot down multiple times and keeps. bringing. it. up. Any indication in our interview process that you are a language or framework zealot will make it a lot harder for you to move to the next round.
• curtisblaine 2y ago
  React 16.8 (the one with hooks) has been stable for almost 6 years and newer React versions are mostly backwards compatible. The real problem are bundler / build tools. Using something like esbuild + tsc goes a really long way and will never get deprecated. If you know the craft enough, you can ignore everything else (save eslint, probably).
• czk 2y ago
  I don't disagree with the point being made but it should also be noted that React and Vue are both 11 years old. Hell, even Meteor.js (anyone remember this one?) is still around and being updated.
  • Sateeshm 2y ago
    Even Svelte is going to be 10 years old in about a year.
  • sodapopcan 2y ago
    This is covered in the article. They change so much they may as well be new. There are tons of apps out there that have a mix of React class and functional components, for example. And didn't Svelte just make a huge fundamental change to its api?
  • pier25 2y ago
    Good luck with a Vue 2 + vuex + Vue Router project scaffolded with Vue CLI in 2016 which NPM is screaming at you is full of vulnerabilities. Or that React + React Router + Redux + Webpack 3 project from 2015. In both cases you'd need to spend serious time moving to newer deps, rearchitecturing, probably moving to Vite, etc.
    • czk 2y ago
      Sounds absolutely brutal for sure. I didn't mean to sound like everything was fine in JavaScript land, they have been chasing the shiny new thing and focusing too much on the wrong abstractions for a while. Even backend frameworks aren't free from this same problem, when you look at the support and migration woes in big players like rails/laravel/django. I suppose thats less frequent though. I'm not sure how you avoid it in any framework without rawdogging pure HATEOAS and vanilla concepts. Recently I've gravitated towards Django and HTMX and its felt quite refreshing. Keeping your tech stack up to date inevitably brings some pain and suffering along. I do wish more frontend frameworks cared about backwards compatibility. The web dev influencers really push the latest and greatest memes. One day they are putting out a video of how Firefox is the worst browser in the world because it doesn't support some niche variety of CSS gradient and the next they are gushing over something like Zen (a Firefox fork).
• Aldipower 2y ago
  Out of curiosity I've just fired up an old dynamic Perl website of mine. Works! 20 years later. On my modern machine!
• dekhn 2y ago
  I've proposed an idea several times that I think might resolve this situation, but it's never received any real uptake and I can see some serious issues with the approach. Instead of building a "inner system" (https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect) where the browser uses HTML, CSS, and Javascript to create interactive applications, or attempting to make a sandboxed and highly limited execution environment (WebAssembly), browser tabs should be Virtual Machines- in the sense that VMWare, KVM, and HyperV are VMs, not in the sense that some language runtimes are VMs. Think about it: every tab on your machine could be its own little machine running a full stack and rendering the output to a framebuffer (the tab window content). It provides precisely the sandboxing and virtual IO that existing VMs have already implemented and optimized. But of course, if you do this, you don't actually need a browser window with tabs: you just render the application to a standalone window. But then really what value does the browser provide, other than giving you some convenient runtime for accessible web resources? So just put the browser runtime in the operating system and host applications within virtual machines. Nothing stops you from building applications using web frameworks- you can still use javascript, HTML, and CSS if you want, within or seperate from existing high quality graphics application frameworks (like Qt, GTK, etc). Those reading carefully will note this is exactly what (some) operating systems have been capable of doing for longer than the WWW has existed, and all major operating systems now support this natively (KVM, HyperV, Apple Hypervisor) and they also all embed full browser capability in native libraries. The main issue I see is that there are now 2 or 3 hardware architetures (x86, arm, risc-v) and a VM does not directly resolve performance issues of cross-arch translation, so devs would still need to produce binary packages for 2-3 archectures to reach the level of cross-OS compatibility that browsers currently support. I work frequently with Qt and it's amazing how much better it is for building powerful, complex applications that have long term support.
  • tkcranny 2y ago
    Reminds me of: https://xkcd.com/1367/ https://xkcd.com/1367/ Webpages being rendered framebuffers would be terrible for consistency and accessibility. All the logic for layout computation, responsive design, font rendering, and literally thousands of other things browser have developed over the decades would go out the window. But on the topic of multi-architecture, that’s really what web assembly is. I’d be surprised if it didn’t continue too become more important, it looks like it’s escaping the browser and into backend apps and server code too.
• iamleppert 2y ago
  Make no mistake, the engineers who come in and want to immediately change to another framework, that is purely by design and an organizational play. The goal is to have the team switch to an unfamiliar framework, but one you know well, so you can divide and conquer the team's productivity. It's a great promotion strategy when you're a newcomer with high productivity while the rest of the team is struggling.
• ysabelbristol 2y ago
  [dead]
• toddwprice 2y ago
  I also miss the web. When HTTP form posts were a thing. React and friends are desktop apps, delivered over HTTP, where the browser is the runtime. You know why we got so obsessed with JavaScript? Cause screen refreshes look janky. "Just use XMLHttpRequest to send the data ONLY over the wire! And get data ONLY as a response!" That's how we got into this mess. I'm not saying you don't need JavaScript, or there aren't reasons to use React. I'm saying there are easier solutions to jank. If good engineering is the ability to design the least complicated solution to a problem, we are far from good engineering.
  • AgentME 2y ago
    It's weird to see React frequently treated in these kinds of discussions as the opposite of the good-old ways of doing things because React has great support for server-side rendering and form posts. Its server support was one of its major features that initially distinguished it from other front-end frameworks of the time and helped lead to its popularity.
• guybedo 2y ago
  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
  • lars_francke 2y ago
    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.
    • CharlieDigital 2y ago
      I have a semi-technical friend who's built a whole SaaS with paying customers (currently $x,xxx/mo) using nothing but AI and an occasional bit of hand tuning. He has some knowledge of the space and technical terminology from managing devs and projects, but was never a developer or engineer himself. I watched his approach once and it's totally different from mine when I tried AI. He tells the AI what to do and if there's an error, he copy+pastes the error from the dev tools and says "fix this". And he'll keep cycling. When this happens to me, I think too much about the error and perhaps I'm too specific to the AI on how to fix it. He just lets the AI do it over and over until it gets it right. He doesn't care how the code looks, what libraries are used, etc.; the only thing that he cares about is "when I click this, does the right thing happen". It's actually kind of insane what he's built solo over a period of 4 months or so.
  • pttrn 2y ago
    “I just fuck around til it works”
• guybedo 2y ago
  fwiw i've added a structured summary of the discussion here: https://extraakt.com/extraakts/frontend-development-churn https://extraakt.com/extraakts/frontend-development-churn
• lo_fye 2y ago
  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.
  • skydhash 2y ago
    > You can change frontends any time you want, or you can run multiple frontends simultaneously. Everything important, including validation, is handled by the database. Or you can properly architecture your application and move the logic layer to a language with better tooling.
  • JamesonNetworks 2y ago
    My experience with this at one company is the DB became a wild west of cowboyed sprocs that were in source control but a lot of times the sproc in the db didnt match the stored code. It became a way to skirt code reviews and push changes fast. Now, the environment was toxic to begin with, and maybe that wouldnt happen on a project with better technical leadership, but there is a lot of wiggle room for hanky panky at the db level
• deleted 2y ago
  [deleted]
• timewizard 2y ago
  > If your product is still around in 5 years, you’re doing great and you should feel successful. But guess what? Whatever framework you choose will be obsolete in 5 years. Frontend guys crack me up. The browser is an extremely advanced environment and ES6 is an extremely powerful language. You don't need a framework. You haven't for 10 years now, which is probably why they're so easy to replace, they're wrappers of very thin technology and very thick opinions. The only reason to use one is if you want to share code between the web and a native app, otherwise, it's a complete and total waste of your engineering efforts.
• proc0 2y ago
  I think there's a big part of the picture being missed here. Frontend is bad because of how the industry treats frontend engineering, and web engineering overall. Companies will make engineers do way more than just focus on the code and build things properly and correctly. This is why they all gravitate towards the new, shiny library and over time the ecosystem is a huge mess of dozens upon dozens of libraries just to build something simple. They want engineers to be more like a technical entrepreneur, thinking about how to add value to the business, and this comes at the expense of building things properly and correctly. > On a more personal note, this is frustrating to me because I think it’s a big part of why we’re seeing the web stagnate so much. I still run into lots of devs who are creative and enthusiastic about building cool things. They just can’t. Yes, because they're not allowed to just code. It's no longer enough for the role, and the expectations include everything from talking to stakeholders, to crafting the requirements, to testing, releasing, and doing the telemetry and analyticis. Obviously nobody will have the focus or time to build anything properly this way, and they will always choose to use external libraries instead of making something from scratch that will fit the domain space and will allow full control to build something with no bugs. It's amazing how the industry has accepted that bugs are normal, and part of building frontends, when good engineering should mean that you are able to build and ship something with almost zero bugs. The industry has changed the role and steered it away from what engineering is supposed to be, which is building things properly, and now people are scratching their heads as to why we have such bad software and everything is so complicated on the frontend.
  • skydhash 2y ago
    > They want engineers to be more like a technical entrepreneur, thinking about how to add value to the business, and this comes at the expense of building things properly and correctly. The reason is that most business are marketing driven, where the focus is let's try this to see if it sticks. Everything from the product to the technical implementation is a prototype where no ones can articulate a specification for anything. The same has infected Windows and macOS where no focus is given to the whole, but it's just adding beta features on top of other beta features.
• Illniyar 2y ago
  I love it when people phrase this as a frontend problem. It's not a frontend problem. It's just a "it's a huge ecosystem with new players" problem. I've seen this in Java 15 years ago when it was the front of innovation (I can name dozens of frameworks, and a half dozen build systems coming out in as many years). React 17-18 is quite a minor change then perl 5->6 or python 2->3 For backend instead of "let's use this new framework", I get the "let's use this new LANGUAGE" - the newest hottness is to rewrite something in Rust. It was Go before that, haskell, scala, F# (yes I got that too). You think migrating your frontend code from react to svelte or whatever is troublesome, trying rewriting that VB 6 app :) (Or god forbid something like RPC where your data is in the code) Not saying that the unstableness of engineering practices aren't a problem. It's a huge problem. Just that it's not a frontend problem.
  • dpcx 2y ago
    React has been around for 11 years. The amount of stuff that's online that tells you to do something with it one way when the react devs tell you to do it another is _astonishing_. And that's just from the last few years. Or take webpack that's been around for 13 years. The way things are set up even within the last few years have changed dramatically. If Apache configs moved as much as these systems did, no one would use Apache.
    • montag 2y ago
      imo, the Webpack situation is worse. React's evolution has been more incremental/cumulative. Best practices evolve, but not too much truly needs to be forgotten.
    • theknarf 2y ago
      No one is using Apache... Almost everyone moved to Nginx years ago xD
      • le-mark 2y ago
        The configs are very similar though, the reasons for the move were technical and performance, for whatever that’s worth.
• dcchambers 2y ago
  I was once hopeful that WASM would bring some sanity to browser but...I don't know any more. That was also when I thought (assumed) WASM would get the ability to manipulate the DOM directly but it seems like that's not what the browser overlords want to happen. Having a dependency on javascript doesn't change much IMO.
• brainzap 2y ago
  express.js and vue.js with axios/bulma css, has not changed that much in 10 years
• pier25 2y ago
  It's not a frontend problem but a JS-ecosystem problem. Happens in the backend too. The JS landscape is an absolute mess where dependencies have dozens if not hundreds of other dependencies. As an example, this is the dependency graph of Platformatic (a Node framework based on Fastify): https://npmgraph.js.org/?q=platformatic#zoom=h https://npmgraph.js.org/?q=platformatic#zoom=h Each of those dependencies could be abandoned at any moment. Even huge dependencies like Axios or Express seemed to have been abandoned at one point. And then each dependency is ruled by whatever their maintainers think is right. Just the other day a dependency I use in prod with aprox 25M downloads per week (React is aprox 26M) and used by 10M Github repos decided it was ok to drop support for Safari versions from about 3 years ago. It's just insane considering Safari has +50% mobile market share in the US.
  • antfarm 2y ago
    368 dependencies, 179 dependencies with only one maintainer. 8 different licenses used. No thanks.
• allenu 2y ago
  I wonder how much of this has been driven by ZIRP, making companies a little bit more lax on what they were spending energy on. Teams are large and devs are decoupled from the end user and end result (PMs, designers, leads, managers have more say on the product being created). That, coupled with devs traditionally, IMO, being enamored by system design and wanting to create even more efficient systems for building things, and given that is the one thing they have direct control over (not the end user experience and product), they would naturally want to focus their efforts on improving their systems for building things, at the sake of missing out on the bigger picture, which is that rebuilding systems has a cost that does not directly translate into net user benefit. When you're closer to improving the bottom line in terms of sales and user joy, I think there's a greater likelihood that you focus less on spending time rebuilding your platform to whatever is currently hot on the scene. (Not to mention internal promotions may be skewed towards clear engineering efforts vs. more qualitative user-perceived improvements.)
• ozim 2y ago
  I am quite some time in the biz but I see it as a feature not a bug. I was waiting until we get rid of IE6. Nowadays no one will support anything for dozens of year so you would have to take care of some bug ridden monstrosity because it will get decommissioned because it will just stop working and cost of supporting it will be higher. Your CRUD web app is not a nuclear powered plant to run 50 years.
• jweir 2y ago
  We use Elm for any complicated front end. Elm has not been updated in over five years.
  • tasuki 2y ago
    People say "Elm is dead". Yes, and that's one of its many amazing features! I'm not a frontend developer, but I'm always looking forward to writing frontend these days!
• mattlondon 2y ago
  Just 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 https://angular.dev/update-guide) I've been using it at BigCos now for years and it's really just totally fine, and importantly zero drama. They key thing is you only need angular so you don't need a whole fleet of dependencies that you also need to migrate at the same time.
  • JamesonNetworks 2y ago
    Upgrading to standalone components and the new signal API right now, not sure I’d say this avoids the frontend treadmill
    • mattlondon 2y ago
      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?
      • JamesonNetworks 2y ago
        You may not have to today, but you will one day. They will remove zone.js and there will be a whole host of deprecated libraries and outdated blog posts about how to do things the “angular” way. If the vite dev server didnt feel so much snappier, I would lament it, however, I think overall its a nice change. And sure, just change components while you are in there, but this is for my blog libraries I work on in my spare time. A lot of the standalone stuff just feels like change for change sake and the scripts did not run against a library project. I tried to dig into the @angular/cli repo to try and figure out what was going on, but after reading a few classes noped out and just converted by hand. Only takes a couple of hours or a day to test, but thats 0 productivity time. Change detection is different now and leveraging ngOnChanges is def broken now, zone js removal is experimental, and all of it so Angular becomes more like React as far as I can tell. My new projects are Django with templates and post backs. Its a breath of fresh air.
• medhir 2y ago
  Front-end engineering is incredibly driven by the “fashion” of the moment. The only framework that seems to have maybe overcome fashion is React. Though React is plagued with its own churn around trends. Perhaps this is aging me a bit but I still can’t get my head around why we threw away class-based components with clear lifecycle methods. I use hooks regularly now but it just feels so much less elegant than the perfectly fine solution that came before it.
• nimish 2y ago
  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
• turnsout 2y ago
  Just 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.
• H1Supreme 2y ago
  Considering all the advancements that Vanilla JS and CSS have made in recent years (plus exciting features like animating "display: none" that are almost fully adopted), I think templated HTML on the server + JS where it's needed, makes more sense than ever. And, that's coming from someone who largely makes their living from React. Like the author, I've been doing frontend in one way or another for 20 years. The ecosystem, churn, and the absolute juggling act of sync'ing state between the frontend and backend is batshit crazy. I recently started a proof of concept project using Go templates and HTMX. I'm trying to approximate building a UI with "components" like I would with React. There's still a lot of rough edges, but it's promising. I'm still not sure I need HTMX tbh. I've started managing event listeners myself, and I think I prefer it. Interestingly enough, managing complex UI state that's based on user roles and permissions is so much easier on the server. Just send the HTML that the user is allowed to see. Done. That said, React, Vue, et. al has sooo much steam. I don't know how a collective shift in thinking would even begin. Especially considering all the developers who have never known anything but frontend frameworks as a way to build a UI.
• meshweaver 2y ago
  > New developers are having an extremely hard time learning enough skills to be gainfully employed. They are drowning in this complex garbage and feeling really disheartened. > We need to relearn what the web is capable of and go back to that. > And it [the web] has only gotten better over time while retaining an incredible level of backwards compatibility. I would suggest that "retaining an incredible level of backwards compatibility" might be one of the sources of this "complex garbage" the web world is drowning in. The fact that so many people feel the need to reach for a framework makes me wonder if the web doesn't do nearly as much as it needs to do. Maybe the web will always just be too big, too slow to change, and too bad at pruning out all of the bad ideas that accumulated over the years. "But what about backwards compatibility? Don't we want all the old web apps to continue to work forever?" Yes, so ship the renderer with the app. Sure, the current web is probably beyond being able to this, but I'm sure we'll eventually find a far better way to distribute software than the web, a way that makes fewer assumptions about the environment our code will run in.
• jongjong 2y ago
  It is kind of gaslighting to say that frontend frameworks don't last more than 5 years when React has been around and popular for more than 10 years and the vast majority of FE jobs today are React. When I read comments suggesting that frameworks keep changing, it sounds like the kinds of articles which were written 7 to 10 years ago. It made sense to say that back then, the top frameworks DID keep changing. Nowadays it just sounds very strange... It's like complaining about something which is no longer a reality... But which actually turned out to have been a good thing all along. I actually liked that different companies used different frameworks. It mirrored the reality that no framework is inherently superior to every other framework for every use case. I hate the pretense that React is the silver bullet while simultaneously pretending that it's an underdog struggling for relevance in a world of relentless framework-churn...
• deleted 2y ago
  [deleted]
• notnmeyer 2y ago
  all i know is that nextjs is the absolute worst
• anymouse123456 2y ago
  I've been writing UX code professionally since the late 90's and for many years, I have led teams that build relatively complex UX software products at companies you've surely heard of. It took me about about 5 years before I began to realize no one I had met, had any idea how to do this work in a way that wasn't horrible. I held out hope, and thought maybe those other super-smarty-pants folks over there had it all figured out. It took another 10 years to figure out that they most definitely did not have anything figured out at all. Functional weanies, OO nerds, Imperative Prima donnas. No one. Has GUI figured out. Not Apple, Not MS, Not Linux. No One. I've worked professionally in every language, every framework, every paradigm. I've tried it all. Writing Graphical User Interfaces is HARD. The problem is that the problem is HARD. Graphical User Interfaces (for anything reasonably sophisticated) represent broad and deep, hierarchical, tree-like (or graph-like) projections of large amounts of domain information PLUS some amount of administrative debris. Changing any state of any node in these large and complex data structures can and often should cause some other node in some faraway sub-branch to instantaneously be updated. Sometimes, that node is on someone else's computer. Almost always, there's a replicated, similar, but different version of that information on a server somewhere that really must be kept in sync. The problem is made exponentially more complex when we just drop in some little multi-user, real-time update stories. This thread is a great example of people shitting on the whole field, and yet... Not one person has figured out how to make front-end development not suck. The problem appears to be deceptively simple on the surface, and like those sirens, it calls out to weary sailors, only to leave them shipwrecked on the shore. Funny enough, it turns out that Text-based User Interfaces (TUI's) are far more expressive and exponentially easier to author and maintain. They just have the little, teeny problem of being a sheer cliff face that users must ascend in order to get anything useful at all. It's my bet, that the world will be saved by some mixture of Text and Graphical UX that is primarily rooted in Text, but enhanced by graphics, rather than the other way around. This whole LLM thing looks kind of interesting on that front. I suspect we'll all look back on the last 30 years with contempt and remorse at all the wasted time and energy we've put into this mess that we've created that is called, "Graphical Applications." Feel free to rant on about how shitty everything is, but just remember that at least one person out here in the ether knows that your solution either doesn't exist (most likely) or is even worse.
  • 2y ago
• SeanAnderson 2y ago
  I think this issue will slow down as LLMs become more prominent. I find myself being naturally dissuaded from the "shiny, new thing" because it means my LLM won't have a deep set of materials to draw from. Writing in Bevy was really hard because it was a niche language that has breaking changes every three months. Writing in Svelte has been decent/good, but LLMs constantly prefer using v4's syntax rather than v5's runes -- even with Cursor rules and reminders. At some point I think the tools will become so overwhelmingly part of my workflow that I'll prefer sticking with the old rather than moving to the new and losing access to well-written LLM code code.
  • api 2y ago
    This sounds like it could also be a terrible thing: LLMs freezing progress in languages. It’s kind of analogous to how the entire web became a slave to SEO.
    • SeanAnderson 2y ago
      I agree. I'm concerned with the implications, too.
• FpUser 2y ago
  I sometime hire web developers to do frontend for my clients. 90% of the time when I talk to them all I can hear is - can we use / rewrite with X/Y/Z/etc framework. Needless to say that I tell them to take a hike right away. I usually ask how would you implement this and that workflow using plain JS (using some specific libs is ok).
• nfRfqX5n 2y ago
  It’s really not that hard. Software needs maintenance, big deal. This is why we have a job. Everyone complaining in this thread about trivial things like upgrading a build tool once every 5 years is hilarious
• beders 2y ago
  > 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.
• adamredwoods 2y ago
  >> The frontend ecosystem is kind of broken right now. Everyone claims it's broken, then builds a new framework.
• wraptile 2y ago
  Vanilla JS and the default browser capabilities are quite incredible these days. Server-side templating (jinja2, twig etc.) + vanilla js and some library sprinkle (htmx, graphs) will cover 99% of all web use cases and continue working 10 years later faster than most new stuff. I recently adapted 3 open source dashboards made in react, alpine and vue to just vanilla JS for my use case and saw at least 100x speed increase. Data rows that took 2~ seconds to render were visually instant. Granted, the original dashbboard code lacked some optimizations but the vanilla code I replaced it with didn't really do any magic to begin with — just got rid of the incredible overhead these frameworks introduce by default.
• d--b 2y ago
  Author misses the point. There are now basically 2 answers: - go with vanilla html js + some css stuff à la tailwind - go with react for anything with more dynamic interaction I am not a huge fan of either, but anything else will be costly either in hiring opportunity or in terms of “shit I can’t use that dependency in my xxx framework”
• nextts 2y ago
  > People that are learning the current tech ecosystem are absolutely not learning web fundamentals. They are too abstracted away. This might be the solution in many cases. For small projects vanilla js is quite pleasant to use. For bigger projects React helps structure things for sure. I am for "vanilla react", or prop drilling, hooks and context. No state libraries or fancy shit.
• micheleAM 2y ago
  A wise man once wrote, "There is nothing new under the sun" (King Solomon, ~2500 years ago), but the frontend cult refuses to accept that. They reinvent the wheel multiple times a year, failing to realize they are going in circles. Every so-called "new" thing falls victim to the Pareto principle — it solves only 80% of the problems introduced by the last shiny thing, meaning progress is merely asymptotic. They also seem oblivious to the short history of programming. In general, there are three main branches: imperative, functional, and logic programming — with the latter two being built on imperative foundations. Yet the frontend cult acts as if they're groundbreaking by introducing pattern matching via discriminated unions in TypeScript, a concept that has existed in functional and logic programming for over 50 years. In other words, they behave like brats.
• ncpop 2y ago
  Probably a little more than 10 years ago I made a project with Django and Angular 1.x. I had a look at it again recently and managed to update Django to v5 with very little effort. The front-end however would obviously need to be completely rewritten.
  • globular-toast 2y ago
    AngularJS hasn't just disappeared. There are security issues that are now unpatched, but what's the risk here? Users attack software running on their own computer?
• hyperbolablabla 2y ago
  As a frontend engineer, I see the proclivity frontend engineers have for fully rewriting their codebase in a new framework for literally no reason all the time. It drives me absolutely bananas. This would never happen in game dev.
• julik 2y ago
  I wrote https://blog.julik.nl/2024/03/those-people-who-say-no https://blog.julik.nl/2024/03/those-people-who-say-no in response to that Mastodon thread back when it was posted. I fully agree with the article. The problem, I believe, is that "getting off the treadmill" is incredibly hard if you have no authority to push for "getting off the treadmill", and when you get labeled as a problem when you suggest the "getting off the treadmill". I do believe that with the end of ZIRP delivering more with smaller teams and being forced to make more pragmatic choices will be a net positive with this.
• dguest 2y ago
  Is the frontend treadmill responsible for making browsers so expensive to maintain? Sorry for the incredibly naive question. I've only ever worked on "backend" projects. A few times I've made simple read-only pages in raw html (and maybe some CSS) to share information with colleagues. So while I get that the web is more awesome now than it was 10 years ago, I don't have any concrete understanding as to why this is a multi-billion dollar industry.
• hsuduebc2 2y ago
  It’s kind of wild that local storage is still the go-to in most places. Just a single big string, and the only way to handle complex data is by endlessly serializing and parsing one massive JSON object.
  • owebmaster 2y ago
    That's a technical problem, most frontend developers (or backend monkeypatching FE code) are not capable of using IndexedDB.
• saos 2y ago
  > People that are learning the current tech ecosystem are absolutely not learning web fundamentals. They are too abstracted away This hit hard.
• admiralrohan 2y ago
  The frontend space will surely change to accomodate AI. We may go back to pre-framework days if we don't need that much complexity anymore. If we start to rely on AI Summaries we won't need complex interactions. Just beautiful charts to explain data.
• grishka 2y ago
  That's why I haven't even bothered getting into the atrocity that is modern frontend. I still build stuff mostly like it's 2007. In my projects I don't even have much of a frontend — most of the functionality works without any JavaScript whatsoever — but the JS that I do have has to contain exactly zero third-party runtime dependencies. I'm okay with self-contained third-party scripts like Leaflet for when I need to display a map, and I'm okay with build tools like TypeScript and PostCSS. But that's it really. I'm not having any of that abstraction-over-single-platform nonsense.
  • elevation 2y ago
    This approach is ideal until you try to grow your design team. People will poke at your code for money but it takes a while for them to orient to doing things without their heavy environments.
• theknarf 2y ago
  I think he have a good point, you shouldn't be switching frontend tech all the time. Focus on making a good product. > If your product is still around in 5 years, you’re doing great and you should feel successful. But guess what? Whatever framework you choose will be obsolete in 5 years. However I feel like this point isn't entirely correct. According to StateOfJs [1] React have been the most used frontend library for the last 8 years (which I think is how long the survey have been done). React Hooks which is the modern way of writing React components have been around for 7 years (since 2018). React is definitely going to be around in 5 years, and most likely still going to be the most used frontend library. I also don't think Vue is going away in the next 5 years (Angular might however, they are loosing usage numbers year after year). So really I think there is an argument to be made that you should just use React and move on. [1] https://2024.stateofjs.com/en-US/libraries/front-end-frameworks/ https://2024.stateofjs.com/en-US/libraries/front-end-framewo...
  • BurnGpuBurn 2y ago
    Funny story. I started a new job in 2017 rewriting a rather large website with tons of functionality. The old one had to be replaced because it wasn't maintained and started to become a security issue. I started doing JS and React/Redux for that job, and just as I was getting the hang of it React broke all my knowledge by coming up with "the modern way of writing React components", hooks. In my opinion there was absolutely nothing wrong with the old way of writing components. I never rewrote my now more than year old project, kept using the normal way of writing React components, which was still allowed. Two years later the depreciation messages started flashing by in the build process, and I was looking at a moutain of work having to refactor the complete front end. Luckily I was able to move on to other things. But React always left the taste in my mouth of "don't, it auto-breaks after time". I recently visited this old employer, and they have now hired a new coder to rebuild the old website, which is becoming a security issue.
• gr4vityWall 2y ago
  Doesn't seem to be a popular opinion here, but I think FE can be ok. A typical React application feels easier to reason about than HTMX-based code that I looked at. I never had a hard time picking up an app that used React/Preact + Tailwind + some simple state management library like Preact Signals. Maybe never having had to deal with GraphQL or Server Components helped. Tooling, OTOH, does feel like it gets insane from time to time. I don't know why we needed such a painful migration to go from CommonJS to ES Modules in Node.js. They always just 'worked' in Bun, and even Node.js has a flag these days to allow you to use both of them together. ESLint changed their configuration format and instantly made every existent tutorial/configuration available out of date. I fail to see how anyone benefited from that. It's not as popular these days, but I appreciate how Meteor always made an effort to be backwards compatible to the extend it was possible. The only __major__ migration was going from Fibers to Promises - and I don't blame them for picking the wrong 'horse' 13 years ago. But yeah I feel very comfortable doing FE these days. Meteor for bigger fullstack apps, or just Vite for a simple FE, and things just work. TypeScript tooling is better than ever. AI helps automating lots of the simpler but tiring tasks like generating Zod schemas.
  • gr4vityWall 2y ago
    I also want to add: the new hooks introduced by React 19 seem like a complexity creep. But I haven't found any need to use them yet.
• joduplessis 2y ago
  > Whatever framework you choose will be obsolete in 5 years. I must be living in a different reality, because most of the frameworks 5 years ago are still being (actively) used.
• canyonero 2y ago
  I think it’s reasonable for the author to feel like Frontend is a treadmill. It can at times without a doubt be tiring. It certainly was moving much, much faster in the 2010s (although, I think it started to cool down in the 2020s) I don’t think this specific problem targeted at Frontend or Frontend frameworks is necessarily useful other than to vent. It seems this can be attributed as an effect of swelling technology communities. Frontend has been a community with explosions of ideas, high levels of participation and enthusiasm coupled with opportunities for notoriety and wealth. One could argue that AI is currently experiencing a similar phenomenon as Frontend did in the 2010s. If it follows a similar trajectory, we’ll be seeing articles about AI treadmills.
• owebmaster 2y ago
  When I started coding, 20 years ago, the frontend was HTML+CSS+JS. Now, it is still HTML+CSS+JS. The most used backend was perl/Java/C/C++, which is not the case anymore. So which one changed more, frontend or backend?
• heisenbit 2y ago
  A big part of the treadmill is that frontends are seen as interchangeable low level investments steered by sales. Short term superficial requirement drive development often by an external team. Funding for sustaining them is scarce. So after a few years - the original team disbanded except maybe a small fraction and when the list of must have changes become too painful a new team is assembled and with it comes a need to differentiate itself from the legacy and assert control of architecture and purse.
• deleted 2y ago
  [deleted]
• rglover 2y ago
  This is exactly why I'm building Joystick [1]. I got tired of the constant indecision and churn in JS frameworks, so I've built (and am actively building) a full-stack solution that features a simple component API that doesn't change, backed up by a batteries-included Node.js backend. All wired together so it's easy to use and fast to build your idea (for real, not just marketing fluff). Purposefully designed for people who are trying to build real businesses, not tinkering around to pad their resume. The best part? I'm a tyrant about backwards compatibility, stability, and longevity (meaning, even if nobody else uses it, I'll be maintaining this for the long-haul). For the cynics: for the love of all that's holy, do not send me the XKCD cartoon about standards. I deeply care about solving this problem and this isn't "just another JS framework." It's a replacement for all of the "just do everything on the client" buffoonery and it works incredibly well. [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
• derekzhouzhen 2y ago
  The frontend world gave you many fancy toys; but they all come with hidden cost. It is your choice: do you want to stay on or get off this treadmill? My need is modest, so I got off. I rewrote my simple SPA from Svelte to SolidJS to no framework at all. Now I have ~1000 LOC javascript, ~500 LOC CSS, all written by myself. No framework, no package, no build step. If you want to see it in action: https://airss.roastidio.us https://airss.roastidio.us It is a fully functional RSS reader. You are welcome to poke under the hood. The key insight is that I don't need reactivity, if re-rendering everything at every event is fast enough. I believe this style of barebone SPA programming can scale up to at least 10,000 LOC javascript.
• hasbot 2y ago
  IMHO, the root cause is HTML was/is not designed for building user interfaces. It's amazing what people have accomplished with HTML but, damn, so much work compared to using an actual UI toolkit.
• allex77 2y ago
  Someone knows some good framework or anything which I could embedd Haskell code in HTML to use in Canvas to see results immediately. I am just started learning Haskell. Someones have some exp.how to use LLMs for speed-up learning of coding in new language with new paradigm?:) Thx!
• allex777 2y ago
  [dead]
• allex777 2y ago
  Hi, are there any good frameworks which I could use embedding Haskell code in HTML to see results during code changing in Canvas. Someone use LLMs to speed-up programming language? Especially FP. Arebthere some good structured methods for this? Thx.!
• miragecraft 2y ago
  Use “survivor” frameworks, things that last a decade will likely last another. Tailwind, React, Vue, PHP/Laravel, Rails etc. are all very much alive and kicking. Plus there is nothing wrong with using outdated front end framework other than being unfashionable. The web is the most backwards compatible platform ever invented,
• bborud 2y ago
  I wonder why nobody seems to have designed a front end framework by sitting down and asking themselves how to express things clearly. Every single front end framework seems to have been designed by people just riffing on all the nonsense complexity already in the world. Odd syntax rules, lots of implicit behaviors and side effects, logic spread across at least 5 different domains etc. Why hasn’t anyone talented designed a front end framework? And before getting angry and downvoting me for this heresy: prove me wrong first.
• whoiscroberts 2y ago
  For any backend engineers that don’t build products because dealing with frontend is demoralizing… give the replit ai agent a test. I’m making better ui now than I ever could with bootstrap and jquery. Typescript + react + the right amount of prompting about code quality and maintainability and it produced workable interfaces plus some.
• hackburg 2y ago
  [dead]