13 ms·

Why is front-end development so unstable? (2018)

132 points by ddtaylor 4y ago

zackify 4y ago
I’ve been using react for 8 years. In that time I’ve gone from webpack, to vite. Lately using remix or nextjs. Not that much has had to change in that time, it definitely feels more stable in the past 5 years or so. Every new library is using components, just with their own preferred syntax.
- taeric 4y ago
  I'll agree it feels a little more stable in the past 5 years or so. I do have a sense that a lot of the UI libraries we used on our project are working fine, but are also deprecated and have a doom's day clock on them. Oddly, this is as much from "in house" widgets as it is 'in the wild" ones. Specifically, I know that if we want to bring in some widgets that were created this year, we have a massive upgrade task ahead of us. :(
- ldjkfkdsjnv 4y ago
  Yeah I actually think react is the stability. Its still here, still the main choice.
marcosdumay 4y ago
Hum... The Great (Web) Frontend Revamping seems to have passed. Nowadays people are still discussing if React or Vue is better, with a clear intonation of "whatever works for you, I prefer X". Looks like the field is maturing. Either that or we are on a fake calm before we see a lot of articles about people migrating into wasm in "whatever language has support for it right now" (AFAIK, currently wasm goes with rust).
- sircastor 4y ago
  This doesn’t feel that different to me from ~2010 era jQuery vs Prototype vs …Dojo(?) these things happen in waves. I’ve wondered if the next revolution will be wasm, or another round of JS magic… or something different.
- darepublic 4y ago
  Don't worry, view layer may be stabilizing but what about Managing backend requests is too complicated!(react-query) You *need* gql don't you? Don't forget forms. Super hard to do right. react-final form, react form hook, etc We need a monorepo framework! Nx, turbo, rush, pnpm (too low level), Lerna (too old and unmaintained) What about bundlers huh? Vite, esbuild, rollup, webpack I still see plenty of opportunity for teams to ignore persistent issues and just diagnose a new framework without analyzing their current woes. Silver bullets for everyone!
  - nicoburns 4y ago
    The difference is that's all ignorable. If you want to standard React with classes, redux, npm and webpack like it's 2017 then you absolutely can, and it's still a maintained and supported solution. That's very different to say the evolution from JQuery to Backbone to AngularJS to React where you ended up being on an increasingly unsupported platform if you didn't upgrade.
    - darepublic 4y ago
      It's not really ignorable, these frameworks come ready made with converts seeking to spread the good news to every codebase they find. Understanding, let alone improving, legacy code is a total waste of their awesome powers. It's raze the city and build paradise from scratch. Using shiny new framework (tm).
      - nicoburns 4y ago
        That's what tech leads are for. To be the person with experience and judgement who has the authority to set the rules for the rest of the team on these kind of questions. If you're having problems with this I'd suggest you have more of a hiring problem than a framework problem.
        darepublic 4y ago
        you might be right on the money with that. I mean it also reflects badly on me in regards sort of jobs I find myself in where this is a recurring problem. But.. I feel like it may be more widespread problem than most people admit.
- jansan 4y ago
  If you started with Vue two years ago, you had to learn Vue 3 shortly after that. With a new Vuex. Which has been dropped since in favor of Pinia. Oh, Vite has been developed since, so you may want to add this to your stack, because it makes compiling during development so much faster. Also, be aware of all the breaking changes that Webpack 5 has introduced. I hope front end development will be more stable in future, but the last two years where full of pretty major changes.
  - suction 4y ago
    The Vue 3 disaster (in my opinion) shook my trust in the framework forever. I immediately knew this is not a framework I will spend any more time in. What if I "upgrade" my apps to 3 and then Vue 4 comes along with yet another fundamentally different concept? This is not acceptable for apps with any kind of long time support requirement. Yes I know, Vue 2 paradigms are still usable in 3 but they feel very deprecated.
    - KaoruAoiShiho 4y ago
      Don't think Vue 2 to Vue 3 is that bad, certainly nothing like AngularJS to Angular. You can still conservatively upgrade piecemeal elements of your stack and most of the code still just works.
    - gherkinnn 4y ago
      Coming from Vue 0.x and 1, Vue 2 felt wrong. It didn’t know what it wanted. Classes and hooks and decorators and options and only some obscure combination offered acceptable TS support. Having only read the docs, Vue redeemed itself with version 3. There’s the options API we know and love from v1 and the new and intuitive composition API. The docs make it easy to decide and not to mix them up. And no useEffect fuckery.
    - runarberg 4y ago
      I inherited a vue2 codebase with a vuex store, and upgrading to vue3 and pinia one component at a time over a course of 3-4 months was quite easy. The upgrade path is really clear and they did a good job making everything compatible so that it could be made gradually over a relatively long time.
Atheros 4y ago
UI/UX is a fundamentally flawed field for a number of intersecting reasons, most of which boil down to not really distinguishing between when it's doing engineering, when it's doing psychology, and when it's doing fashion. And these days, on web apps and mobile apps, it mostly does fashion. Fashion must change for the sake of change. To more easily support these frequent changes, more libraries get invented to make doing new things easier. After that, everything in the article makes sense.
- csande17 4y ago
  > Fashion must change for the sake of change. To more easily support these frequent changes, more libraries get invented to make doing new things easier. The frontend "ecosystem" libraries discussed in the article are also subject to a fashion hype cycle, independently of UI/UX design trends. A lot of them don't actually make anything easier, or don't make rapid design iteration easier at least.
- sjtindell 4y ago
  I’m not sure fashion feels like the right term. People just assume newer equals better. So they want to use the latest and “greatest”.
  - azemetre 4y ago
    This sounds exactly like fashion to me. One just has to look at how often design has changed over the last decade with the many fads and worst UX. I feel like when you have an org of designers they will justify in wanting to redesign everything because why else do you need them? The same can be said for some POs and devs as well IMO.
    - fny 4y ago
      Yup. The most brutal environments I've ever worked in canned design folk very quickly once a cost crunch arrived. Some startups would even can designers first to save cash.
- deleted 4y ago
HidyBush 4y ago
The old saying goes like this: "if you want freedom on one layer you need stability on the layer below" My guess is that since frontend web development is at the top of the stack it has an incredible amount of freedom so everything changes every minute. You don't see too many people wanting to subvert HTTP making a billion homemade alternatives
- capableweb 4y ago
  > You don't see too many people wanting to subvert HTTP making a billion homemade alternatives No? I constantly come across new protocols, promising improvements compared to it. Some even become relatively popular and are included in browsers by default. Just some examples are WebSockets, WebRTC and QUIC. I expect we'll see more of them in the future as specific use cases requires more specific protocols.
  - ezsmi 4y ago
    I think you make a fair point but on the other hand I don’t see many “top 20 alternatives to http in 2022” articles (which implies there are more than 20 alternatives) like we have for front end technologies. I.e. https://www.netguru.com/blog/front-end-technologies https://www.netguru.com/blog/front-end-technologies
    - bobthepanda 4y ago
      I think part of it is also level of effort. You could right click "inspect element" in any browser and mess around in the html or the JS console and see things happening live. This is an extremely low barrier to entry. Low barriers to entry are good, our profession is very well compensated and developed economies could certainly use low effort ways to get people from lower compensated jobs into higher compensated jobs* but that also means that there are a lot of cooks in the kitchen. --- * yes, tech isn't for everyone (what job is?), and when I say low barrier to entry I mean you don't really need to subject yourself to what could easily be 5-10 years of schooling in medicine or law or engineering.
bigmattystyles 4y ago
I think that if you want a page to impress or make a splash then sure, you always have to move to the next greatest thing, however, I don't work for them but I've paid for Telerik Kendo Controls (the react ones specifically)since they were released, before then, the AngularJs ones and it's been great - it keeps my (albeit internal app) UI development stable, fast and looks great with minimal fussing about. It's been years now and it feels very stable and quick. The switch from AngularJs to React was the only unstable part, but it was at an inflection point in the number of apps I had to support and develop, so the change was actually welcome. YMMV (edit - I just realized I spent the weekend experimenting with MAUI, so I'm full of it)
- Etheryte 4y ago
  I had to read your comment twice to be sure we're talking about the same Kendo. I've consulted for a number of companies over the years who have used it (or tried to use it), ever since the jQuery version to up until now, and it's always been pure pain. I understand how their components work, I understand the underlying architecture because I've stepped through it too many times with a debugger, and I still always fail to understand how they have any happy customers. Perhaps there is a good experience to be had if you only use the components exactly the way the documentation examples use them, but the moment you step outside that narrow path, things fall apart. Never mind custom code, simply using two different components from their library together doesn't even always work. The first time I had a bout with Kendo was some odd ten years ago, and then I was sure it was simply me not understanding the framework. After all, every component library has its own kinks and it takes a while to get up to speed. After seeing them again and again many times over the years, I've changed my opinion. In my eyes, Kendo is what I like to call an MBA trap. It ticks all the boxes that an MBA manager going by a feature checklist is looking for, but under the hood it's garbage software. I'm glad you've had a good experience, at the same time I don't think I will ever stop recommending everyone to stay away from Kendo.
  - bigmattystyles 4y ago
    I don't agree with you but I don't disagree either. Our use cases are very vanilla, and now that I have quite a bit of sway in my team, when people deviate from the showcased Kendo way, I push back and see if the desired way deviating from Kendo is a necessity or a nice to have. If it's the former, we sometimes have the experience you described, though I've often be helped by stackoverflow, their forums or Kendo's support team. (We pay for the 24 hour tier). If it's the latter then I force the Kendo way. FWIW, their ODATA v4 support OOTB with dotnetcore webapi with its ODATA v4 out of the box with an EF model is the perfect pattern for most of our use cases. But again, I don't disagree with you either - but I would stress that any alternatives I've seen have their same range of issues.
RcouF1uZ4gsC 4y ago
I think part of the reason is the evolution of common user networking. Initially, users had low bandwidth connections, and web pages were mostly static with links. Then came JavaScript interactivity and AJAX. As users bandwidth grew, we started having heavier frameworks and SPAs. I believe there is another revolution that is happening now because of decreased latency. Recently with protocols such as HTTP2, web sockets, and edge computing, round trip latency is greatly decreased. This is resulting in UI where more of the logic lives on the server and has led to such libraries as htmx (client) and Turbo. It will be interesting to see where this settles out.
- crooked-v 4y ago
  React is also pushing in the 'edge computing' direction with Suspense and with major libs like Next implementing the idea of "server components".
- blueslurpee 4y ago
  Agreed, very interesting things going on in the "edge" space. I personally think this is why HN is so jazzed about things like fly.io. Super low latency opens up a whole new category of applications, it's a "step function" change in that regard.
anyonecancode 4y ago
Maybe I'm the odd one out, but I feel like the instability is mostly surface-level and FE is not, actually, so much less stable than other areas? I got into tech via web development, migrating further into the backend over time, and about four years ago became pretty much exclusively backend. Just started a new job and I'm back in the front end. Some things have changed, but not that much. - Typescript was just getting popular when I left, now it's basically a standard, but 1) after having been in javaland for a while, adding typing to JS makes a lot of sense to me and 2) though it's a change, feels like a change toward more stability, not less? - React was the big framework when I left, still is the dominant framework. - There's still a lot of option -- eg vue, etc. nextjs wasn't a thing I knew about that I am starting to learn now. Class syntax felt unecessary to me but seems to be de facto these days. But... these all feel relatively small? I started in FE back in the days of IE 6. jQuery was a godsend when it arrived, underscore was super helpful. I'll grant the shift from "we use JS to add some interaction, form validation, and sometimes interact with Flash" to "we use JS to write actual programs delivered via your browser" was a huge shift, but since we've made that shift it seems most of the "instability" is more around FE devs adopting practices already common in the rest of the stack. I think maybe that's where this sense of instability comes from -- a focus on the wide array of possible _implementations_ -- but I feel the really disruptive shift from "interactive decoration" to "web applications" was the really big one, and that's a while back now. And even with the dizzying array of possible implementations, there's obvious market leaders -- you're not going to go wrong by learning React, any more than you're going to go wrong by learning Spring Boot. Always good to explore and get familiar with other libraries and frameworks, but if one feel overwhelmed by options, there's some clear well trodden paths that aren't changing _that_ fast. One thing I will say is that I do think FE is _harder_ than BE, because the scope is wider. You need to grasp all the aspects of good programming, but _also_ get a decent grounding in design and UX, which are their own disciplines. A backend API doesn't have to think about things like screen readers or color contrast or all the weird ways users will figure out to misunderstand how to interact with your GUI widgets. A UI for humans is inherently harder than a UI for machines. But that's not the same thing as saying that the FE is unstable.
moonchrome 4y ago
Saying React support libraries are at fault here is not fair - React basically reimagined itself over the years and went from OO and class based components to hooks and functions. The fact that you can still do OO isn't really helping it since it adds to the complexity of things you need to learn to grasp the ecosystem. But that's honestly missing the forest for the trees - JavaScript itself went from asynchronous callback pyramid of doom, to promises and callback chaining, to async/await. The community went through multiple half-assed module approaches/specifications. Several FOTM bundlers with extreme complexity and various tradeoffs. Various build systems. Features like hot reloading, transpiling, source mapping, shimming are table stakes for any frontend framework and involve a lot of complexity and tooling - because the entire ecosystem is built on a foundation of shit that is JS and the browsers. So frontend frameworks are the least relevant part here - it's everything that makes them tick that's the problem.
- holoduke 4y ago
  I don't know one single UI/UX development environment which is elegant and nice. From Android to iOS to Linux to Linux and Windows to browser UI kits. They are all complex and require constant searching for answers. The libraries are very big and require a complex tooling setup. You can never be an expert in all of them. At least not me.
  - api 4y ago
    My pet hypothesis for years has been that developers always vastly underestimate the difficulty of doing a UI framework or environment. They think it'll just be a matter of painting widgets and presenting data. As a result they under-build the foundation. The insufficient structure is then released out to the world for everyone else to build upon. Once people realize the soul devouring chthonic difficulty of doing good modern UI, they've already built on a shit foundation and been forced to realize the full system with a heap of ugly hacks and workarounds. Then someone thinks "wow, this is way too complex! All I need is a simple UI." Then history repeats. You can see this with immediate mode clean simple GUI library of the week. They all stagnate after getting all the basics working, and there's a reason for this. A good mature modern UI is at least on par with a high-end game engine like Unity in terms of feature surface area and difficulty. In some ways it's worse because while the breadth and size of the problem domain is similar the problems you encounter in a game engine are probably a lot more fun. UI is a hell of incredibly hairy state management and a really long tail of edge cases.
newbieuser 4y ago
I think we should stop talking about libraries and talk about the crap of browser specs. Libraries are just a tool and evolve over the years. but browsers are getting worse every year
- eyelidlessness 4y ago
  Asking sincerely because this take is surprising to me: which specs are you referring to? From my perspective—started front end, gradually went full stack, spent several years fully back end, dove back in a couple years ago—quite a lot of the APIs introduced in the period I was fully back end (and since) are excellent and vastly improve both development experience and the ability to deliver a better user experience. I’m not saying your take is wrong necessarily, I just don’t immediately relate to it and I’m curious what specifically you find objectionable.
  - spiffytech 4y ago
    > Asking sincerely because this take is surprising to me: which specs are you referring to? I'd like to see the Web Components spec revisited: it has a) no API for passing non-string attributes to other web components, b) no API for declaratively updating your DOM subtree - you either do manual surgical DOM changes, or blow away your (potentially stateful) children and recreate them. Without these, the raw web components API isn't suitable as an alternative to React et al. You've got to build a whole framework around them (like Lit), and at that point you're just using another framework.
    - eyelidlessness 4y ago
      I haven’t worked with web components, and have only had a passing interest generally. But oddly enough I took some time today to dive deeper. It occurred to me that some of the APIs would potentially benefit some work I’m doing in a legacy project. I’m not an expert on the topic, but I have a few thoughts. First, I agree both of these limitations make the spec less directly useful than a framework, and more likely to be APIs targeted by a framework (however formal or bespoke). That said, that’s pretty much the guiding design philosophy behind nearly all DOM APIs, and it doesn’t seem to me that makes anything worse, just incomplete. I suspect that richer APIs would make things worse. People would still use frameworks, but those frameworks would have to use much more opinionated and much less flexible APIs at a higher level of abstraction. All of that said, > no API for passing non-string attributes to other web components This is really a limit of HTML, and not new. But there’s plenty of precedent for raw string attributes to have a more meaningful representation in the DOM state. An area of the spec that seems really well suited to accommodate this is `part`[1]. Like `classList`, it’s a `DOMTokenList`, and has a corresponding CSS selector. It’s a string attribute, but it’s also structured data as a property. I have a long list of things I’m confident will benefit from this. > no API for declaratively updating your DOM subtree - you either do manual surgical DOM changes, or blow away your (potentially stateful) children and recreate them. This really is a footgun, but I’m not sure what the appropriate alternative is. I don’t think any spec could accommodate the fact that people choose different declarative implementations for very different use cases, without essentially defining high level interfaces that expect to be overridden. Even then, those interfaces would almost certainly be ill-suited to some specialization or another. If your goal was purely creation, I’d agree that there should be a declarative API. But for updates? I can’t imagine a design which wouldn't be worse. > Without these, the raw web components API isn't suitable as an alternative to React et al. You've got to build a whole framework around them (like Lit), and at that point you're just using another framework. I don’t think the goal of any of these APIs should be to replace frameworks. At that point you’re just using a framework forever. It’s an enormous credit to the design behind all of these APIs and their overlapping specs that they continue to produce useful lower-level interfaces without overly steering the ship. 1: https://developer.mozilla.org/en-US/docs/Web/API/Element/part https://developer.mozilla.org/en-US/docs/Web/API/Element/par...
shaunxcode 4y ago
Because it is the frontier which by definition is unstable!
DrFell 4y ago
Because it's all social media trends driven by noobs?
jokethrowaway 4y ago
Frontend is the entry level field for all those people who were not developers but wanted a slice of the salary pie. Designers, architect, lawyers. I've seen everything. I know a few React engineers in my company who can make components and be productive - but they don't know JavaScript and they get stuck when something is slightly different from what they're expecting. Similarly I'm mentoring a few engineers who started with react and are trying to learn backend and other languages. Being the field where all the least developer figures start means you'll have tons of people, tons of visibility, tons of cargo culting and tons of crap being built just to make you look cooler. I'm guilty of this as well, I have my frontend framework on GitHub and it's quite useless - even if it's a nice idea. Of course nobody bothers to maintain stuff and everything is trying to make money on their junior devs fanboys.
heseyin 4y ago
lopatin 4y ago
The article starts off with an outdated take on the space: "We all know the meme: by the time you’ve learned one front-end technology, another three have just been released. Also, that one you just learned? It’s deprecated." Maybe it's because the article is 4 years old. I just don't think it's true anymore. Ok there's React and Vue and others, but that's fine. It's basically the same tech, but they have DX/cosmetic differences. It's not like we're still arguing whether or not VDOM is a good thing. That said, the "Imagine being a junior developer" section sounds spot on still. Maybe it's because those articles that use dogmatic arguments to recommend inferior technologies are still on the internet, and they are not going anywhere.
- croes 4y ago
  I thought VDom is old school since Svelte and such? https://news.ycombinator.com/item?id=19950253 https://news.ycombinator.com/item?id=19950253
  - lopatin 4y ago
    I was waiting for someone to mention Svelte :) I think it's is very possible that it's the next evolution of innovation in the space. It might actually be a Backbone -> React style quantum leap in terms of tech and adoption. The thing is, that won't happen for another 10 years, if it does at all. It could very well turn out to be a niche technology for most people, with minimal real-life benefits compared to the drawbacks of moving off the mainstream. Every space has new innovative technologies that risk upsetting the status quo. I'm not saying things are completely boring now. Just that, unlike in the mid 2010s, they are actually stable enough.
    - runarberg 4y ago
      As far as I know most native web components use direct DOM manipulations over a virtual DOM. So I think the jury is pretty much out on VDOM and we are witnessing it transition to a relic of legacy frameworks. As far as other innovations Svelte has brought, Vue with the <script setup> sugar looks quite similar to Svelte, as well as compiling to a render function (just like Svelte). I’m not super familiar with the intrinsics of Vue but the VDOM is starting to feel like a thin MIR of the framework which could be swapped out in a future major release, rather then something essential to it. I honestly think that 10 years is a very conservative prediction.
jansan 4y ago
Front end develoment has never been more fun if you can keep up with the pace. Finally all major browsers have decent standard support (no Internet Explorer anymore), so crutches like jQuery are not needed anymore. Developers constantly find new ways to implement front end apps, and they are not afraid to break backwards compatibility. This may be bad if you have an old monolith to maintain, but overall it's a good thing IMO. Also, this is not limited to libraries. Have you looked at what speed Chrome devs are implementing new APIs? It's insane. And great.
- jraph 4y ago
  > Have you looked at what speed Chrome devs are implementing new APIs? It's insane. And great. It's not great. It is bad, really. It means no one that hasn't dozen millions of dollars can implement or even just maintain a viable browser that can keep up. And since we expect browsers to be free, that means… "complicated" business models cough mostly¹ relying on ads and tracking cough to maintain the Web. I which it wasn't this way really. There was a time when it was possible for a few people to implement a quite good browser engine in their free time. KHTML. So good, in fact, that it was chosen as the basis of WebKit (and therefore Blink). This does not seem possible anymore. 1. There's Apple maintaining a browser engine without relying on ads, but their business model is also questionable.
daenz 4y ago
Fads are tempered by a community of people anchored in a deep understanding of the technology. As talented as many FE engineers are, I can count on one hand the number that I've met that have a deep understanding of things like await/async + Futures, closures, DOM trees, etc. These things are (perhaps unfortunately) required to do FE work, yet the engineers using them don't fully understand them, so they don't know how to discern if helper libraries are actually helpful. Additionally, I'd argue FE draws more junior people in general, because of the theoretical rapid feedback loop, and the fact that you can "make something that looks cool" with relatively little effort (relative to a BE engineer). These junior people add confusion to the chaos of the community because they don't know what they don't know, so they're cocksure about their opinions. And as long as they've "made something that looks cool", even if the architecture behind it is hot garbage, it buys them cred in the community. Somewhat related, I've been using Flutter for a recent FE project and I'm in love with it. It's more for webs/mobile applications than websites, but the ergonomics of it feel like a coherent vision. The people maintaining it (Googlers) are excellent, and the Dart library community seems to know what they're doing. Furthermore, the FE design choices are based on Material Design[0], which is backed by (some informal) research by UI and UX professionals, so you don't have to sweat usability quite as much as you would starting from scratch. 0. https://material.io/components?platform=flutter https://material.io/components?platform=flutter
- randomtwiddler 4y ago
  It's interesting how you can look down on front end for being new and naive while suggesting that Google is a fine reliable tech stack provider. I'm the opposite of everything about this post. A very experienced dev (>20 years professional experience) that has moved primarily to the front end recently in my career (gradually over 4 years). I won't touch flutter simply because the sole vendor and essential dependency is Google. Fads are present in every corner of development. As is "not invented here" or the general draw to green field.
  - daenz 4y ago
    If you're looking for a response, you're not really giving me much to respond to. Why do you think Google doesn't provide a "reliable tech stack" ? In any case, I wasn't suggesting that specifically (though I tend to agree with it), only that they have a coherent ergonomic vision by competent engineers.
blenderdt 4y ago
It also has to do with the low entry level. The same happened to PHP. Inexperienced programmers can easily create nice things that look great on the outside. Libs like React and Vue are stable enough but when you throw in a lot of other dependencies it is always the question how experienced the creators were. And when unstable libs become popular bugs and security issues are exposed, pull requests are created and before you know it a next version is launched that is not backwards compatible.
danenania 4y ago
A lot of it is that UI programming is just difficult and inherently complex. Expectations of users are very high and always shifting. Browsers/consumer OSes are constantly moving targets. Mistakes and bugs, even small ones, stand out in a glaring way, so there’s low forgiveness. There are more code paths and they’re harder to test. All that means that unless you want to miss your deadline by a year or leave a bad impression on users, you will need a lot of libraries! Backend/systems specialists always underestimate how hard UI programming is. Then they try their hand at frontend and quickly run into a wall. They find they either need to build something clunky that users aren’t impressed by or else spend a lot of time learning new tools and paradigms (and yes, installing lots of dependencies /shiver). This is a blow to the ego, so it’s better to criticize the language, the culture, the “churn”... anything to avoid admitting the pixel pushers are solving seriously tough problems too :)
- deleted 4y ago
  [deleted]
- daenz 4y ago
  >anything to avoid admitting the pixel pushers are solving seriously tough problems too :) That's not how I view it, as a SRE/BE-SWE who has done substantial visual/FE work. From my perspective, the majority of problems in FE are due to extremely poor libraries and standards, bolstered by a community where copying and pasting large chunks of unknown code is acceptable. Yes, there are "seriously tough problems" with trying to develop in that world, but they are of a different world than most BE problems, from my experience. So they feel comparably difficult, but for very different reasons.
dang 4y ago
Discussed at the time: Why Is Front-End Development So Unstable? - https://news.ycombinator.com/item?id=17190992 https://news.ycombinator.com/item?id=17190992 - May 2018 (354 comments) Why Is Front-End Development So Unstable? A Perspective - https://news.ycombinator.com/item?id=17182748 https://news.ycombinator.com/item?id=17182748 - May 2018 (5 comments)
zero_shift 4y ago
I'm the author of this piece. I no longer think front-end suffers the instability people accuse it of. I think there are a lot of _vendors_ trying to usher in a revolution around their particular products - there's a lot of VC funding in JavaScript tooling nowadays - but that's a different problem.
- dgb23 4y ago
  Some of the vendor backed libraries are among the best. But generally I would agree that marketing, especially certain types, generates a ton of noise, like you beautifully illustrated in your article. I think navigating the web with a BS filter on is an important skill to have.
- pljung 4y ago
  I enjoyed reading your article, thanks for writing it. I think your recommendation to new devs to focus on Next.js in 2018 (!) was prescient. > I no longer think front-end suffers the instability people accuse it of. Do you mind elaborating why you believe this is the case?
  - dylan604 4y ago
    >to focus on Next.js in 2018 (!) was prescient. now that it is 2022, what's the new flavor that would be prescient? I don't ask to actually know, but to reiterate the problem of nothing being solid in this world.
    - vosper 4y ago
      NextJS is still looking pretty good if you're in React land. There's new competition, like Remix, Astro, etc... but I don't see any of them putting NextJS to bed. I'm starting a new application, and I'm still choosing NextJS. (Now what you couple with NextJS for data access is an interesting question - this is where there's a lot of innovation. Personally, I'm going with tRPC. I would look at Edge DB, but in this application I'll need a recursive CTE and Edge can't do it.) Edit: I do think Astro might replace NextJS for purely-static sites, or ones where the "islands of interactivity" pattern is compelling.
pojzon 4y ago
Frontend is unstable because it attracts ppl whose attention span is often lower than the one of a goldfish. Every JS frontend dev I met was speedrunning trying to prove himself by "inventing something new" which in fact was already a state of art. The amount of rehashing and reinventing the wheel with new catchy names in the field is staggering. TBH, if the field wants to improve -> its time to ditch JavaScript and force Browsers to move to something that makes more sense.
- lopatin 4y ago
  Thank you! Part of the reason that I love these front-end threads is because inevitably somebody will make a fool of themselves by spouting anti-js-dev "backend master-race" nonsense, and this certainly did not let me down.
  - pojzon 4y ago
    It would be true if I was working in backend development. I dont. JS is just not good enough for what we want it to do. Someone sooner or later has to make a decision to move further.
    - doomroot 4y ago
      No. JS is here to stay, better get used to it.
    - rschachte 4y ago
      What is JS not good enough for w.r.t front-end dev in your eyes?
  - dang 4y ago
    Please don't post in the flamewar style to HN. It's not what this site is for, and it destroys what it is for. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - lopatin 4y ago
spion 4y ago
Lack of standardization is the primary reason we have this problem in the JS ecosystem. "Productive" ecosystems (e.g. Rails, Elixir) usually have one central framework that provides the standard basics. Libraries, tools and other extensions are built on top of the framework to enhance the feature set. Everything typically works well together. JavaScript has multiple frameworks to implement components, multiple tools to implement bundling, multiple tools to implement modular/extensible stylesheets, multiple package managers with somewhat different features (e.g. when it comes to monorepo support), and multiple libraries to implement basic standard functions. Many of these are not compatible with each other. Compatibility is a combinatorial explosion problem that cannot be solved without standardization. Without it, you need to have m*n modules to have m things talk to n other things. Extensions to the ecosystem therefore typically have partial compatibility with all the tools, which further widens the breadth of the problem. There's been very little effort in the community to standardize interfaces and protocols: but for the few things where it has been successful (e.g. see package.json) we've seen much nicer and smoother interop/tool interchangeability. We need more of this, especially when it comes to open-ended "plugin" style stuff (e.g. bundler plugins/extensions, component interfaces, monorepo structures)
sbf501 4y ago
Here's an unpopular opinion: it is unstable because we don't know what exactly "front-end" means. First it was static HTML pages, then it was CGI (ColdFusion & DHTML FTW!), then it was PHP, then it was Rails, then it was Node, then it was React, Angular, Vue... Those aren't random progressions. On the contrary, they are front-end devs responding to needs of the UX moreso than the UI. There have been major efforts to make reactivity match what the user is trying to do, but we're still in unstable-land because we're building the bridge while we cross (I hate that analogy but it is true). Just my $0.01.
- truthwhisperer 4y ago
- kbrannigan 4y ago
  Funny I started to rediscover PHP. It is so pleasant. Just by reading the documentation of Symfony, Yii I have learned a lot about web development.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
karmasimida 4y ago
I think it is getting stable recently. It is a choice of React/Vue/Angular for the most. Be hold there are some choices to make here and there, but if you go with a vanilla setting with popular choices (like Webpack for build), things won't go wrong. Not everything needs to be shiny and edgy. From that angle, the frontend space doesn't seem to be that different from wrapping around pytorch and offer yet another Trainer API with some callback shenanigans and claims to invent an AI framework.
ajmurmann 4y ago
Let's use an analogy to maybe get closer to why churn on the front-end tech is so high: A few weeks ago I was reading a discussion on which musical instruments are hardest to play. Someone said that they are all equally hard, because if the instrument is easy to play, people will write more complex music for it. I think the same happens in front-end dev. It happens here because it's obviously exposed to users and we want to a) follow fashions and b) wow our users. As soon as tools get more powerful and we start to master them we'll start to push the boundaries and everything becomes a pain again and several people will write frameworks or tools to make it easier.
etoxin 4y ago
Changing APIs. When the front-end gets JSON from an API. We really don't know what we're getting. We need to liaise with the API team to figure out how these APIs work and when they change, we don't know what changed. Luckily there is a new solution. End to end type safety. Using tools like graphQL allows FED build tools to get the entire API schema and bring that into the typescript build. If the API changes, your build will break allowing you to update your app to the latest API. Maybe we need a new HTTP method "SCHEMA" that allows the app team to get the schema directly from the API and stop sharing postman links around in chats.
- miiiiiike 4y ago
  This comment makes absolutely no sense in the context of the article. Did you read it?
  - deleted 4y ago
    [deleted]
  - etoxin 4y ago
    you're right. I only read the title and very quickly. My bad.
    - miiiiiike 4y ago
      Good on you man. Not many people are big enough/bother to admit to being wrong on the internet.
nathants 4y ago
the last good ideas in js land were react and google’s closure compiler. reagent[1], a react wrapper, has had a stable and tiny api for a decade. easy, fun, and effective sdlc[2] on mature technology is easier now than ever. there are no more excuses. 1. https://reagent-project.github.io/ https://reagent-project.github.io/ 2. https://github.com/nathants/new-gocljs https://github.com/nathants/new-gocljs
apatheticonion 4y ago
I would say the Web is unstable because it's a disruptive platform. Traditionally we build native clients, be it mobile or desktop, that work offline and connect to back end services. The modern web allows for that but in a simple, cost effective and cross platform way. Naturally this attracts developers from all backgrounds to target this platform for their projects. These various influences puts pressure on the platform to morph to their preferences and with the platform still being young; that pressure (and profitability) means it tries to appeal to everyone, creating issues. - Privacy Privacy on the web is a challenge primarily because of government legislation. With the exception of the deprecated third party tracking mechanisms, the issues faced on the browser are no different to those faced by native applications - it's just that the scale of the web is much larger. Any app, desktop application or website can opt to send user data to a third party. Cross-site cookies allow for customer tracking, but they are being phased out. Service worker has recently started being used by advertisers for tracking. Generally though, advertiser networks can always operate in silos and request from their partners that they send customer data in exchange for compensation. As a developer you may inadvertently subject your customers to tracking, for this I would love to see greater script sandboxing capabilities. Right now we have CSP and need to iframe anything we don't want to have access to the parent document - it would be amazing if we could sandbox _scripts_ directly, allowing us to grant no permissions by default and add them. <script src="https://..." sandbox="fetch; dom" /> I would also love to see permanent storage (local storage, indexdb, cookie) require a user prompt for approval, where temporary storage (2 weeks) is allowed by default. - Utility The web platform has had incredible innovation and is going in a controversial direction that I personally love. While simple documents on the web are great, the platform is increasingly somewhere you can go to interact with rich experiences that operate on every platform. Some criticize this as overreach of the traditional web, but in reality - Linux can now use MS Word and Photoshop natively on x86, x86_64, ARM, RISC5. Tools we use daily like APMs (DataDog, NewRelic), Google Maps, Email are all available on all platforms without requiring a native client. This is good because no one is going to make Linux clients for these applications. Electron demonstrates that people want to use HTML/CSS as a UI toolkit (rather than platform native UI kits like QT, GKT, SwitftUI, WinForms, WPF, WinUI, Xamarin, Flutter, etc) and demand greater OS access than installable web applications can offer (like IDEs). Web assembly demonstrates that people want to update this simple UI model using the language they like the best. Expanding the Web Sandbox to offer lower level access to things like the permanent storage, filesystem access and hardware through user prompts would eliminate the need for Electron and allow for optimisations in a single browser to operate across these installable applications. The inclusion of Web Assembly would allow for more processor and memory efficient applications to be written - removing the stigma of "those bloated Electron apps" Perhaps marking your web application as a "wasm" application would allow browsers to trim some JavaScript specific runtime logic allow for smaller memory footprints. - JavaScript, Testability and Performance There's a lot of investment in JavaScript tooling and a lot of impressionable developers out there are implementing software that isn't testable or well architected. A lot of these tools are used in improper contexts or, in some cases, are plainly bad tools. By and large, JavaScript is a great language - or more specifically, a great compile target. A lot of the issues with JavaScript can be resolved by applying a pre-processor like TypeScript to it. The ecosystem is a point of critique. Being as open as it is, it's unopinionated, lacking a standard library or tools and engineers must stitch together their projects. By comparison - Rust, Go, Kotlin, Swift all offer rich test tooling and strong standard libraries. As a language itself, the language features of JavaScript have become an amalgamation of various developer preferences. Being that it's the only language that can be executed in the browser - it is under a lot of pressure to morph into every other language used by web developers. If Web Assembly ends up replacing JavaScript as a compile target, the web would become a significantly nicer place to develop for as you can pick your language ecosystem of preference. Some languages are better suited to testing, have better tooling or dependency management. Some languages have access to better multi threading APIs and some languages have more efficient runtime performance. These would bring the development and user experiences on the web as comparable to native applications in performance. - Rant on WASM That said, WASM has been the biggest tease for me as they have over promised and under delivered. 5 years ago they were talking about it as a replacement for JavaScript as a compile target for languages like TypeScript, Go, Rust. Smaller binaries, faster parsing, better runtime performance and multi-threading support. Here we are today and I still can't make a div from my WASM-compiled C project.
tomcam 4y ago
What did this reference to deliberate suppression? I’m aware of Medium but don’t know what OP is referring to here: > You miss the replies pointing out some critical inadequacies in X.js, because Medium deliberately suppresses them, and move on to finding a _Y_.
5350-uiop-1130 4y ago
I worked on a play <button> today that was 200 lines of HTML. Just the button. Front end sucks ass, sorry for the language. The web browser as a platform just sucks to work with, it always has, just now the issues are more nuanced than just dealing with quirks or ms jscipt weirdness.
qudat 4y ago
I used to think the FE ecosystem was vitriolic and full of potentially unnecessary change. I think there are some really good reasons for that which are described here https://erock.io/2021/03/27/my-love-letter-to-front-end-web-development.html https://erock.io/2021/03/27/my-love-letter-to-front-end-web-... Having started to work more in dev ops lately, I no longer think this problem is unique to FE. The number of tools used in the dev ops scene makes my head spin. There are hundreds of products and services one can employ when building out infrastructure that didn’t exist 5 years ago. Everything being built on top of kubernetes alone will send you into decision fatigue and months of research. I see no meaningful difference. Why’s is that? Do we just feel like the gravity of infra is more deserving of the complexity?
hrbf 4y ago
I feel entirely exhausted by the JavaScript ecosystem. Just for me, it takes all the fun and workmanship out of building something. I tend to spend so much time on tooling that by the time I get to do anything creative, my motivation is nearly gone. I just experience the moment over and over that I just don’t want to deal with any of it. Then I wonder where the fascination and enthusiasm has gone that attracted me to and kept me in this area of technology for over 20 years. Maybe that’s my inner geezer talking or there’s some nostalgic distortion at work but building a website and a small product used to be comparatively easy. Today with the elevated expectations on functionality and the tons of tooling it quickly becomes an almost insurmountable task. Everything appears to be optimized for the large scale, where all the tooling and workflows probably help. There are just so many moving parts, all the time. I’d like to build performant web sites and products with as little JS as possible, make a good living doing it and spend time refining the foundation. But those jobs are gone. It’s all JavaScript and full-stack development positions now.
pif 4y ago
> webdevs being naturally impatient, faddish and incompetent Well, isn't it the case? One more article confusing web programming with the whole software development! Front-end development is unstable only for those applications where the nicest, latest GUI is the only value the developer takes to the table. Learn the business, have your application solve an actual business problem, offer a well-thought and on-spot ergonomic interface, and the users will love the features, and the GUI will not look oldish to them after two years.
mbrodersen 4y ago
It isn’t and never has been. Nobody stops you from using the same tools for years, only upgrading when it is truly worth it. The “instability” of front-end development is a “problem” created by front-end developers themselves. Like most problems in software development I might add.

132 points by ddtaylor 4y ago

I’ve been using react for 8 years. In that time I’ve gone from webpack, to vite. Lately using remix or nextjs. Not that much has had to change in that time, it definitely feels more stable in the past 5 years or so. Every new library is using components, just with their own preferred syntax.

taeric 4y ago
I'll agree it feels a little more stable in the past 5 years or so. I do have a sense that a lot of the UI libraries we used on our project are working fine, but are also deprecated and have a doom's day clock on them. Oddly, this is as much from "in house" widgets as it is 'in the wild" ones. Specifically, I know that if we want to bring in some widgets that were created this year, we have a massive upgrade task ahead of us. :(
ldjkfkdsjnv 4y ago
Yeah I actually think react is the stability. Its still here, still the main choice.

marcosdumay 4y ago

Hum... The Great (Web) Frontend Revamping seems to have passed. Nowadays people are still discussing if React or Vue is better, with a clear intonation of "whatever works for you, I prefer X". Looks like the field is maturing. Either that or we are on a fake calm before we see a lot of articles about people migrating into wasm in "whatever language has support for it right now" (AFAIK, currently wasm goes with rust).

sircastor 4y ago
This doesn’t feel that different to me from ~2010 era jQuery vs Prototype vs …Dojo(?) these things happen in waves. I’ve wondered if the next revolution will be wasm, or another round of JS magic… or something different.
darepublic 4y ago
Don't worry, view layer may be stabilizing but what about Managing backend requests is too complicated!(react-query) You *need* gql don't you? Don't forget forms. Super hard to do right. react-final form, react form hook, etc We need a monorepo framework! Nx, turbo, rush, pnpm (too low level), Lerna (too old and unmaintained) What about bundlers huh? Vite, esbuild, rollup, webpack I still see plenty of opportunity for teams to ignore persistent issues and just diagnose a new framework without analyzing their current woes. Silver bullets for everyone!
- nicoburns 4y ago
  The difference is that's all ignorable. If you want to standard React with classes, redux, npm and webpack like it's 2017 then you absolutely can, and it's still a maintained and supported solution. That's very different to say the evolution from JQuery to Backbone to AngularJS to React where you ended up being on an increasingly unsupported platform if you didn't upgrade.
  - darepublic 4y ago
    It's not really ignorable, these frameworks come ready made with converts seeking to spread the good news to every codebase they find. Understanding, let alone improving, legacy code is a total waste of their awesome powers. It's raze the city and build paradise from scratch. Using shiny new framework (tm).
    - nicoburns 4y ago
      That's what tech leads are for. To be the person with experience and judgement who has the authority to set the rules for the rest of the team on these kind of questions. If you're having problems with this I'd suggest you have more of a hiring problem than a framework problem.
      - darepublic 4y ago
        you might be right on the money with that. I mean it also reflects badly on me in regards sort of jobs I find myself in where this is a recurring problem. But.. I feel like it may be more widespread problem than most people admit.
jansan 4y ago
If you started with Vue two years ago, you had to learn Vue 3 shortly after that. With a new Vuex. Which has been dropped since in favor of Pinia. Oh, Vite has been developed since, so you may want to add this to your stack, because it makes compiling during development so much faster. Also, be aware of all the breaking changes that Webpack 5 has introduced. I hope front end development will be more stable in future, but the last two years where full of pretty major changes.
- suction 4y ago
  The Vue 3 disaster (in my opinion) shook my trust in the framework forever. I immediately knew this is not a framework I will spend any more time in. What if I "upgrade" my apps to 3 and then Vue 4 comes along with yet another fundamentally different concept? This is not acceptable for apps with any kind of long time support requirement. Yes I know, Vue 2 paradigms are still usable in 3 but they feel very deprecated.
  - KaoruAoiShiho 4y ago
    Don't think Vue 2 to Vue 3 is that bad, certainly nothing like AngularJS to Angular. You can still conservatively upgrade piecemeal elements of your stack and most of the code still just works.
  - gherkinnn 4y ago
    Coming from Vue 0.x and 1, Vue 2 felt wrong. It didn’t know what it wanted. Classes and hooks and decorators and options and only some obscure combination offered acceptable TS support. Having only read the docs, Vue redeemed itself with version 3. There’s the options API we know and love from v1 and the new and intuitive composition API. The docs make it easy to decide and not to mix them up. And no useEffect fuckery.
  - runarberg 4y ago
    I inherited a vue2 codebase with a vuex store, and upgrading to vue3 and pinia one component at a time over a course of 3-4 months was quite easy. The upgrade path is really clear and they did a good job making everything compatible so that it could be made gradually over a relatively long time.

Atheros 4y ago

UI/UX is a fundamentally flawed field for a number of intersecting reasons, most of which boil down to not really distinguishing between when it's doing engineering, when it's doing psychology, and when it's doing fashion. And these days, on web apps and mobile apps, it mostly does fashion. Fashion must change for the sake of change. To more easily support these frequent changes, more libraries get invented to make doing new things easier. After that, everything in the article makes sense.

csande17 4y ago
> Fashion must change for the sake of change. To more easily support these frequent changes, more libraries get invented to make doing new things easier. The frontend "ecosystem" libraries discussed in the article are also subject to a fashion hype cycle, independently of UI/UX design trends. A lot of them don't actually make anything easier, or don't make rapid design iteration easier at least.
sjtindell 4y ago
I’m not sure fashion feels like the right term. People just assume newer equals better. So they want to use the latest and “greatest”.
- azemetre 4y ago
  This sounds exactly like fashion to me. One just has to look at how often design has changed over the last decade with the many fads and worst UX. I feel like when you have an org of designers they will justify in wanting to redesign everything because why else do you need them? The same can be said for some POs and devs as well IMO.
  - fny 4y ago
    Yup. The most brutal environments I've ever worked in canned design folk very quickly once a cost crunch arrived. Some startups would even can designers first to save cash.
deleted 4y ago

HidyBush 4y ago

The old saying goes like this: "if you want freedom on one layer you need stability on the layer below" My guess is that since frontend web development is at the top of the stack it has an incredible amount of freedom so everything changes every minute. You don't see too many people wanting to subvert HTTP making a billion homemade alternatives

capableweb 4y ago
> You don't see too many people wanting to subvert HTTP making a billion homemade alternatives No? I constantly come across new protocols, promising improvements compared to it. Some even become relatively popular and are included in browsers by default. Just some examples are WebSockets, WebRTC and QUIC. I expect we'll see more of them in the future as specific use cases requires more specific protocols.
- ezsmi 4y ago
  I think you make a fair point but on the other hand I don’t see many “top 20 alternatives to http in 2022” articles (which implies there are more than 20 alternatives) like we have for front end technologies. I.e. https://www.netguru.com/blog/front-end-technologies https://www.netguru.com/blog/front-end-technologies
  - bobthepanda 4y ago
    I think part of it is also level of effort. You could right click "inspect element" in any browser and mess around in the html or the JS console and see things happening live. This is an extremely low barrier to entry. Low barriers to entry are good, our profession is very well compensated and developed economies could certainly use low effort ways to get people from lower compensated jobs into higher compensated jobs* but that also means that there are a lot of cooks in the kitchen. --- * yes, tech isn't for everyone (what job is?), and when I say low barrier to entry I mean you don't really need to subject yourself to what could easily be 5-10 years of schooling in medicine or law or engineering.

bigmattystyles 4y ago

I think that if you want a page to impress or make a splash then sure, you always have to move to the next greatest thing, however, I don't work for them but I've paid for Telerik Kendo Controls (the react ones specifically)since they were released, before then, the AngularJs ones and it's been great - it keeps my (albeit internal app) UI development stable, fast and looks great with minimal fussing about. It's been years now and it feels very stable and quick. The switch from AngularJs to React was the only unstable part, but it was at an inflection point in the number of apps I had to support and develop, so the change was actually welcome. YMMV (edit - I just realized I spent the weekend experimenting with MAUI, so I'm full of it)

Etheryte 4y ago
I had to read your comment twice to be sure we're talking about the same Kendo. I've consulted for a number of companies over the years who have used it (or tried to use it), ever since the jQuery version to up until now, and it's always been pure pain. I understand how their components work, I understand the underlying architecture because I've stepped through it too many times with a debugger, and I still always fail to understand how they have any happy customers. Perhaps there is a good experience to be had if you only use the components exactly the way the documentation examples use them, but the moment you step outside that narrow path, things fall apart. Never mind custom code, simply using two different components from their library together doesn't even always work. The first time I had a bout with Kendo was some odd ten years ago, and then I was sure it was simply me not understanding the framework. After all, every component library has its own kinks and it takes a while to get up to speed. After seeing them again and again many times over the years, I've changed my opinion. In my eyes, Kendo is what I like to call an MBA trap. It ticks all the boxes that an MBA manager going by a feature checklist is looking for, but under the hood it's garbage software. I'm glad you've had a good experience, at the same time I don't think I will ever stop recommending everyone to stay away from Kendo.
- bigmattystyles 4y ago
  I don't agree with you but I don't disagree either. Our use cases are very vanilla, and now that I have quite a bit of sway in my team, when people deviate from the showcased Kendo way, I push back and see if the desired way deviating from Kendo is a necessity or a nice to have. If it's the former, we sometimes have the experience you described, though I've often be helped by stackoverflow, their forums or Kendo's support team. (We pay for the 24 hour tier). If it's the latter then I force the Kendo way. FWIW, their ODATA v4 support OOTB with dotnetcore webapi with its ODATA v4 out of the box with an EF model is the perfect pattern for most of our use cases. But again, I don't disagree with you either - but I would stress that any alternatives I've seen have their same range of issues.

RcouF1uZ4gsC 4y ago

I think part of the reason is the evolution of common user networking. Initially, users had low bandwidth connections, and web pages were mostly static with links. Then came JavaScript interactivity and AJAX. As users bandwidth grew, we started having heavier frameworks and SPAs. I believe there is another revolution that is happening now because of decreased latency. Recently with protocols such as HTTP2, web sockets, and edge computing, round trip latency is greatly decreased. This is resulting in UI where more of the logic lives on the server and has led to such libraries as htmx (client) and Turbo. It will be interesting to see where this settles out.

crooked-v 4y ago
React is also pushing in the 'edge computing' direction with Suspense and with major libs like Next implementing the idea of "server components".
blueslurpee 4y ago
Agreed, very interesting things going on in the "edge" space. I personally think this is why HN is so jazzed about things like fly.io. Super low latency opens up a whole new category of applications, it's a "step function" change in that regard.

anyonecancode 4y ago

Maybe I'm the odd one out, but I feel like the instability is mostly surface-level and FE is not, actually, so much less stable than other areas? I got into tech via web development, migrating further into the backend over time, and about four years ago became pretty much exclusively backend. Just started a new job and I'm back in the front end. Some things have changed, but not that much. - Typescript was just getting popular when I left, now it's basically a standard, but 1) after having been in javaland for a while, adding typing to JS makes a lot of sense to me and 2) though it's a change, feels like a change toward more stability, not less? - React was the big framework when I left, still is the dominant framework. - There's still a lot of option -- eg vue, etc. nextjs wasn't a thing I knew about that I am starting to learn now. Class syntax felt unecessary to me but seems to be de facto these days. But... these all feel relatively small? I started in FE back in the days of IE 6. jQuery was a godsend when it arrived, underscore was super helpful. I'll grant the shift from "we use JS to add some interaction, form validation, and sometimes interact with Flash" to "we use JS to write actual programs delivered via your browser" was a huge shift, but since we've made that shift it seems most of the "instability" is more around FE devs adopting practices already common in the rest of the stack. I think maybe that's where this sense of instability comes from -- a focus on the wide array of possible _implementations_ -- but I feel the really disruptive shift from "interactive decoration" to "web applications" was the really big one, and that's a while back now. And even with the dizzying array of possible implementations, there's obvious market leaders -- you're not going to go wrong by learning React, any more than you're going to go wrong by learning Spring Boot. Always good to explore and get familiar with other libraries and frameworks, but if one feel overwhelmed by options, there's some clear well trodden paths that aren't changing _that_ fast. One thing I will say is that I do think FE is _harder_ than BE, because the scope is wider. You need to grasp all the aspects of good programming, but _also_ get a decent grounding in design and UX, which are their own disciplines. A backend API doesn't have to think about things like screen readers or color contrast or all the weird ways users will figure out to misunderstand how to interact with your GUI widgets. A UI for humans is inherently harder than a UI for machines. But that's not the same thing as saying that the FE is unstable.

moonchrome 4y ago

Saying React support libraries are at fault here is not fair - React basically reimagined itself over the years and went from OO and class based components to hooks and functions. The fact that you can still do OO isn't really helping it since it adds to the complexity of things you need to learn to grasp the ecosystem. But that's honestly missing the forest for the trees - JavaScript itself went from asynchronous callback pyramid of doom, to promises and callback chaining, to async/await. The community went through multiple half-assed module approaches/specifications. Several FOTM bundlers with extreme complexity and various tradeoffs. Various build systems. Features like hot reloading, transpiling, source mapping, shimming are table stakes for any frontend framework and involve a lot of complexity and tooling - because the entire ecosystem is built on a foundation of shit that is JS and the browsers. So frontend frameworks are the least relevant part here - it's everything that makes them tick that's the problem.

holoduke 4y ago
I don't know one single UI/UX development environment which is elegant and nice. From Android to iOS to Linux to Linux and Windows to browser UI kits. They are all complex and require constant searching for answers. The libraries are very big and require a complex tooling setup. You can never be an expert in all of them. At least not me.
- api 4y ago
  My pet hypothesis for years has been that developers always vastly underestimate the difficulty of doing a UI framework or environment. They think it'll just be a matter of painting widgets and presenting data. As a result they under-build the foundation. The insufficient structure is then released out to the world for everyone else to build upon. Once people realize the soul devouring chthonic difficulty of doing good modern UI, they've already built on a shit foundation and been forced to realize the full system with a heap of ugly hacks and workarounds. Then someone thinks "wow, this is way too complex! All I need is a simple UI." Then history repeats. You can see this with immediate mode clean simple GUI library of the week. They all stagnate after getting all the basics working, and there's a reason for this. A good mature modern UI is at least on par with a high-end game engine like Unity in terms of feature surface area and difficulty. In some ways it's worse because while the breadth and size of the problem domain is similar the problems you encounter in a game engine are probably a lot more fun. UI is a hell of incredibly hairy state management and a really long tail of edge cases.

newbieuser 4y ago

I think we should stop talking about libraries and talk about the crap of browser specs. Libraries are just a tool and evolve over the years. but browsers are getting worse every year

eyelidlessness 4y ago
Asking sincerely because this take is surprising to me: which specs are you referring to? From my perspective—started front end, gradually went full stack, spent several years fully back end, dove back in a couple years ago—quite a lot of the APIs introduced in the period I was fully back end (and since) are excellent and vastly improve both development experience and the ability to deliver a better user experience. I’m not saying your take is wrong necessarily, I just don’t immediately relate to it and I’m curious what specifically you find objectionable.
- spiffytech 4y ago
  > Asking sincerely because this take is surprising to me: which specs are you referring to? I'd like to see the Web Components spec revisited: it has a) no API for passing non-string attributes to other web components, b) no API for declaratively updating your DOM subtree - you either do manual surgical DOM changes, or blow away your (potentially stateful) children and recreate them. Without these, the raw web components API isn't suitable as an alternative to React et al. You've got to build a whole framework around them (like Lit), and at that point you're just using another framework.
  - eyelidlessness 4y ago
    I haven’t worked with web components, and have only had a passing interest generally. But oddly enough I took some time today to dive deeper. It occurred to me that some of the APIs would potentially benefit some work I’m doing in a legacy project. I’m not an expert on the topic, but I have a few thoughts. First, I agree both of these limitations make the spec less directly useful than a framework, and more likely to be APIs targeted by a framework (however formal or bespoke). That said, that’s pretty much the guiding design philosophy behind nearly all DOM APIs, and it doesn’t seem to me that makes anything worse, just incomplete. I suspect that richer APIs would make things worse. People would still use frameworks, but those frameworks would have to use much more opinionated and much less flexible APIs at a higher level of abstraction. All of that said, > no API for passing non-string attributes to other web components This is really a limit of HTML, and not new. But there’s plenty of precedent for raw string attributes to have a more meaningful representation in the DOM state. An area of the spec that seems really well suited to accommodate this is `part`[1]. Like `classList`, it’s a `DOMTokenList`, and has a corresponding CSS selector. It’s a string attribute, but it’s also structured data as a property. I have a long list of things I’m confident will benefit from this. > no API for declaratively updating your DOM subtree - you either do manual surgical DOM changes, or blow away your (potentially stateful) children and recreate them. This really is a footgun, but I’m not sure what the appropriate alternative is. I don’t think any spec could accommodate the fact that people choose different declarative implementations for very different use cases, without essentially defining high level interfaces that expect to be overridden. Even then, those interfaces would almost certainly be ill-suited to some specialization or another. If your goal was purely creation, I’d agree that there should be a declarative API. But for updates? I can’t imagine a design which wouldn't be worse. > Without these, the raw web components API isn't suitable as an alternative to React et al. You've got to build a whole framework around them (like Lit), and at that point you're just using another framework. I don’t think the goal of any of these APIs should be to replace frameworks. At that point you’re just using a framework forever. It’s an enormous credit to the design behind all of these APIs and their overlapping specs that they continue to produce useful lower-level interfaces without overly steering the ship. 1: https://developer.mozilla.org/en-US/docs/Web/API/Element/part https://developer.mozilla.org/en-US/docs/Web/API/Element/par...

shaunxcode 4y ago

Because it is the frontier which by definition is unstable!

DrFell 4y ago

Because it's all social media trends driven by noobs?

jokethrowaway 4y ago

Frontend is the entry level field for all those people who were not developers but wanted a slice of the salary pie. Designers, architect, lawyers. I've seen everything. I know a few React engineers in my company who can make components and be productive - but they don't know JavaScript and they get stuck when something is slightly different from what they're expecting. Similarly I'm mentoring a few engineers who started with react and are trying to learn backend and other languages. Being the field where all the least developer figures start means you'll have tons of people, tons of visibility, tons of cargo culting and tons of crap being built just to make you look cooler. I'm guilty of this as well, I have my frontend framework on GitHub and it's quite useless - even if it's a nice idea. Of course nobody bothers to maintain stuff and everything is trying to make money on their junior devs fanboys.

heseyin 4y ago

lopatin 4y ago

The article starts off with an outdated take on the space: "We all know the meme: by the time you’ve learned one front-end technology, another three have just been released. Also, that one you just learned? It’s deprecated." Maybe it's because the article is 4 years old. I just don't think it's true anymore. Ok there's React and Vue and others, but that's fine. It's basically the same tech, but they have DX/cosmetic differences. It's not like we're still arguing whether or not VDOM is a good thing. That said, the "Imagine being a junior developer" section sounds spot on still. Maybe it's because those articles that use dogmatic arguments to recommend inferior technologies are still on the internet, and they are not going anywhere.

croes 4y ago
I thought VDom is old school since Svelte and such? https://news.ycombinator.com/item?id=19950253 https://news.ycombinator.com/item?id=19950253
- lopatin 4y ago
  I was waiting for someone to mention Svelte :) I think it's is very possible that it's the next evolution of innovation in the space. It might actually be a Backbone -> React style quantum leap in terms of tech and adoption. The thing is, that won't happen for another 10 years, if it does at all. It could very well turn out to be a niche technology for most people, with minimal real-life benefits compared to the drawbacks of moving off the mainstream. Every space has new innovative technologies that risk upsetting the status quo. I'm not saying things are completely boring now. Just that, unlike in the mid 2010s, they are actually stable enough.
  - runarberg 4y ago
    As far as I know most native web components use direct DOM manipulations over a virtual DOM. So I think the jury is pretty much out on VDOM and we are witnessing it transition to a relic of legacy frameworks. As far as other innovations Svelte has brought, Vue with the <script setup> sugar looks quite similar to Svelte, as well as compiling to a render function (just like Svelte). I’m not super familiar with the intrinsics of Vue but the VDOM is starting to feel like a thin MIR of the framework which could be swapped out in a future major release, rather then something essential to it. I honestly think that 10 years is a very conservative prediction.

jansan 4y ago

Front end develoment has never been more fun if you can keep up with the pace. Finally all major browsers have decent standard support (no Internet Explorer anymore), so crutches like jQuery are not needed anymore. Developers constantly find new ways to implement front end apps, and they are not afraid to break backwards compatibility. This may be bad if you have an old monolith to maintain, but overall it's a good thing IMO. Also, this is not limited to libraries. Have you looked at what speed Chrome devs are implementing new APIs? It's insane. And great.

jraph 4y ago
> Have you looked at what speed Chrome devs are implementing new APIs? It's insane. And great. It's not great. It is bad, really. It means no one that hasn't dozen millions of dollars can implement or even just maintain a viable browser that can keep up. And since we expect browsers to be free, that means… "complicated" business models cough mostly¹ relying on ads and tracking cough to maintain the Web. I which it wasn't this way really. There was a time when it was possible for a few people to implement a quite good browser engine in their free time. KHTML. So good, in fact, that it was chosen as the basis of WebKit (and therefore Blink). This does not seem possible anymore. 1. There's Apple maintaining a browser engine without relying on ads, but their business model is also questionable.

daenz 4y ago

Fads are tempered by a community of people anchored in a deep understanding of the technology. As talented as many FE engineers are, I can count on one hand the number that I've met that have a deep understanding of things like await/async + Futures, closures, DOM trees, etc. These things are (perhaps unfortunately) required to do FE work, yet the engineers using them don't fully understand them, so they don't know how to discern if helper libraries are actually helpful. Additionally, I'd argue FE draws more junior people in general, because of the theoretical rapid feedback loop, and the fact that you can "make something that looks cool" with relatively little effort (relative to a BE engineer). These junior people add confusion to the chaos of the community because they don't know what they don't know, so they're cocksure about their opinions. And as long as they've "made something that looks cool", even if the architecture behind it is hot garbage, it buys them cred in the community. Somewhat related, I've been using Flutter for a recent FE project and I'm in love with it. It's more for webs/mobile applications than websites, but the ergonomics of it feel like a coherent vision. The people maintaining it (Googlers) are excellent, and the Dart library community seems to know what they're doing. Furthermore, the FE design choices are based on Material Design[0], which is backed by (some informal) research by UI and UX professionals, so you don't have to sweat usability quite as much as you would starting from scratch. 0. https://material.io/components?platform=flutter https://material.io/components?platform=flutter

randomtwiddler 4y ago
It's interesting how you can look down on front end for being new and naive while suggesting that Google is a fine reliable tech stack provider. I'm the opposite of everything about this post. A very experienced dev (>20 years professional experience) that has moved primarily to the front end recently in my career (gradually over 4 years). I won't touch flutter simply because the sole vendor and essential dependency is Google. Fads are present in every corner of development. As is "not invented here" or the general draw to green field.
- daenz 4y ago
  If you're looking for a response, you're not really giving me much to respond to. Why do you think Google doesn't provide a "reliable tech stack" ? In any case, I wasn't suggesting that specifically (though I tend to agree with it), only that they have a coherent ergonomic vision by competent engineers.

blenderdt 4y ago

It also has to do with the low entry level. The same happened to PHP. Inexperienced programmers can easily create nice things that look great on the outside. Libs like React and Vue are stable enough but when you throw in a lot of other dependencies it is always the question how experienced the creators were. And when unstable libs become popular bugs and security issues are exposed, pull requests are created and before you know it a next version is launched that is not backwards compatible.

danenania 4y ago

A lot of it is that UI programming is just difficult and inherently complex. Expectations of users are very high and always shifting. Browsers/consumer OSes are constantly moving targets. Mistakes and bugs, even small ones, stand out in a glaring way, so there’s low forgiveness. There are more code paths and they’re harder to test. All that means that unless you want to miss your deadline by a year or leave a bad impression on users, you will need a lot of libraries! Backend/systems specialists always underestimate how hard UI programming is. Then they try their hand at frontend and quickly run into a wall. They find they either need to build something clunky that users aren’t impressed by or else spend a lot of time learning new tools and paradigms (and yes, installing lots of dependencies /shiver). This is a blow to the ego, so it’s better to criticize the language, the culture, the “churn”... anything to avoid admitting the pixel pushers are solving seriously tough problems too :)

deleted 4y ago
[deleted]
daenz 4y ago
>anything to avoid admitting the pixel pushers are solving seriously tough problems too :) That's not how I view it, as a SRE/BE-SWE who has done substantial visual/FE work. From my perspective, the majority of problems in FE are due to extremely poor libraries and standards, bolstered by a community where copying and pasting large chunks of unknown code is acceptable. Yes, there are "seriously tough problems" with trying to develop in that world, but they are of a different world than most BE problems, from my experience. So they feel comparably difficult, but for very different reasons.

dang 4y ago

Discussed at the time: Why Is Front-End Development So Unstable? - https://news.ycombinator.com/item?id=17190992 https://news.ycombinator.com/item?id=17190992 - May 2018 (354 comments) Why Is Front-End Development So Unstable? A Perspective - https://news.ycombinator.com/item?id=17182748 https://news.ycombinator.com/item?id=17182748 - May 2018 (5 comments)

zero_shift 4y ago

I'm the author of this piece. I no longer think front-end suffers the instability people accuse it of. I think there are a lot of _vendors_ trying to usher in a revolution around their particular products - there's a lot of VC funding in JavaScript tooling nowadays - but that's a different problem.

dgb23 4y ago
Some of the vendor backed libraries are among the best. But generally I would agree that marketing, especially certain types, generates a ton of noise, like you beautifully illustrated in your article. I think navigating the web with a BS filter on is an important skill to have.
pljung 4y ago
I enjoyed reading your article, thanks for writing it. I think your recommendation to new devs to focus on Next.js in 2018 (!) was prescient. > I no longer think front-end suffers the instability people accuse it of. Do you mind elaborating why you believe this is the case?
- dylan604 4y ago
  >to focus on Next.js in 2018 (!) was prescient. now that it is 2022, what's the new flavor that would be prescient? I don't ask to actually know, but to reiterate the problem of nothing being solid in this world.
  - vosper 4y ago
    NextJS is still looking pretty good if you're in React land. There's new competition, like Remix, Astro, etc... but I don't see any of them putting NextJS to bed. I'm starting a new application, and I'm still choosing NextJS. (Now what you couple with NextJS for data access is an interesting question - this is where there's a lot of innovation. Personally, I'm going with tRPC. I would look at Edge DB, but in this application I'll need a recursive CTE and Edge can't do it.) Edit: I do think Astro might replace NextJS for purely-static sites, or ones where the "islands of interactivity" pattern is compelling.

pojzon 4y ago

Frontend is unstable because it attracts ppl whose attention span is often lower than the one of a goldfish. Every JS frontend dev I met was speedrunning trying to prove himself by "inventing something new" which in fact was already a state of art. The amount of rehashing and reinventing the wheel with new catchy names in the field is staggering. TBH, if the field wants to improve -> its time to ditch JavaScript and force Browsers to move to something that makes more sense.

lopatin 4y ago
Thank you! Part of the reason that I love these front-end threads is because inevitably somebody will make a fool of themselves by spouting anti-js-dev "backend master-race" nonsense, and this certainly did not let me down.
- pojzon 4y ago
  It would be true if I was working in backend development. I dont. JS is just not good enough for what we want it to do. Someone sooner or later has to make a decision to move further.
  - doomroot 4y ago
    No. JS is here to stay, better get used to it.
  - rschachte 4y ago
    What is JS not good enough for w.r.t front-end dev in your eyes?
- dang 4y ago
  Please don't post in the flamewar style to HN. It's not what this site is for, and it destroys what it is for. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - lopatin 4y ago

spion 4y ago

Lack of standardization is the primary reason we have this problem in the JS ecosystem. "Productive" ecosystems (e.g. Rails, Elixir) usually have one central framework that provides the standard basics. Libraries, tools and other extensions are built on top of the framework to enhance the feature set. Everything typically works well together. JavaScript has multiple frameworks to implement components, multiple tools to implement bundling, multiple tools to implement modular/extensible stylesheets, multiple package managers with somewhat different features (e.g. when it comes to monorepo support), and multiple libraries to implement basic standard functions. Many of these are not compatible with each other. Compatibility is a combinatorial explosion problem that cannot be solved without standardization. Without it, you need to have m*n modules to have m things talk to n other things. Extensions to the ecosystem therefore typically have partial compatibility with all the tools, which further widens the breadth of the problem. There's been very little effort in the community to standardize interfaces and protocols: but for the few things where it has been successful (e.g. see package.json) we've seen much nicer and smoother interop/tool interchangeability. We need more of this, especially when it comes to open-ended "plugin" style stuff (e.g. bundler plugins/extensions, component interfaces, monorepo structures)

sbf501 4y ago

Here's an unpopular opinion: it is unstable because we don't know what exactly "front-end" means. First it was static HTML pages, then it was CGI (ColdFusion & DHTML FTW!), then it was PHP, then it was Rails, then it was Node, then it was React, Angular, Vue... Those aren't random progressions. On the contrary, they are front-end devs responding to needs of the UX moreso than the UI. There have been major efforts to make reactivity match what the user is trying to do, but we're still in unstable-land because we're building the bridge while we cross (I hate that analogy but it is true). Just my $0.01.

truthwhisperer 4y ago
kbrannigan 4y ago
Funny I started to rediscover PHP. It is so pleasant. Just by reading the documentation of Symfony, Yii I have learned a lot about web development.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

karmasimida 4y ago

I think it is getting stable recently. It is a choice of React/Vue/Angular for the most. Be hold there are some choices to make here and there, but if you go with a vanilla setting with popular choices (like Webpack for build), things won't go wrong. Not everything needs to be shiny and edgy. From that angle, the frontend space doesn't seem to be that different from wrapping around pytorch and offer yet another Trainer API with some callback shenanigans and claims to invent an AI framework.

ajmurmann 4y ago

Let's use an analogy to maybe get closer to why churn on the front-end tech is so high: A few weeks ago I was reading a discussion on which musical instruments are hardest to play. Someone said that they are all equally hard, because if the instrument is easy to play, people will write more complex music for it. I think the same happens in front-end dev. It happens here because it's obviously exposed to users and we want to a) follow fashions and b) wow our users. As soon as tools get more powerful and we start to master them we'll start to push the boundaries and everything becomes a pain again and several people will write frameworks or tools to make it easier.

etoxin 4y ago

Changing APIs. When the front-end gets JSON from an API. We really don't know what we're getting. We need to liaise with the API team to figure out how these APIs work and when they change, we don't know what changed. Luckily there is a new solution. End to end type safety. Using tools like graphQL allows FED build tools to get the entire API schema and bring that into the typescript build. If the API changes, your build will break allowing you to update your app to the latest API. Maybe we need a new HTTP method "SCHEMA" that allows the app team to get the schema directly from the API and stop sharing postman links around in chats.

miiiiiike 4y ago
This comment makes absolutely no sense in the context of the article. Did you read it?
- deleted 4y ago
  [deleted]
- etoxin 4y ago
  you're right. I only read the title and very quickly. My bad.
  - miiiiiike 4y ago
    Good on you man. Not many people are big enough/bother to admit to being wrong on the internet.

nathants 4y ago

the last good ideas in js land were react and google’s closure compiler. reagent[1], a react wrapper, has had a stable and tiny api for a decade. easy, fun, and effective sdlc[2] on mature technology is easier now than ever. there are no more excuses. 1. https://reagent-project.github.io/ https://reagent-project.github.io/ 2. https://github.com/nathants/new-gocljs https://github.com/nathants/new-gocljs

apatheticonion 4y ago

I would say the Web is unstable because it's a disruptive platform. Traditionally we build native clients, be it mobile or desktop, that work offline and connect to back end services. The modern web allows for that but in a simple, cost effective and cross platform way. Naturally this attracts developers from all backgrounds to target this platform for their projects. These various influences puts pressure on the platform to morph to their preferences and with the platform still being young; that pressure (and profitability) means it tries to appeal to everyone, creating issues. - Privacy Privacy on the web is a challenge primarily because of government legislation. With the exception of the deprecated third party tracking mechanisms, the issues faced on the browser are no different to those faced by native applications - it's just that the scale of the web is much larger. Any app, desktop application or website can opt to send user data to a third party. Cross-site cookies allow for customer tracking, but they are being phased out. Service worker has recently started being used by advertisers for tracking. Generally though, advertiser networks can always operate in silos and request from their partners that they send customer data in exchange for compensation. As a developer you may inadvertently subject your customers to tracking, for this I would love to see greater script sandboxing capabilities. Right now we have CSP and need to iframe anything we don't want to have access to the parent document - it would be amazing if we could sandbox _scripts_ directly, allowing us to grant no permissions by default and add them. <script src="https://..." sandbox="fetch; dom" /> I would also love to see permanent storage (local storage, indexdb, cookie) require a user prompt for approval, where temporary storage (2 weeks) is allowed by default. - Utility The web platform has had incredible innovation and is going in a controversial direction that I personally love. While simple documents on the web are great, the platform is increasingly somewhere you can go to interact with rich experiences that operate on every platform. Some criticize this as overreach of the traditional web, but in reality - Linux can now use MS Word and Photoshop natively on x86, x86_64, ARM, RISC5. Tools we use daily like APMs (DataDog, NewRelic), Google Maps, Email are all available on all platforms without requiring a native client. This is good because no one is going to make Linux clients for these applications. Electron demonstrates that people want to use HTML/CSS as a UI toolkit (rather than platform native UI kits like QT, GKT, SwitftUI, WinForms, WPF, WinUI, Xamarin, Flutter, etc) and demand greater OS access than installable web applications can offer (like IDEs). Web assembly demonstrates that people want to update this simple UI model using the language they like the best. Expanding the Web Sandbox to offer lower level access to things like the permanent storage, filesystem access and hardware through user prompts would eliminate the need for Electron and allow for optimisations in a single browser to operate across these installable applications. The inclusion of Web Assembly would allow for more processor and memory efficient applications to be written - removing the stigma of "those bloated Electron apps" Perhaps marking your web application as a "wasm" application would allow browsers to trim some JavaScript specific runtime logic allow for smaller memory footprints. - JavaScript, Testability and Performance There's a lot of investment in JavaScript tooling and a lot of impressionable developers out there are implementing software that isn't testable or well architected. A lot of these tools are used in improper contexts or, in some cases, are plainly bad tools. By and large, JavaScript is a great language - or more specifically, a great compile target. A lot of the issues with JavaScript can be resolved by applying a pre-processor like TypeScript to it. The ecosystem is a point of critique. Being as open as it is, it's unopinionated, lacking a standard library or tools and engineers must stitch together their projects. By comparison - Rust, Go, Kotlin, Swift all offer rich test tooling and strong standard libraries. As a language itself, the language features of JavaScript have become an amalgamation of various developer preferences. Being that it's the only language that can be executed in the browser - it is under a lot of pressure to morph into every other language used by web developers. If Web Assembly ends up replacing JavaScript as a compile target, the web would become a significantly nicer place to develop for as you can pick your language ecosystem of preference. Some languages are better suited to testing, have better tooling or dependency management. Some languages have access to better multi threading APIs and some languages have more efficient runtime performance. These would bring the development and user experiences on the web as comparable to native applications in performance. - Rant on WASM That said, WASM has been the biggest tease for me as they have over promised and under delivered. 5 years ago they were talking about it as a replacement for JavaScript as a compile target for languages like TypeScript, Go, Rust. Smaller binaries, faster parsing, better runtime performance and multi-threading support. Here we are today and I still can't make a div from my WASM-compiled C project.

tomcam 4y ago

What did this reference to deliberate suppression? I’m aware of Medium but don’t know what OP is referring to here: > You miss the replies pointing out some critical inadequacies in X.js, because Medium deliberately suppresses them, and move on to finding a _Y_.

5350-uiop-1130 4y ago

I worked on a play <button> today that was 200 lines of HTML. Just the button. Front end sucks ass, sorry for the language. The web browser as a platform just sucks to work with, it always has, just now the issues are more nuanced than just dealing with quirks or ms jscipt weirdness.

qudat 4y ago

I used to think the FE ecosystem was vitriolic and full of potentially unnecessary change. I think there are some really good reasons for that which are described here https://erock.io/2021/03/27/my-love-letter-to-front-end-web-development.html https://erock.io/2021/03/27/my-love-letter-to-front-end-web-... Having started to work more in dev ops lately, I no longer think this problem is unique to FE. The number of tools used in the dev ops scene makes my head spin. There are hundreds of products and services one can employ when building out infrastructure that didn’t exist 5 years ago. Everything being built on top of kubernetes alone will send you into decision fatigue and months of research. I see no meaningful difference. Why’s is that? Do we just feel like the gravity of infra is more deserving of the complexity?

hrbf 4y ago

I feel entirely exhausted by the JavaScript ecosystem. Just for me, it takes all the fun and workmanship out of building something. I tend to spend so much time on tooling that by the time I get to do anything creative, my motivation is nearly gone. I just experience the moment over and over that I just don’t want to deal with any of it. Then I wonder where the fascination and enthusiasm has gone that attracted me to and kept me in this area of technology for over 20 years. Maybe that’s my inner geezer talking or there’s some nostalgic distortion at work but building a website and a small product used to be comparatively easy. Today with the elevated expectations on functionality and the tons of tooling it quickly becomes an almost insurmountable task. Everything appears to be optimized for the large scale, where all the tooling and workflows probably help. There are just so many moving parts, all the time. I’d like to build performant web sites and products with as little JS as possible, make a good living doing it and spend time refining the foundation. But those jobs are gone. It’s all JavaScript and full-stack development positions now.

pif 4y ago

> webdevs being naturally impatient, faddish and incompetent Well, isn't it the case? One more article confusing web programming with the whole software development! Front-end development is unstable only for those applications where the nicest, latest GUI is the only value the developer takes to the table. Learn the business, have your application solve an actual business problem, offer a well-thought and on-spot ergonomic interface, and the users will love the features, and the GUI will not look oldish to them after two years.

mbrodersen 4y ago

It isn’t and never has been. Nobody stops you from using the same tools for years, only upgrading when it is truly worth it. The “instability” of front-end development is a “problem” created by front-end developers themselves. Like most problems in software development I might add.