7 ms·

I've been using the same React stack as an employed frontend developer since 2016. Recently, I started using Tailwind CSS and Next.js in my own stuff, because I

I've been using the same React stack as an employed frontend developer since 2016. Recently, I started using Tailwind CSS and Next.js in my own stuff, because I felt like it, not because anything was being deprecated. This kind of reminds me of this tweet: Backend devs: lol frontend devs love toolchain churn, how do you get anything done Also Backend devs: Docker Vagrant Packer Kubernetes Linkerd Istio CloudFoundry gVisor kNative Firecracker Chaos Prometheus Ansible Juju Chef SaltStack Puppet CloudFormation Terraform Consul Vault Source: https://twitter.com/swyx/status/1234181016367063040 https://twitter.com/swyx/status/1234181016367063040

jpgvm 4y ago
Eh. I think that is pretty weak. 99.99% of that list is infra stuff, not directly related to backend developmnent. Assuming your infra already worked for you and you were wring Java + Spring at most you might have migrated to Kotlin + Spring Boot. If your infra wasn't working for you already you might be using k8s + jib, the end. So churn has a lot to do with eco-system you are in and it's individual tolerance for churn. JVM, especially Java has very minimal tolerance and won't move unless something is very clearly objectively better in some way or the existing solution is being deprecated. Infra has seen a larger push than usual this time with the containers/k8s/service-mesh push but it's not that unusual for infra to see large upheavals every now and then.
- k__ 4y ago
  In the last years backend basically merged with infra, so it's a reasonable concern.
  - kodah 4y ago
    That's not really true. I'm a SWE and Systems Engineer - it's really, really rare to find anyone that knows anything deep about both. DevOps/SRE may be on the same or adjacent teams as SWEs but they're still operating in loosely coupled domains of their own work and tooling - despite what it may appear from the outside. The exception on either side may be at the Staff+ level, where engineers have grown deeper end to end knowledge that slips into other domains. That said, Staff+ isn't a significant portion of the industry.
    - ungamedplayer 4y ago
      I agree with this statement, there is clear delineation between back-end and infra. I imagine because there been significant time to stabalise expections and behavior that the front-end guys haven't had time to develop.
    - k__ 4y ago
      Interesting. A few days ago I read how DevOps failed because people didn't understand it meant devs should do their own ops, instead they rebranded their ops roles to DevOps and called it a day. Here we are, talking about just that happening. Anyway, lately I was working with SaaS and serverless systems and had the impression that there wasn't much difference anymore between infra and code. Configuring and deploying an auth service, or a isn't much different from writing code for FaaS and deploying it.
      - kodah 4y ago
        It depends on the scale you're operating at, not to be cliche. A small service with simple scaling constraints and that's designed intentionally to scale horizontally or vertically can make use of a lot of our the box systems that a single developer or even team of software engineers could wrangle. If the service needs better security guarantees, scaling triggered by advanced/atypical metrics, or cutting edge performance and tuning then you still need specialized people to realize those systems and maintain them. That's not to underscore how quickly a distributed system starts to get "chatty" and quickly falls into this space. Really all DevOps fundamentally meant was spreading APIs to all kinds of things in infrastructure that previously did not have APIs. Someone, unfortunately, took the leap that it also meant SWEs could do this now - ignoring huge domains of knowledge about distributed systems scaling, security, and performance that rest within the domain of systems people. In effect, it just meant more systems people need to be coding and doing systems thinking.
- jitl 4y ago
  So, we can wave our arms in similar fashion at front end space. This is variant of “no true Scotsman” fallacy. Example: Waves arms all this churn is in the frontend infra space. Assuming your infra already worked for you maybe you’ve gone from JavaScript/React five years ago to writing Typescript/React today. JavaScript infra has seen larger than usual push around contain^H^H^H^H^H err around “bundling”, but it’s normal to see large upheavals every now and then
  - jpgvm 4y ago
    The argument is a ton weaker in the frontend space. Even if you got into React early and stayed there there has been numerous upheavals in "the correct way to do react" from class style to functional style and a ton of different ways to do state (redux and friends) etc, hooks, bleh. It's insanely dishonest to try palm off bundling as infra, it has absolutely nothing to do with infra just like Java build systems have essentially zero to do with infra. All of the churn in Webpack/esbuild/vite/whatever is entirely on the frontend space and they have no one to blame but themselves for the mess they have created. The proper solutions have been known for a long time but for various political reasons they have remained untenable to implement. Namely NaCL, WASM and friends. Everyone knows JS is a poor language but it's the only available web runtime (hence why we have so much transpilation) but because of the fractured web engine ecosystem and no standards body with backbone it can't be reasonably fixed right now. Failing that the least the JS community could do would be find a way to work reasonably with real build systems like Bazel, Pants, Buck etc instead of continually trying to poorly implement build systems themselves that just plain suck (looking at you nx).
    - jitl 4y ago
      All these things are a matter of perspective. Look close enough and you will find new ideas (“churn”) happening in every area of programming. What is the difference between Nx vs Nix, Gradle vs Bazel, gRPC vs Twirp, MessagePack vs CBOR, C++ vs Rust, dep vs go mod, ARM vs RISC V? Why is it that Webpack vs Vite is worthy of such frustration compared to any of the above?
    - TechBro8615 4y ago
- cdelsolar 4y ago
  99.99%? Did he list at least 10000 items lol
- eurasiantiger 4y ago
  Someone needs to set up the infra. Do you, as a backender, let the frontend guys handle it?
maxk42 4y ago
I'd say most of those are infrastructure rather than back end
- ggregoire 4y ago
  Then what about enumerating backend libraries to build HTTP API? Just for Python I can probably find 10 of them if not more.
  - maxk42 4y ago
    Yes but the premise is about tooling changing. Most commercial backend tools in Python are still using Django or Flask. That doesn't mean no new libraries will ever emerge. It's just that the pace of change is slower.
    - deleted 4y ago
      [deleted]
    - ggregoire 4y ago
      We use Falcon and FastAPI at my shop, both are very common and popular alternatives to the ones you listed. FastAPI is from 2018, it's more recent than any popular JavaScript framework (angular 2010, react 2013, vue 2014, svelte 2016).
koboll 4y ago
Yeah React in particular really feels like a settled frontend standard now. If anything, JavaScript seems to be changing more slowly than it did during the turbulent Angular/React/Vue days.
- cdelsolar 4y ago
  Svelte
- ipaddr 4y ago
  React is the corporate standard displaying angular but Vue is more popular than ever, Angular is smaller then peak but strong.
  - bobbylarrybobby 4y ago
    Do you know where Svelte is these days?
    - winrid 4y ago
      Svelte gets a lot of love, but big enterprises will pick React, and sometimes Angular for not having to make as many choices.
irrational 4y ago
All those are devops things. The actual code is written in languages that rarely change. I work on websites whose backend code was written 20 years ago and still works great. The front end has to be rewritten every 5 years or so as things change.
tomc1985 4y ago
For the backend devs, it doesn't have to be this way but the business side of our community absolutely hates overprovisioning and are allergic to deploying power in reserve. It's that foolish "well I'm just leaving money on the table" mindset.
ozzythecat 4y ago
I think this was already said, but most of what you’ve written here is infrastructure tooling. Here’s my personal anecdote - for what it’s worth. I’m writing application and service code in Java and C++, mostly using the same libraries I’ve been using for the past 5-7 years. All of my storage is using Postgres, and for some data crunching use cases, I’ve been using Kinesis, SQS, and SNS, along with two hosts running Spark. Most of it is pretty boring, which I think is a good thing. I was writing web pages in HTML in the late 90s and began using MySQL with PHP for the server by the early 2000s. In the last 20 or so odd years, the front end stack has had endless churn and complexity. I’d like to say C++ is insanity, but it feels tame compared to the expansive web stack… all just to create websites.
- eurasiantiger 4y ago
  ”Just to create websites”
ipaddr 4y ago
My 2015 react code did work in 2017 with node/packages changing so much. My 2017 react code in 2019 didn't run. Things I've written in php in 2004 still work today.
- mikercampbell 4y ago
  Did your php version change? Because I'm pretty sure my php 5 code would not run on the latest version.
  - ipaddr 4y ago
    Much of your php 5 code will run in 7 and 8 and if it's 5.2+ most will run. Your php 4 code would run. Your php 3 code would.
  - acrooks 4y ago
    I built a PHP 5 app back in ~2007 that's still in active use today. My hosting provider emailed me at some point saying that they would force-upgrade the server to PHP 8 for security reasons. It took less than 2 hours of effort to update all of the code to work with the latest version.
tnel77 4y ago
I haven’t seen most of those listed on job postings whereas I’ve seen seemingly dozens of frontend frameworks on various postings.
cjbprime 4y ago
> Docker Vagrant Packer Kubernetes Linkerd Istio CloudFoundry gVisor kNative Firecracker Chaos Prometheus Ansible Juju Chef SaltStack Puppet CloudFormation Terraform Consul Vault Most of these are over ten years old.

jpgvm 4y ago

Eh. I think that is pretty weak. 99.99% of that list is infra stuff, not directly related to backend developmnent. Assuming your infra already worked for you and you were wring Java + Spring at most you might have migrated to Kotlin + Spring Boot. If your infra wasn't working for you already you might be using k8s + jib, the end. So churn has a lot to do with eco-system you are in and it's individual tolerance for churn. JVM, especially Java has very minimal tolerance and won't move unless something is very clearly objectively better in some way or the existing solution is being deprecated. Infra has seen a larger push than usual this time with the containers/k8s/service-mesh push but it's not that unusual for infra to see large upheavals every now and then.

k__ 4y ago
In the last years backend basically merged with infra, so it's a reasonable concern.
- kodah 4y ago
  That's not really true. I'm a SWE and Systems Engineer - it's really, really rare to find anyone that knows anything deep about both. DevOps/SRE may be on the same or adjacent teams as SWEs but they're still operating in loosely coupled domains of their own work and tooling - despite what it may appear from the outside. The exception on either side may be at the Staff+ level, where engineers have grown deeper end to end knowledge that slips into other domains. That said, Staff+ isn't a significant portion of the industry.
  - ungamedplayer 4y ago
    I agree with this statement, there is clear delineation between back-end and infra. I imagine because there been significant time to stabalise expections and behavior that the front-end guys haven't had time to develop.
  - k__ 4y ago
    Interesting. A few days ago I read how DevOps failed because people didn't understand it meant devs should do their own ops, instead they rebranded their ops roles to DevOps and called it a day. Here we are, talking about just that happening. Anyway, lately I was working with SaaS and serverless systems and had the impression that there wasn't much difference anymore between infra and code. Configuring and deploying an auth service, or a isn't much different from writing code for FaaS and deploying it.
    - kodah 4y ago
      It depends on the scale you're operating at, not to be cliche. A small service with simple scaling constraints and that's designed intentionally to scale horizontally or vertically can make use of a lot of our the box systems that a single developer or even team of software engineers could wrangle. If the service needs better security guarantees, scaling triggered by advanced/atypical metrics, or cutting edge performance and tuning then you still need specialized people to realize those systems and maintain them. That's not to underscore how quickly a distributed system starts to get "chatty" and quickly falls into this space. Really all DevOps fundamentally meant was spreading APIs to all kinds of things in infrastructure that previously did not have APIs. Someone, unfortunately, took the leap that it also meant SWEs could do this now - ignoring huge domains of knowledge about distributed systems scaling, security, and performance that rest within the domain of systems people. In effect, it just meant more systems people need to be coding and doing systems thinking.
jitl 4y ago
So, we can wave our arms in similar fashion at front end space. This is variant of “no true Scotsman” fallacy. Example: Waves arms all this churn is in the frontend infra space. Assuming your infra already worked for you maybe you’ve gone from JavaScript/React five years ago to writing Typescript/React today. JavaScript infra has seen larger than usual push around contain^H^H^H^H^H err around “bundling”, but it’s normal to see large upheavals every now and then
- jpgvm 4y ago
  The argument is a ton weaker in the frontend space. Even if you got into React early and stayed there there has been numerous upheavals in "the correct way to do react" from class style to functional style and a ton of different ways to do state (redux and friends) etc, hooks, bleh. It's insanely dishonest to try palm off bundling as infra, it has absolutely nothing to do with infra just like Java build systems have essentially zero to do with infra. All of the churn in Webpack/esbuild/vite/whatever is entirely on the frontend space and they have no one to blame but themselves for the mess they have created. The proper solutions have been known for a long time but for various political reasons they have remained untenable to implement. Namely NaCL, WASM and friends. Everyone knows JS is a poor language but it's the only available web runtime (hence why we have so much transpilation) but because of the fractured web engine ecosystem and no standards body with backbone it can't be reasonably fixed right now. Failing that the least the JS community could do would be find a way to work reasonably with real build systems like Bazel, Pants, Buck etc instead of continually trying to poorly implement build systems themselves that just plain suck (looking at you nx).
  - jitl 4y ago
    All these things are a matter of perspective. Look close enough and you will find new ideas (“churn”) happening in every area of programming. What is the difference between Nx vs Nix, Gradle vs Bazel, gRPC vs Twirp, MessagePack vs CBOR, C++ vs Rust, dep vs go mod, ARM vs RISC V? Why is it that Webpack vs Vite is worthy of such frustration compared to any of the above?
  - TechBro8615 4y ago
cdelsolar 4y ago
99.99%? Did he list at least 10000 items lol
eurasiantiger 4y ago
Someone needs to set up the infra. Do you, as a backender, let the frontend guys handle it?

maxk42 4y ago

I'd say most of those are infrastructure rather than back end

ggregoire 4y ago
Then what about enumerating backend libraries to build HTTP API? Just for Python I can probably find 10 of them if not more.
- maxk42 4y ago
  Yes but the premise is about tooling changing. Most commercial backend tools in Python are still using Django or Flask. That doesn't mean no new libraries will ever emerge. It's just that the pace of change is slower.
  - deleted 4y ago
    [deleted]
  - ggregoire 4y ago
    We use Falcon and FastAPI at my shop, both are very common and popular alternatives to the ones you listed. FastAPI is from 2018, it's more recent than any popular JavaScript framework (angular 2010, react 2013, vue 2014, svelte 2016).

koboll 4y ago

Yeah React in particular really feels like a settled frontend standard now. If anything, JavaScript seems to be changing more slowly than it did during the turbulent Angular/React/Vue days.

cdelsolar 4y ago
Svelte
ipaddr 4y ago
React is the corporate standard displaying angular but Vue is more popular than ever, Angular is smaller then peak but strong.
- bobbylarrybobby 4y ago
  Do you know where Svelte is these days?
  - winrid 4y ago
    Svelte gets a lot of love, but big enterprises will pick React, and sometimes Angular for not having to make as many choices.

irrational 4y ago

All those are devops things. The actual code is written in languages that rarely change. I work on websites whose backend code was written 20 years ago and still works great. The front end has to be rewritten every 5 years or so as things change.

tomc1985 4y ago

For the backend devs, it doesn't have to be this way but the business side of our community absolutely hates overprovisioning and are allergic to deploying power in reserve. It's that foolish "well I'm just leaving money on the table" mindset.

ozzythecat 4y ago

I think this was already said, but most of what you’ve written here is infrastructure tooling. Here’s my personal anecdote - for what it’s worth. I’m writing application and service code in Java and C++, mostly using the same libraries I’ve been using for the past 5-7 years. All of my storage is using Postgres, and for some data crunching use cases, I’ve been using Kinesis, SQS, and SNS, along with two hosts running Spark. Most of it is pretty boring, which I think is a good thing. I was writing web pages in HTML in the late 90s and began using MySQL with PHP for the server by the early 2000s. In the last 20 or so odd years, the front end stack has had endless churn and complexity. I’d like to say C++ is insanity, but it feels tame compared to the expansive web stack… all just to create websites.

eurasiantiger 4y ago
”Just to create websites”

ipaddr 4y ago

My 2015 react code did work in 2017 with node/packages changing so much. My 2017 react code in 2019 didn't run. Things I've written in php in 2004 still work today.

mikercampbell 4y ago
Did your php version change? Because I'm pretty sure my php 5 code would not run on the latest version.
- ipaddr 4y ago
  Much of your php 5 code will run in 7 and 8 and if it's 5.2+ most will run. Your php 4 code would run. Your php 3 code would.
- acrooks 4y ago
  I built a PHP 5 app back in ~2007 that's still in active use today. My hosting provider emailed me at some point saying that they would force-upgrade the server to PHP 8 for security reasons. It took less than 2 hours of effort to update all of the code to work with the latest version.

tnel77 4y ago

I haven’t seen most of those listed on job postings whereas I’ve seen seemingly dozens of frontend frameworks on various postings.

cjbprime 4y ago

> Docker Vagrant Packer Kubernetes Linkerd Istio CloudFoundry gVisor kNative Firecracker Chaos Prometheus Ansible Juju Chef SaltStack Puppet CloudFormation Terraform Consul Vault Most of these are over ten years old.