7 ms·

The front end community wants to wash its hands of the decade we lost

57 points by caspii 4y ago

secondcoming 4y ago
'toxic positivity' that's a new one
- Beltalowda 4y ago
  Yeah, that's the part that really kills me about JavaScript. I can deal with the language, npm, some curious conventions in the community, every "npm install" telling me I have 100+ security vulnerabilities. It's the whole "THIS IS THE MOST AWESOME THING OF AWESOMENESS SINCE THE INVENTION OF AWESOMENESS!!!!" that kills me, which is really just my snarky way of saying that I found there's generally some serious lack of introspection in the community at large. Something like, say, the Python packaging situation is far from ideal, but people are generally pretty honest about the fact that the situation sucks, and that it has sucked for quite a few years. Python devs tend to get embarrassed when you ask about packaging, or the GIL, and most ecosystems have some pain point(s) like that. I understand that some problems are just hard, that there are obstacles, or that things you build don't always turn out to work as well as you intended when you started out (sometimes what seemed like a good idea at the start turn out not to be so good ideas later on), and that many things are also trade-offs where there is no perfect solution. That's all okay. It's the whole attitude I find hard to deal with.
  - cynicalreason 4y ago
    maybe people enjoy working with it .. I love it, I went from a systems admin/customer support to being a senior react dev, I learned angular, than some javascript, than some programming and then some more and some more.
    - z9znz 4y ago
      Perhaps your love of JS/TS/whatever is based more on the path you took and your starting point than the tech you use. Having been through half a dozen programming languages and most phases of the evolution of web development, I have a very different perspective. The complexity and fragility of modern JS-centric web development would have been unimaginable to us 15 years ago. What started (as far as most people experienced) as Jquery, where you could sprinkle a little JS and make some big UX improvements ballooned into this monster where you need thousands of libraries, package management, bundling/minifying/babeling/etc., and fallback plans (you do have graceful degredation built into your JS frontend, yes?). As the phrase goes, we can't see the forest for the trees. If we did carefully review the path we took from then to now, the promises or beliefs we bought which led us down certain trails, and then considered the outcome... I expect we wouldn't be even close to this situation we find ourselves in now.
      - christophilus 4y ago
        I’ve written quite a few old-school web apps in Rails and ASP.Net. Unless you stuck to really basic stuff, they were much harder for me to reason about than the React codebases I’ve been on. jQuery consists of trying to reason about accidentally over aggressive global event handlers and effects, etc. I prefer the modern mess. It’s still a mess, though.
    - Beltalowda 4y ago
      That's fine, but lots of people also enjoy working with Python. I happen to not particularly like Python all that much, and that's never really caused that much friction (responses tend to be "yeah, that part isn't very good" and/or "right, I see where you're coming from"). Frontend on the other hand... I don't want to paint with too broad of a brush. Some of my best friends are frontend developers! But a community can have a certain "atmosphere" or "vibe" to it. I do a lot of Go programming these days, and I find the "vibe" in Go is one of self-righteous arrogant twattery. Does that mean every Go developer is like that? Of course not. But I found that's the overall "vibe" in the community nonetheless (it's a bit better than it used to be though).
  - moron4hire 4y ago
    Toxic positivity goes a step further. It's not just the gung ho "everything is awesome". There's also pushback against critique. In some communities, you can't say, "this project has aspects that are not good" without getting met with "be quiet, the devs are trying really hard". I'm sorry, but certain things shouldn't involve participation trophies. Building bird houses with your kids in the backyard, yes. Building anything at least as complex as a toolshed for other people, no. At a certain point (i.e. when our work can have consequences for others), we have to take responsibility for our work, and expect responsibility from others.
    - Ensorceled 4y ago
      > It's not just the gung ho "everything is awesome". There's also pushback against critique. And the required "buy in", not only can't you critique, you must ALSO actively assert everything is great or you're not "part of the team". Any team without a few, "I disagree but support the group" engineers on it, is probably in a bad way.
  - Ensorceled 4y ago
    > It's the whole "THIS IS THE MOST AWESOME THING OF AWESOMENESS SINCE THE INVENTION OF AWESOMENESS!!!!" that kills me I joined a project using node, npm and angular. Everybody said things like that; "this is so awesome", "JS is great", "never had so much fun". I tried installing it and needed help at every step, "Oh right! We need to do this in our env because X and Y", "Oh, you missed a step, trust me, it's easier to nuke everything and start again now." I ended up with a 30+ step guide that nobody had documented before. We had a little less than 100 security vulnerabilities. Almost every standup was an exercise in figuring out some strange problem with node or angular, sometimes several. This team was definitely doing things poorly, but the unrelenting toxic positivity mixed with the "Rails and Django and Symfony all suck so bad" was hard to take, especially as we struggled to ship a really basic MVP.
stemuk 4y ago
After reading the entire thread I am still in the dark about what exactly the author wants to see changed. The narrative that frameworks = bad and vanilla js = good falls apart quickly IMHO in medium to large sized projects since the complexity has to be abstracted in some way in order to reach a realistic timeframe for completion.
- cynicalreason 4y ago
  I'm in the same boat, I was expecting some punchline .. it's just moaning without anything concrete
  - rubyfan 4y ago
    I couldn’t even get through it. I sort of hate Twitter threads. Lost are the days of making your point in 140 characters or less.
    - expanseoftrees 4y ago
      Haha I created an account just to agree. There’s no content to this twitter thread. I think he’s anti mainstream? That’s his signal?
    - smt88 4y ago
      I've never seen an interesting point that could be made in 140 characters or less. That limit works for jokes, headlines, and almost nothing else. Single-tweet "wisdom" always turns out to be something so broad/unqualified that it's uninteresting or untrue. VC Twitter is basically a deluge of that kind of faux-profound nonsense.
      - drewcoo 4y ago
        > Single-tweet "wisdom" always turns out to be something so broad/unqualified that it's uninteresting or untrue. True, but Twitter threads are the Burma Shave signs of the tech-gentsia. https://en.wikipedia.org/wiki/Burma-Shave https://en.wikipedia.org/wiki/Burma-Shave https://www.legendsofamerica.com/66-burmashave/2/ https://www.legendsofamerica.com/66-burmashave/2/
christophilus 4y ago
Ah, yes. Everyone’s favorite whipping boy: the front end developers. I don’t think the last decade was a mistake. React (and Preact and similar) are my favorite ways to build out UIs. I prefer it to every other thing I’ve tried— and I’ve tried just about every other thing, including building native UIs for a decade. It’s not perfect. I think we’ll find a better approach eventually, which is why I’m fine with the churn. The churn is part of the search for something better. I hate the poor UX often produced by React— fat, slow, clunky pages with loading spinners and jank. So, I sympathize with the author. I hope something like Quik gets it’s footing. But until there’s a better way to build UIs from this subjective developer’s perspective, I’m sticking with React.
- bayraktar 4y ago
  I hate my spouse's lousy cooking; the slow, clunky way their hips move when they walk; but most of all, their cringe poetry. But until I find someone better or at least less embarrassing to be seen with in public, I'm sticking with 'em. OK, so what about Vue.js? Or is it dead to you already?
  - nl 4y ago
    I think you are missing the point. React/Vue/Angular/Whatever are different flavours of the "framework oriented front end development" thing. Yes there differences in both technices and degree you are forced to use only that framework but the principles are essentially the same.
    - bayraktar 4y ago
      So what other kind of thing do you suggest (and which currently has some traction)?
      - nl 4y ago
        I don't agree with the Twitter thread but the implied alternative is serverside HTML and unclear what is the solution for rapid UX on the client.
synu 4y ago
This seems to refer to some new consensus that everyone now agrees to, but I am not sure what they are referencing. Does anyone know?
- z9znz 4y ago
  The consensus is that "good frontends need to be all done in JS, whether React or Vue or Angular or ...". It's like the blockchain craze that thankfully has passed. A few years ago, any company worth anything had some kind of blockchain project, because "everyone knew" that blockchain was some magic thing that would make your business (and your product) better. Certainly some levels of upper management believed this, and they saw their peers embracing it. It's the same, but older, for JS-heavy frontends. The point is that we should carefully re-evaluate how we got here and if we indeed have reaped rewards great enough to compensate for the immense additional complexity.
madeofpalk 4y ago
What's the missing context for this thread? This person seems upset at something, but it's entirely unclear what they're actually talking about...
- jmuguy 4y ago
  I dunno, he seems to say at first that not naming whatever he is talking about is a bad idea. And then never names what he's talking about.
- throwingrocks 4y ago
  He doesn’t care about making a point to the world at large. He’s subtweeting some group of people and is hoping they read his long thread.
mabbo 4y ago
I feel the author misjudges the people making these decisions because for them in their own situation, the choice of large frameworks isn't the right one. But many smart people are in different situations in which the best decision is to use a framework. If I'm Amazon or Google and each ms of time to page load (p99 and average) is measurably worth a 6+ figure sum of money per year, then yes, cutting out the framework and going very very basic is the right thing to do. If I'm a startup with 3 engineers who need to iterate quickly and don't care about page load time (yet) then I'm going to reach for React.
- berkes 4y ago
  This makes three shaky if not outright wrong presumptions: 1. The only reason to cutting out the framework is speed. There are many reasons to forego a framework. Coupling, maintenance[1], dependencies or simply "keeping it simple" are some of the parameters to take into consideration when choosing for or against a (certain) framework. More practically: I'm writing a simple job search engine[2]. Plain, vanilla JS, some \<template\> tags, and a library to communicate with the search backend. I dont' yet need anything react-redux-saga-event-based yet. This approach is reaching its limit, but I now have the proper information to make a better choice. I did not have that when I started, so I would've certainly picked the wrong framework and painted myself in a corner there. 2. Without a framework we cannot iterate quickly As I point out in my blog[1] article, this is has often (but not always) be proven to be exactly opposite. Obviously depending on context and use-case. But there are many situations in which a framework is holding you back. In which it is actually slowing the project down, rather than speeding it up. Frameworks, famously, allow a rapid start, and therefore are great for PoCs, Demos, prototypes, MVPs or even "run-off-the-mill-agency-produce". But over time (think years, decades) often get in the way, hold the project back. Just think of the wasted eons of all engineers "rewriting project P from scratch"; often because it turns out that the current version/market/tech/use requires things that no longer fit the boundaries the framework imposed. Bouddaries welcomed or disregarded when the framework was chosen a decade (or just years) ago. 3. Smaller teams need a framework See above. But also: what a small team needs is reusable code. Libraries. Not Frameworks per-sé, but libraries. Preferably implemented behind decoupled, isolated layers; away from business-logic. Or, more modern, SAAS, PAAS, IAAS. reusable stuff, preferably implemented behind isolated layers. [1] https://news.ycombinator.com/item?id=33185010 https://news.ycombinator.com/item?id=33185010 [2] https://search.flockingbird.social/ https://search.flockingbird.social/
skrebbel 4y ago
This is just good old cargo cult JS Framework Fatigue but then in a fancy “thought leader” writing style, yes? Am I missing some fundamental new insight?
- z9znz 4y ago
  The point I got from the mini-rant was that we have been going down this path of ever-increasing complexity (and ever-increasing client burdon) with this inherent belief that it would result in something better. Better could be "user experience", or "client behavior control/consistency", or ? something. But have we really done side by side comparisons and gathered real evidence? My instinct is that 80% of websites can be HTML and comfortably meet user needs. Another 15% can sprinkle in a little JS to make some targeted improvements. And finally, maybe 5% really do need full JS frontends. Our problem in general is that we like shiny new things, clever things, and things which we think will make our developer lives better. But it seems we end up overdoing it, approaching each new thing as if it were a silver bullet. The Phoenix Framework (LiveView) crowd, and later the Rails (Hotwire) crowd show that you don't need a complex SPA to get user-positive experiences. I have a strong opinion on which of the two does this better and more simply, but that's a separate discussion.
  - kcartlidge 4y ago
    > The Phoenix Framework (LiveView) crowd, and later the Rails (Hotwire) crowd show that you don't need a complex SPA to get user-positive experiences. As an aside, for those unaware it may be of interest that Hotwire can be used to incrementally enhance any ecosystem's server-rendered HTML experience and not just Rails. From the simplest option of just including the source but changing absolutely no code, which has an instant impact, to making proper use of it. One of the projects I use it on is a C# MVC (server-rendered) app and with virtually no effort you get some of the benefits of ye olde update panels from webforms. It's really quite neat.
    - jaredcwhite 4y ago
      Turbo's actually really great for static sites—you can speed up page transitions and even handle some "reactive" elements using Frames and HTML fragments. Pretty awesome stuff. No Rails required.
llamaLord 4y ago
As a PM, I’m used to being blamed for shit going wrong (it’s part of the JD). But c’mon… the state of modern FE development… that’s my fault too???
- altdataseller 4y ago
  You’re a pm. By default, everything is your fault :)
- berkes 4y ago
  I think blame is a too strong word, but there's some merit in this. PMs should be aware of what they bring in when they allow some dev to (re)write the next project to in [this weeks' framework or tech]. PMs can push towards boring, proven and simple tech. Sure, much less fun for devs, might even push away the "magpie-devs" (the ones always chasing the next shiny thing), but in many projects this is probably the best for the business. Not always, but PMs more than devs, should know that any tech has trade-offs and downsides, what they are and how they will affect the business over years and decades.
- Existenceblinks 4y ago
  There was/is also a level of resisting against evidence too though. Like "I don't care performance I will use what I like". And find reasons to back subjective metrics claims, like hiring pool (catch-22 problem of demand & supply of type of workforce).
cardanome 4y ago
The problem is misaligned incentives. Sure, for my personal projects I am all about KISS but at work, if someone insists we try out this new framework and build a super complicated SPA, why not? People make fun of resume-driven development but besides the money which obviously is the main benefit of having a job, experience is the other big thing that a job can offer. It is in my best interest that we use the most complex solution. I like the challenge. Lets be honest, most fronted jobs could be rationalized away and the products would actually be better. It depends on your exact business but in many areas there is not point in keeping your UI "fresh". I have seen lots of redesigns actually HURT sales. Once you have found a design that works for you target customers, just keep riding the good thing. So yeah, things are insane but as a developer it is neither in my power nor in my interest to change anything.
DanG2Point0 4y ago
CharlieDigital 4y ago
I'm at a startup that builds an e-comm platform. Currently on Next.js; evaluating Astro. We're slowly coming to the realization that none of these platforms are either simpler or faster than what we could do with modern vanilla. Some very basic things like show/hide images and blocks of text based on user selection require an obscene amount of code/complexity in React that in vanilla is just element.style.display = condition ? 'none' : 'block' Bonus is that there's no need to think about component re-render. No need to think about hooks, callbacks, memos, effects, etc. A whole layer of complexity disappears. From a performance perspective, there's no contest. Not only is the resultant JS more performant, having the content actually in HTML at download results in faster renders and time to interactive. Our stats show 90+% of our users are mobile so being fast and light are key parameters. I think the author's point is that while HTML, JS, and CSS have been advancing, a generation of developers have been invested in React rather than learning the fully capable and often better underlying capabilities of modern browser platforms. There are many, many developers who have been trained in React + component frameworks with only a very cursory understanding of the underlying HTML, JS, and CSS. Should any team use component libraries or roll vanilla? It depends on the objectives of each team. Often that tradeoff is time to market and future tech debt versus absolute performance. (I have not worked on a React project that didn't have massive tech debt not because of React itself, but the complexity ramp that arises with additional packages, dependencies, state management, and general lack of deep understanding of React's render model). We still like Astro because it allows us the flexibility to use React (or Vue, or Svelte) in dollops where it makes sense.
- wellanyway 4y ago
  It's been while since I've heard frontend devs even speak about actual frontend. Layouts, fonts, accessibility, that sort of thing.
  - CharlieDigital 4y ago
    When I interview front-end devs, I still focus on core fundamentals and I want to see if they can build simple interactions and layouts in HTML, CSS, and simple JS via jsfiddle. My assumption is that if they can do vanilla well enough, having them do React is easy enough. The reverse is often not the case.
kethinov 4y ago
I thought it was a good thread. For those unaware of the missing context, what he's talking about is how in the 2010s, progressive enhancement — long seen as a webdev best practice — was largely replaced by a JS-first approach by JS frameworks in practice. It does seem like the JS-first bubble is deflating a bit, but I'm not sure it's on its way to fully popping like the Flash bubble did. I do agree it was a lost decade though. More than a decade. I miss when everyone agreed progressive enhancement was the way to go. It's entirely possible to build a SPA without abandoning progressive enhancement, but the frameworks do not encourage those best practices. As such, it's rare to see a web app built with a framework that doesn't create a hard dependency on JavaScript or isn't an accessibility disaster. When I reflect on the last decade of frontend development, the lesson I draw from it is everyone is susceptible to ill-conceived fads, including people who think of themselves as evidence-driven. We're good at convincing ourselves we're objective, especially at times when we're not. What's really depressing is this tendency applies to all the applied sciences. Tons of people who think of themselves as motivated solely by evidence fall for terrible fads in their field all the time, including, terrifyingly, in areas like medical practices. I think we'd all do better to spend less time emotionally attaching to our tools and more time looking at evidence and metrics in a dispassionate way. As Paul Graham once said, keep your identities small. A great book that's vital to grokking this stuff is The Scout Mindset by Julia Galef. She argues we should always just go where the evidence leads. But our monkey brains are bad at this, so it takes a lot of conscious effort or we'll do it poorly. I think JS framework mania is yet more evidence of her thesis.
pupppet 4y ago
Front end development won't change. We'll just keep switching out frameworks for the shiny new one with the hope the next one won't be an overly complex mess of npm packages and microservices that can topple over at any moment.
caspii 4y ago
To add my subjective opinion: I came back to frontend development after a break of 10 years. Back then there was jQuery, CSS and HTML. I found that the complexity of the tooling had increased 20-fold. All these build and task runners that were cool for a year and then a new one came along. Those were the costs, but what was the upside? It seems that you can do maybe 10%-20% "more" than back then. It seems to me that this is a very very steep price to pay.
Existenceblinks 4y ago
Red flags words in web tech/tools to me: - modern - revolutionary - love ("really really like" is ok) - can't go back to / can't live without - is the future - just (describe which is not)

57 points by caspii 4y ago

secondcoming 4y ago

'toxic positivity' that's a new one

Beltalowda 4y ago
Yeah, that's the part that really kills me about JavaScript. I can deal with the language, npm, some curious conventions in the community, every "npm install" telling me I have 100+ security vulnerabilities. It's the whole "THIS IS THE MOST AWESOME THING OF AWESOMENESS SINCE THE INVENTION OF AWESOMENESS!!!!" that kills me, which is really just my snarky way of saying that I found there's generally some serious lack of introspection in the community at large. Something like, say, the Python packaging situation is far from ideal, but people are generally pretty honest about the fact that the situation sucks, and that it has sucked for quite a few years. Python devs tend to get embarrassed when you ask about packaging, or the GIL, and most ecosystems have some pain point(s) like that. I understand that some problems are just hard, that there are obstacles, or that things you build don't always turn out to work as well as you intended when you started out (sometimes what seemed like a good idea at the start turn out not to be so good ideas later on), and that many things are also trade-offs where there is no perfect solution. That's all okay. It's the whole attitude I find hard to deal with.
- cynicalreason 4y ago
  maybe people enjoy working with it .. I love it, I went from a systems admin/customer support to being a senior react dev, I learned angular, than some javascript, than some programming and then some more and some more.
  - z9znz 4y ago
    Perhaps your love of JS/TS/whatever is based more on the path you took and your starting point than the tech you use. Having been through half a dozen programming languages and most phases of the evolution of web development, I have a very different perspective. The complexity and fragility of modern JS-centric web development would have been unimaginable to us 15 years ago. What started (as far as most people experienced) as Jquery, where you could sprinkle a little JS and make some big UX improvements ballooned into this monster where you need thousands of libraries, package management, bundling/minifying/babeling/etc., and fallback plans (you do have graceful degredation built into your JS frontend, yes?). As the phrase goes, we can't see the forest for the trees. If we did carefully review the path we took from then to now, the promises or beliefs we bought which led us down certain trails, and then considered the outcome... I expect we wouldn't be even close to this situation we find ourselves in now.
    - christophilus 4y ago
      I’ve written quite a few old-school web apps in Rails and ASP.Net. Unless you stuck to really basic stuff, they were much harder for me to reason about than the React codebases I’ve been on. jQuery consists of trying to reason about accidentally over aggressive global event handlers and effects, etc. I prefer the modern mess. It’s still a mess, though.
  - Beltalowda 4y ago
    That's fine, but lots of people also enjoy working with Python. I happen to not particularly like Python all that much, and that's never really caused that much friction (responses tend to be "yeah, that part isn't very good" and/or "right, I see where you're coming from"). Frontend on the other hand... I don't want to paint with too broad of a brush. Some of my best friends are frontend developers! But a community can have a certain "atmosphere" or "vibe" to it. I do a lot of Go programming these days, and I find the "vibe" in Go is one of self-righteous arrogant twattery. Does that mean every Go developer is like that? Of course not. But I found that's the overall "vibe" in the community nonetheless (it's a bit better than it used to be though).
- moron4hire 4y ago
  Toxic positivity goes a step further. It's not just the gung ho "everything is awesome". There's also pushback against critique. In some communities, you can't say, "this project has aspects that are not good" without getting met with "be quiet, the devs are trying really hard". I'm sorry, but certain things shouldn't involve participation trophies. Building bird houses with your kids in the backyard, yes. Building anything at least as complex as a toolshed for other people, no. At a certain point (i.e. when our work can have consequences for others), we have to take responsibility for our work, and expect responsibility from others.
  - Ensorceled 4y ago
    > It's not just the gung ho "everything is awesome". There's also pushback against critique. And the required "buy in", not only can't you critique, you must ALSO actively assert everything is great or you're not "part of the team". Any team without a few, "I disagree but support the group" engineers on it, is probably in a bad way.
- Ensorceled 4y ago
  > It's the whole "THIS IS THE MOST AWESOME THING OF AWESOMENESS SINCE THE INVENTION OF AWESOMENESS!!!!" that kills me I joined a project using node, npm and angular. Everybody said things like that; "this is so awesome", "JS is great", "never had so much fun". I tried installing it and needed help at every step, "Oh right! We need to do this in our env because X and Y", "Oh, you missed a step, trust me, it's easier to nuke everything and start again now." I ended up with a 30+ step guide that nobody had documented before. We had a little less than 100 security vulnerabilities. Almost every standup was an exercise in figuring out some strange problem with node or angular, sometimes several. This team was definitely doing things poorly, but the unrelenting toxic positivity mixed with the "Rails and Django and Symfony all suck so bad" was hard to take, especially as we struggled to ship a really basic MVP.

stemuk 4y ago

After reading the entire thread I am still in the dark about what exactly the author wants to see changed. The narrative that frameworks = bad and vanilla js = good falls apart quickly IMHO in medium to large sized projects since the complexity has to be abstracted in some way in order to reach a realistic timeframe for completion.

cynicalreason 4y ago
I'm in the same boat, I was expecting some punchline .. it's just moaning without anything concrete
- rubyfan 4y ago
  I couldn’t even get through it. I sort of hate Twitter threads. Lost are the days of making your point in 140 characters or less.
  - expanseoftrees 4y ago
    Haha I created an account just to agree. There’s no content to this twitter thread. I think he’s anti mainstream? That’s his signal?
  - smt88 4y ago
    I've never seen an interesting point that could be made in 140 characters or less. That limit works for jokes, headlines, and almost nothing else. Single-tweet "wisdom" always turns out to be something so broad/unqualified that it's uninteresting or untrue. VC Twitter is basically a deluge of that kind of faux-profound nonsense.
    - drewcoo 4y ago
      > Single-tweet "wisdom" always turns out to be something so broad/unqualified that it's uninteresting or untrue. True, but Twitter threads are the Burma Shave signs of the tech-gentsia. https://en.wikipedia.org/wiki/Burma-Shave https://en.wikipedia.org/wiki/Burma-Shave https://www.legendsofamerica.com/66-burmashave/2/ https://www.legendsofamerica.com/66-burmashave/2/

christophilus 4y ago

Ah, yes. Everyone’s favorite whipping boy: the front end developers. I don’t think the last decade was a mistake. React (and Preact and similar) are my favorite ways to build out UIs. I prefer it to every other thing I’ve tried— and I’ve tried just about every other thing, including building native UIs for a decade. It’s not perfect. I think we’ll find a better approach eventually, which is why I’m fine with the churn. The churn is part of the search for something better. I hate the poor UX often produced by React— fat, slow, clunky pages with loading spinners and jank. So, I sympathize with the author. I hope something like Quik gets it’s footing. But until there’s a better way to build UIs from this subjective developer’s perspective, I’m sticking with React.

bayraktar 4y ago
I hate my spouse's lousy cooking; the slow, clunky way their hips move when they walk; but most of all, their cringe poetry. But until I find someone better or at least less embarrassing to be seen with in public, I'm sticking with 'em. OK, so what about Vue.js? Or is it dead to you already?
- nl 4y ago
  I think you are missing the point. React/Vue/Angular/Whatever are different flavours of the "framework oriented front end development" thing. Yes there differences in both technices and degree you are forced to use only that framework but the principles are essentially the same.
  - bayraktar 4y ago
    So what other kind of thing do you suggest (and which currently has some traction)?
    - nl 4y ago
      I don't agree with the Twitter thread but the implied alternative is serverside HTML and unclear what is the solution for rapid UX on the client.

synu 4y ago

This seems to refer to some new consensus that everyone now agrees to, but I am not sure what they are referencing. Does anyone know?

z9znz 4y ago
The consensus is that "good frontends need to be all done in JS, whether React or Vue or Angular or ...". It's like the blockchain craze that thankfully has passed. A few years ago, any company worth anything had some kind of blockchain project, because "everyone knew" that blockchain was some magic thing that would make your business (and your product) better. Certainly some levels of upper management believed this, and they saw their peers embracing it. It's the same, but older, for JS-heavy frontends. The point is that we should carefully re-evaluate how we got here and if we indeed have reaped rewards great enough to compensate for the immense additional complexity.

madeofpalk 4y ago

What's the missing context for this thread? This person seems upset at something, but it's entirely unclear what they're actually talking about...

jmuguy 4y ago
I dunno, he seems to say at first that not naming whatever he is talking about is a bad idea. And then never names what he's talking about.
throwingrocks 4y ago
He doesn’t care about making a point to the world at large. He’s subtweeting some group of people and is hoping they read his long thread.

mabbo 4y ago

I feel the author misjudges the people making these decisions because for them in their own situation, the choice of large frameworks isn't the right one. But many smart people are in different situations in which the best decision is to use a framework. If I'm Amazon or Google and each ms of time to page load (p99 and average) is measurably worth a 6+ figure sum of money per year, then yes, cutting out the framework and going very very basic is the right thing to do. If I'm a startup with 3 engineers who need to iterate quickly and don't care about page load time (yet) then I'm going to reach for React.

berkes 4y ago
This makes three shaky if not outright wrong presumptions: 1. The only reason to cutting out the framework is speed. There are many reasons to forego a framework. Coupling, maintenance[1], dependencies or simply "keeping it simple" are some of the parameters to take into consideration when choosing for or against a (certain) framework. More practically: I'm writing a simple job search engine[2]. Plain, vanilla JS, some \<template\> tags, and a library to communicate with the search backend. I dont' yet need anything react-redux-saga-event-based yet. This approach is reaching its limit, but I now have the proper information to make a better choice. I did not have that when I started, so I would've certainly picked the wrong framework and painted myself in a corner there. 2. Without a framework we cannot iterate quickly As I point out in my blog[1] article, this is has often (but not always) be proven to be exactly opposite. Obviously depending on context and use-case. But there are many situations in which a framework is holding you back. In which it is actually slowing the project down, rather than speeding it up. Frameworks, famously, allow a rapid start, and therefore are great for PoCs, Demos, prototypes, MVPs or even "run-off-the-mill-agency-produce". But over time (think years, decades) often get in the way, hold the project back. Just think of the wasted eons of all engineers "rewriting project P from scratch"; often because it turns out that the current version/market/tech/use requires things that no longer fit the boundaries the framework imposed. Bouddaries welcomed or disregarded when the framework was chosen a decade (or just years) ago. 3. Smaller teams need a framework See above. But also: what a small team needs is reusable code. Libraries. Not Frameworks per-sé, but libraries. Preferably implemented behind decoupled, isolated layers; away from business-logic. Or, more modern, SAAS, PAAS, IAAS. reusable stuff, preferably implemented behind isolated layers. [1] https://news.ycombinator.com/item?id=33185010 https://news.ycombinator.com/item?id=33185010 [2] https://search.flockingbird.social/ https://search.flockingbird.social/

skrebbel 4y ago

This is just good old cargo cult JS Framework Fatigue but then in a fancy “thought leader” writing style, yes? Am I missing some fundamental new insight?

z9znz 4y ago
The point I got from the mini-rant was that we have been going down this path of ever-increasing complexity (and ever-increasing client burdon) with this inherent belief that it would result in something better. Better could be "user experience", or "client behavior control/consistency", or ? something. But have we really done side by side comparisons and gathered real evidence? My instinct is that 80% of websites can be HTML and comfortably meet user needs. Another 15% can sprinkle in a little JS to make some targeted improvements. And finally, maybe 5% really do need full JS frontends. Our problem in general is that we like shiny new things, clever things, and things which we think will make our developer lives better. But it seems we end up overdoing it, approaching each new thing as if it were a silver bullet. The Phoenix Framework (LiveView) crowd, and later the Rails (Hotwire) crowd show that you don't need a complex SPA to get user-positive experiences. I have a strong opinion on which of the two does this better and more simply, but that's a separate discussion.
- kcartlidge 4y ago
  > The Phoenix Framework (LiveView) crowd, and later the Rails (Hotwire) crowd show that you don't need a complex SPA to get user-positive experiences. As an aside, for those unaware it may be of interest that Hotwire can be used to incrementally enhance any ecosystem's server-rendered HTML experience and not just Rails. From the simplest option of just including the source but changing absolutely no code, which has an instant impact, to making proper use of it. One of the projects I use it on is a C# MVC (server-rendered) app and with virtually no effort you get some of the benefits of ye olde update panels from webforms. It's really quite neat.
  - jaredcwhite 4y ago
    Turbo's actually really great for static sites—you can speed up page transitions and even handle some "reactive" elements using Frames and HTML fragments. Pretty awesome stuff. No Rails required.

llamaLord 4y ago

As a PM, I’m used to being blamed for shit going wrong (it’s part of the JD). But c’mon… the state of modern FE development… that’s my fault too???

altdataseller 4y ago
You’re a pm. By default, everything is your fault :)
berkes 4y ago
I think blame is a too strong word, but there's some merit in this. PMs should be aware of what they bring in when they allow some dev to (re)write the next project to in [this weeks' framework or tech]. PMs can push towards boring, proven and simple tech. Sure, much less fun for devs, might even push away the "magpie-devs" (the ones always chasing the next shiny thing), but in many projects this is probably the best for the business. Not always, but PMs more than devs, should know that any tech has trade-offs and downsides, what they are and how they will affect the business over years and decades.
Existenceblinks 4y ago
There was/is also a level of resisting against evidence too though. Like "I don't care performance I will use what I like". And find reasons to back subjective metrics claims, like hiring pool (catch-22 problem of demand & supply of type of workforce).

cardanome 4y ago

The problem is misaligned incentives. Sure, for my personal projects I am all about KISS but at work, if someone insists we try out this new framework and build a super complicated SPA, why not? People make fun of resume-driven development but besides the money which obviously is the main benefit of having a job, experience is the other big thing that a job can offer. It is in my best interest that we use the most complex solution. I like the challenge. Lets be honest, most fronted jobs could be rationalized away and the products would actually be better. It depends on your exact business but in many areas there is not point in keeping your UI "fresh". I have seen lots of redesigns actually HURT sales. Once you have found a design that works for you target customers, just keep riding the good thing. So yeah, things are insane but as a developer it is neither in my power nor in my interest to change anything.

DanG2Point0 4y ago

CharlieDigital 4y ago

I'm at a startup that builds an e-comm platform. Currently on Next.js; evaluating Astro. We're slowly coming to the realization that none of these platforms are either simpler or faster than what we could do with modern vanilla. Some very basic things like show/hide images and blocks of text based on user selection require an obscene amount of code/complexity in React that in vanilla is just element.style.display = condition ? 'none' : 'block' Bonus is that there's no need to think about component re-render. No need to think about hooks, callbacks, memos, effects, etc. A whole layer of complexity disappears. From a performance perspective, there's no contest. Not only is the resultant JS more performant, having the content actually in HTML at download results in faster renders and time to interactive. Our stats show 90+% of our users are mobile so being fast and light are key parameters. I think the author's point is that while HTML, JS, and CSS have been advancing, a generation of developers have been invested in React rather than learning the fully capable and often better underlying capabilities of modern browser platforms. There are many, many developers who have been trained in React + component frameworks with only a very cursory understanding of the underlying HTML, JS, and CSS. Should any team use component libraries or roll vanilla? It depends on the objectives of each team. Often that tradeoff is time to market and future tech debt versus absolute performance. (I have not worked on a React project that didn't have massive tech debt not because of React itself, but the complexity ramp that arises with additional packages, dependencies, state management, and general lack of deep understanding of React's render model). We still like Astro because it allows us the flexibility to use React (or Vue, or Svelte) in dollops where it makes sense.

wellanyway 4y ago
It's been while since I've heard frontend devs even speak about actual frontend. Layouts, fonts, accessibility, that sort of thing.
- CharlieDigital 4y ago
  When I interview front-end devs, I still focus on core fundamentals and I want to see if they can build simple interactions and layouts in HTML, CSS, and simple JS via jsfiddle. My assumption is that if they can do vanilla well enough, having them do React is easy enough. The reverse is often not the case.

kethinov 4y ago

I thought it was a good thread. For those unaware of the missing context, what he's talking about is how in the 2010s, progressive enhancement — long seen as a webdev best practice — was largely replaced by a JS-first approach by JS frameworks in practice. It does seem like the JS-first bubble is deflating a bit, but I'm not sure it's on its way to fully popping like the Flash bubble did. I do agree it was a lost decade though. More than a decade. I miss when everyone agreed progressive enhancement was the way to go. It's entirely possible to build a SPA without abandoning progressive enhancement, but the frameworks do not encourage those best practices. As such, it's rare to see a web app built with a framework that doesn't create a hard dependency on JavaScript or isn't an accessibility disaster. When I reflect on the last decade of frontend development, the lesson I draw from it is everyone is susceptible to ill-conceived fads, including people who think of themselves as evidence-driven. We're good at convincing ourselves we're objective, especially at times when we're not. What's really depressing is this tendency applies to all the applied sciences. Tons of people who think of themselves as motivated solely by evidence fall for terrible fads in their field all the time, including, terrifyingly, in areas like medical practices. I think we'd all do better to spend less time emotionally attaching to our tools and more time looking at evidence and metrics in a dispassionate way. As Paul Graham once said, keep your identities small. A great book that's vital to grokking this stuff is The Scout Mindset by Julia Galef. She argues we should always just go where the evidence leads. But our monkey brains are bad at this, so it takes a lot of conscious effort or we'll do it poorly. I think JS framework mania is yet more evidence of her thesis.

pupppet 4y ago

Front end development won't change. We'll just keep switching out frameworks for the shiny new one with the hope the next one won't be an overly complex mess of npm packages and microservices that can topple over at any moment.

caspii 4y ago

To add my subjective opinion: I came back to frontend development after a break of 10 years. Back then there was jQuery, CSS and HTML. I found that the complexity of the tooling had increased 20-fold. All these build and task runners that were cool for a year and then a new one came along. Those were the costs, but what was the upside? It seems that you can do maybe 10%-20% "more" than back then. It seems to me that this is a very very steep price to pay.

Existenceblinks 4y ago

Red flags words in web tech/tools to me: - modern - revolutionary - love ("really really like" is ok) - can't go back to / can't live without - is the future - just (describe which is not)