7 ms·

Cliche rant coming up: as a backend engineer, recently started working on frontend. Is this how yall do things? Everything so far feels less mature, thinly piec

Cliche rant coming up: as a backend engineer, recently started working on frontend. Is this how yall do things? Everything so far feels less mature, thinly pieced together, barely holding up, fast moving, unnecessarily bloated, and no care for longevity, robustness and discipline. Seems like every thing is on Youtube, no real good books (yeah, go ahead and search for "React JS" books on Amazon and see if you find something solid that is well praised). It's these 8 hour fucking Youtube videos that I need to watch and probably not remember anything. I watched one of those and its horrifying what kind of stuff these people are teaching. I am obviously generalizing, sure there are some really smart people involved in Frontend tech, but boy if you take a sweeping look from ten thousand feet, it ain't pretty. Well, first reaction for most people would be I am offended by this. But, I am speaking from the heart. This is exactly how I bloody feel, change my mind. The entire frontend ecosystem including browsers and the horrible mess that html/css/js is needs to be redone properly from scratch. Unfortunately, we can't because we've dug ourselves deep into this hole. How do we get out of this? /rant

dboreham 6y ago
Moving fast and breaking stuff.
kag0 6y ago
As a backend engineer who has worked on frontend recently, yes, that's how they do things. There is some hope though, recent standards like web components and ES imports help a bit.
factorialboy 6y ago
I think it's about individual maturity than tech-stack. Frontenders are likely to be younger than backenders, and some of the traits you observed are a result of that.
- cosmodisk 6y ago
  Maybe,but it's not the kids who sit at the top of the food chain in places like language committees, standard agencies, or even the CTOs of this world ( the real ones,not those of 5 person startups) where things get decided for years or even decades ahead.
  - factorialboy 6y ago
    I'm not blaming kids. And the constant churn is not a bad thing. Next time I build a team, I might consciously choose a mix of stable experienced senior devs, and perhaps a couple of young ignorant-but-brave junior devs. Horses for courses.
fmakunbound 6y ago
Sound’s like a pretty accurate description. It’s been like this for several years now I’m afraid.
Pfhreak 6y ago
I've worked in front end and backend systems. I've worked with extremely high scale web services at FAANG. I've made videogames, and done data processing pipelines. In general, I find that people will look at the domain outside of their area of expertise and say, "Holy shit, how do you work like this?" All the front end devs are like, "You have to wait how many minutes for compile times?" for instance. I think the important thing to remember is that engineers are doing complex engineering at every layer of the stack. And that because of environment and targets they are building for, they've made some tradeoffs around their development.
- worble 6y ago
  >All the front end devs are like, "You have to wait how many minutes for compile times?" for instance. This is funny because waiting for typescript to build is probably double or even triple waiting for my .NET project to compile at this point. I swear it gets slower every update.
  - Pfhreak 6y ago
    I'm not familiar with TS compile times, most of the engineers I know working on FE code use JS.
  - robin21 6y ago
    Yeh Babel and webpack blow out compile times to epic proportions. Any app that grows to a certain size will slow down to a crawl on incremental builds.
    - astrod 6y ago
      There has been some interesting tooling being written in Rust, swc[1] compiles very fast. Not quite production ready but getting there. [1]https://swc.rs/ https://swc.rs/
    - esperent 6y ago
      Try esbuild. I thought the following benchmarks must be fake until I tried it myself. https://raw.githubusercontent.com/evanw/esbuild/master/images/benchmark.png https://raw.githubusercontent.com/evanw/esbuild/master/image...
deleted 6y ago
[deleted]
mattwad 6y ago
I think at its core, the issue is that the code has to run in many different types of hostile environments. At least now we can sort of assume what features of the language are available, but you still have no control over the browser, OS, memory, or bandwidth available. There's no getting out of it :)
halfmatthalfcat 6y ago
How is JS and it’s ecosystem any less mature than Go or Rust? There’s a plethora of mature frameworks, build tooling and patterns on the frontend as well as a lot of cutting edge competition that creates a lot of noise. The point is though that there’s just a lot going on in JS world. Doesn’t mean it’s any less than any other language and it’s ecosystem.
- tstrimple 6y ago
  The bar for participation is dramatically lower for JS. I think that's unequivocally a good thing, but it does lead to explosions of libraries and toolchains of questionable quality which iterate rapidly. There is SO MUCH JS stuff out there that even just the bad stuff greatly outnumbers what you have in Rust or Go. It's the same reason why PHP has such a bad reputation. It was used and abused by non-developers just getting shit done for years that if you casually looked around the PHP world 10 years ago everything looked like crap. Quite frankly I'm over the elitism that so often accompanies these discussions where people ignorant about how other domains work make huge assumptions about the quality of said ecosystem. It's classic Dunning Kruger.
  - franklyt 6y ago
    If you’re developing a library that people use, it’s not because the bar is “low”. An amateur engineer doesn’t develop popular or useful technology overnight.
jakelazaroff 6y ago
Sure, there are a lot of warts. But it feels less mature because it is less mature. Consider that you’re coming from a domain that’s three decades old into one that really only started gaining steam in the 2010s.
olingern 6y ago
Do you remember when you could rent a physical machine somewhere and have something running in 5 minutes? We moved to something more verbose to support the new volume of the internet. The same has happened on the front-end. I consider some front-ends, like Twitter’s, applications just as I do iOS or Android. You can get out of this by using jQuery. It still works.
- esperent 6y ago
  > You can get out of this by using jQuery. You don't even need jQuery these days. All the important functionality is now in the DOM by default.
deleted 6y ago
[deleted]
mobilio 6y ago
Well... things on browsers, html and css are technically most OK. But JS is outstanding on this mess: https://httparchive.org/reports/state-of-javascript https://httparchive.org/reports/state-of-javascript Please note that this is transfer size. So if some script like jQuery 1.X is 90kb minified, but compressed is like 30k. That's why we shouldn't asking ourselves why some users using a 3rd party tools to disable trackers, ads (like PiHole) or even disable JS using browser extensions. And now good news... this time Google. Google are making Core Web Vitals: https://web.dev/vitals/ https://web.dev/vitals/ trying to evaluate sites using CrUX RUM. And soon they will this will be included in ranking algorithm: https://developers.google.com/search/blog/2020/11/timing-for-page-experience https://developers.google.com/search/blog/2020/11/timing-for... This announce make most of webmasters freaking out about web speed finally.
fctorial 6y ago
> no real good books React reference documentation?
- systemvoltage 6y ago
  Yep, I've resorted to that. But, there is more to docs that's needed to get wisdom from others who've built large apps and getting that in a concise book format would be nice. Otherwise, we can all throw away all books written about any programming topic, right?
  - deleted 6y ago
    [deleted]
  - typeengineering 6y ago
    I know right, I dug up a flex 3 book this new years it was so nice to actually read an actual quality book instead of some docs online.
gerdesj 6y ago
Is that why as a security focussed bod I get to read this sort of thing: https://googleprojectzero.blogspot.com/2021/01/introducing-in-wild-series.html https://googleprojectzero.blogspot.com/2021/01/introducing-i...
inopinatus 6y ago
Unfortunately yes. In all my four decades in tech, code bitrots in the the web front-end environment faster than any other I've yet seen. The Javascript language in particular (and its ecosystem) remains a baroque Gormenghast of curiosities built on an ancient sewer where nightmare beasts still roam, and everyone's holed up in the throne room hoping a few trusted paladins will somehow decontaminate the rest. > How do we get out of this? Personally, I try to use as little JS as possible. CSS is in better shape and handles a ton of page-level behaviours, HTTP/2 has done wonders for round-trip responsiveness, such that server-rendered HTML still holds the productivity crown for building out MVPs and SaaS application interfaces and the like. When I absolutely must write JS, I'll tend towards typescript these days, and minimise dependencies to the point where I hopefully have no node_modules/ or bundler at all.
- systemvoltage 6y ago
  I am struggling with this. I have made an Amazon storefront in React JS + npm package manager after watching this tutorial. I must have deleted the node_modules folder a dozen or more times and if you npm install again, it works! This is the kind of stuff that makes me wonder, how can I make a production worthy app without the fear of not being able to fix the dependencies!? Took me 2 hours to just to find out that some module wasn't compatible with Node version 15.
  - cozuya 6y ago
    Why would you default to using the non long term support version? Would you do that for, say, ubuntu?
    - inopinatus 6y ago
      It’s an easy blind alley to blunder down on some platforms. If one’s package manager defaults to edge versions and you’re just getting standard with a new language/framework via a tutorial, for example, this is how you learn there’s an LTS release the hard way. Homebrew users on Mac are common victims, but similarly Arch Linux or FreeBSD may trap the unwary (and for more besides than merely Node)
jamesgeck0 6y ago
Javascript tooling is crazy. A couple years ago I tried to build an older Ionic app that nobody had touched for six months, and the build had just bitrotted. Something somewhere in the dependencies hadn't been screwed down tightly enough, and everything was broken. I feel like the Yarn 2 package manager is a good move towards in making frontend development more stable (The "Plug'n'Play" feature allows you to store your dependencies in your repo as zip files, just in case), but a lot of libraries are still the wild west. There are "boring" frameworks like Ember and Angular that move slowly and limit breakage, but they're pretty unpopular with many developers, despite being great for building products in an enterprise setting. I disagree strongly about browsers; having an extremely stable platform that never breaks backwards compatibility is exactly what the web needs to be. Frontend development tooling would be so much better if it was more like browsers.
- systemvoltage 6y ago
  > having an extremely stable platform that never breaks backwards compatibility is exactly what the web needs to be. Frontend development tooling would be so much better if it was more like browsers. This is precisely my fear [1]. I need something robust and will continue to work for a good foreseeable future. Do you recommend Angular for frontend? I've just tried React and Svelte, but I am told to stay away from Angular as a giant beast. [1] https://news.ycombinator.com/item?id=25798573 https://news.ycombinator.com/item?id=25798573
  - tstrimple 6y ago
    I've found Angular to be more effective than React at companies with a "developers are cogs" mentality. Angular has opinions about how things should be built and there is a lot of supporting material out there on how to do things the "Angular" way. It's much more heavy weight that React because it's a more comprehensive tool whereas React is just the rendering portion. If you're the type of developer who can push the boundaries of what's being done on the web, you'll be happier with React or other tools. If you want to just follow instructions and tutorials online for how to build a website use Angular or even a CMS.
  - 6y ago
john-shaffer 6y ago
The situation with Clojure/ClojureScript is a lot more stable. Most libraries are pretty rigorous about backwards-compatibility. When someone comes up with a better approach, they release it as a new library under a different name instead of making breaking changes to the old one. You will probably still need to pull in some npm packages, but you can cherry pick those and keep it to a manageable number.
mr_toad 6y ago
What’s wrong with MDN and the official React documentation? I’ve never even considered going to YouTube, of all places, for JavaScript documentation. What’s next, people reacting to JavaScript programming?
potta_coffee 6y ago
I work front and back end, I've seen frontend done the "simple" way but not often. The syndrome I'm observing is that guys are chasing the next thing so they can bump up to a better paying job, and nobody is ever worried about maintaining their flaming pile of garbage long-term. When new guys come in to find someone else's trash code, they always need to rewrite it in the new thing. It's really no that hard to use modern tools tastefully and with restraint, but it's so rare to see.
deleted 6y ago
[deleted]
eganjs 6y ago
I consider myself to traditionally be a backend engineer, though this has more been something I fell into rather than chose. I admit I feel I share some of your frustrations. In the past I have written production frontends in Angular and experimented with Vue and React. Out of all of them I found React to be the most enjoyable, but even then I still struggled with project setup and found the tooling confusing. I even quite like TS as a language, but I feel it's still quite limited by the fact it transpiles to JS. Recently, I discovered yew [0]. It is a Rust framework for building frontends using wasm. I really appreciate the robustness that Rust brings such as ownership checks and ADTs. I don't think it's for everyone, but it may be worth looking at if you perhaps find modern frontend development confusing frustrating. I've found it to be quite the breath of fresh air. If you do decide to have a look I found the examples [1] and getting started guide [2] very informative. [0] https://github.com/yewstack/yew https://github.com/yewstack/yew [1] https://github.com/yewstack/yew/tree/master/examples https://github.com/yewstack/yew/tree/master/examples [2] https://yew.rs/docs/en/getting-started/project-setup https://yew.rs/docs/en/getting-started/project-setup
literallycancer 6y ago
Expecting Amazon search results to do your research for you, that was never going to work.
ghufran_syed 6y ago
I can't make any promises, but many js engineers have found that clojurescript together with a framework like re-frame seems to offer a different mental model they find useful https://day8.github.io/re-frame/ https://day8.github.io/re-frame/

dboreham 6y ago

Moving fast and breaking stuff.

kag0 6y ago

As a backend engineer who has worked on frontend recently, yes, that's how they do things. There is some hope though, recent standards like web components and ES imports help a bit.

factorialboy 6y ago

I think it's about individual maturity than tech-stack. Frontenders are likely to be younger than backenders, and some of the traits you observed are a result of that.

cosmodisk 6y ago
Maybe,but it's not the kids who sit at the top of the food chain in places like language committees, standard agencies, or even the CTOs of this world ( the real ones,not those of 5 person startups) where things get decided for years or even decades ahead.
- factorialboy 6y ago
  I'm not blaming kids. And the constant churn is not a bad thing. Next time I build a team, I might consciously choose a mix of stable experienced senior devs, and perhaps a couple of young ignorant-but-brave junior devs. Horses for courses.

fmakunbound 6y ago

Sound’s like a pretty accurate description. It’s been like this for several years now I’m afraid.

Pfhreak 6y ago

I've worked in front end and backend systems. I've worked with extremely high scale web services at FAANG. I've made videogames, and done data processing pipelines. In general, I find that people will look at the domain outside of their area of expertise and say, "Holy shit, how do you work like this?" All the front end devs are like, "You have to wait how many minutes for compile times?" for instance. I think the important thing to remember is that engineers are doing complex engineering at every layer of the stack. And that because of environment and targets they are building for, they've made some tradeoffs around their development.

worble 6y ago
>All the front end devs are like, "You have to wait how many minutes for compile times?" for instance. This is funny because waiting for typescript to build is probably double or even triple waiting for my .NET project to compile at this point. I swear it gets slower every update.
- Pfhreak 6y ago
  I'm not familiar with TS compile times, most of the engineers I know working on FE code use JS.
- robin21 6y ago
  Yeh Babel and webpack blow out compile times to epic proportions. Any app that grows to a certain size will slow down to a crawl on incremental builds.
  - astrod 6y ago
    There has been some interesting tooling being written in Rust, swc[1] compiles very fast. Not quite production ready but getting there. [1]https://swc.rs/ https://swc.rs/
  - esperent 6y ago
    Try esbuild. I thought the following benchmarks must be fake until I tried it myself. https://raw.githubusercontent.com/evanw/esbuild/master/images/benchmark.png https://raw.githubusercontent.com/evanw/esbuild/master/image...

deleted 6y ago

[deleted]

mattwad 6y ago

I think at its core, the issue is that the code has to run in many different types of hostile environments. At least now we can sort of assume what features of the language are available, but you still have no control over the browser, OS, memory, or bandwidth available. There's no getting out of it :)

halfmatthalfcat 6y ago

How is JS and it’s ecosystem any less mature than Go or Rust? There’s a plethora of mature frameworks, build tooling and patterns on the frontend as well as a lot of cutting edge competition that creates a lot of noise. The point is though that there’s just a lot going on in JS world. Doesn’t mean it’s any less than any other language and it’s ecosystem.

tstrimple 6y ago
The bar for participation is dramatically lower for JS. I think that's unequivocally a good thing, but it does lead to explosions of libraries and toolchains of questionable quality which iterate rapidly. There is SO MUCH JS stuff out there that even just the bad stuff greatly outnumbers what you have in Rust or Go. It's the same reason why PHP has such a bad reputation. It was used and abused by non-developers just getting shit done for years that if you casually looked around the PHP world 10 years ago everything looked like crap. Quite frankly I'm over the elitism that so often accompanies these discussions where people ignorant about how other domains work make huge assumptions about the quality of said ecosystem. It's classic Dunning Kruger.
- franklyt 6y ago
  If you’re developing a library that people use, it’s not because the bar is “low”. An amateur engineer doesn’t develop popular or useful technology overnight.

jakelazaroff 6y ago

Sure, there are a lot of warts. But it feels less mature because it is less mature. Consider that you’re coming from a domain that’s three decades old into one that really only started gaining steam in the 2010s.

olingern 6y ago

Do you remember when you could rent a physical machine somewhere and have something running in 5 minutes? We moved to something more verbose to support the new volume of the internet. The same has happened on the front-end. I consider some front-ends, like Twitter’s, applications just as I do iOS or Android. You can get out of this by using jQuery. It still works.

esperent 6y ago
> You can get out of this by using jQuery. You don't even need jQuery these days. All the important functionality is now in the DOM by default.

deleted 6y ago

[deleted]

mobilio 6y ago

Well... things on browsers, html and css are technically most OK. But JS is outstanding on this mess: https://httparchive.org/reports/state-of-javascript https://httparchive.org/reports/state-of-javascript Please note that this is transfer size. So if some script like jQuery 1.X is 90kb minified, but compressed is like 30k. That's why we shouldn't asking ourselves why some users using a 3rd party tools to disable trackers, ads (like PiHole) or even disable JS using browser extensions. And now good news... this time Google. Google are making Core Web Vitals: https://web.dev/vitals/ https://web.dev/vitals/ trying to evaluate sites using CrUX RUM. And soon they will this will be included in ranking algorithm: https://developers.google.com/search/blog/2020/11/timing-for-page-experience https://developers.google.com/search/blog/2020/11/timing-for... This announce make most of webmasters freaking out about web speed finally.

fctorial 6y ago

> no real good books React reference documentation?

systemvoltage 6y ago
Yep, I've resorted to that. But, there is more to docs that's needed to get wisdom from others who've built large apps and getting that in a concise book format would be nice. Otherwise, we can all throw away all books written about any programming topic, right?
- deleted 6y ago
  [deleted]
- typeengineering 6y ago
  I know right, I dug up a flex 3 book this new years it was so nice to actually read an actual quality book instead of some docs online.

gerdesj 6y ago

Is that why as a security focussed bod I get to read this sort of thing: https://googleprojectzero.blogspot.com/2021/01/introducing-in-wild-series.html https://googleprojectzero.blogspot.com/2021/01/introducing-i...

inopinatus 6y ago

Unfortunately yes. In all my four decades in tech, code bitrots in the the web front-end environment faster than any other I've yet seen. The Javascript language in particular (and its ecosystem) remains a baroque Gormenghast of curiosities built on an ancient sewer where nightmare beasts still roam, and everyone's holed up in the throne room hoping a few trusted paladins will somehow decontaminate the rest. > How do we get out of this? Personally, I try to use as little JS as possible. CSS is in better shape and handles a ton of page-level behaviours, HTTP/2 has done wonders for round-trip responsiveness, such that server-rendered HTML still holds the productivity crown for building out MVPs and SaaS application interfaces and the like. When I absolutely must write JS, I'll tend towards typescript these days, and minimise dependencies to the point where I hopefully have no node_modules/ or bundler at all.

systemvoltage 6y ago
I am struggling with this. I have made an Amazon storefront in React JS + npm package manager after watching this tutorial. I must have deleted the node_modules folder a dozen or more times and if you npm install again, it works! This is the kind of stuff that makes me wonder, how can I make a production worthy app without the fear of not being able to fix the dependencies!? Took me 2 hours to just to find out that some module wasn't compatible with Node version 15.
- cozuya 6y ago
  Why would you default to using the non long term support version? Would you do that for, say, ubuntu?
  - inopinatus 6y ago
    It’s an easy blind alley to blunder down on some platforms. If one’s package manager defaults to edge versions and you’re just getting standard with a new language/framework via a tutorial, for example, this is how you learn there’s an LTS release the hard way. Homebrew users on Mac are common victims, but similarly Arch Linux or FreeBSD may trap the unwary (and for more besides than merely Node)

jamesgeck0 6y ago

Javascript tooling is crazy. A couple years ago I tried to build an older Ionic app that nobody had touched for six months, and the build had just bitrotted. Something somewhere in the dependencies hadn't been screwed down tightly enough, and everything was broken. I feel like the Yarn 2 package manager is a good move towards in making frontend development more stable (The "Plug'n'Play" feature allows you to store your dependencies in your repo as zip files, just in case), but a lot of libraries are still the wild west. There are "boring" frameworks like Ember and Angular that move slowly and limit breakage, but they're pretty unpopular with many developers, despite being great for building products in an enterprise setting. I disagree strongly about browsers; having an extremely stable platform that never breaks backwards compatibility is exactly what the web needs to be. Frontend development tooling would be so much better if it was more like browsers.

systemvoltage 6y ago
> having an extremely stable platform that never breaks backwards compatibility is exactly what the web needs to be. Frontend development tooling would be so much better if it was more like browsers. This is precisely my fear [1]. I need something robust and will continue to work for a good foreseeable future. Do you recommend Angular for frontend? I've just tried React and Svelte, but I am told to stay away from Angular as a giant beast. [1] https://news.ycombinator.com/item?id=25798573 https://news.ycombinator.com/item?id=25798573
- tstrimple 6y ago
  I've found Angular to be more effective than React at companies with a "developers are cogs" mentality. Angular has opinions about how things should be built and there is a lot of supporting material out there on how to do things the "Angular" way. It's much more heavy weight that React because it's a more comprehensive tool whereas React is just the rendering portion. If you're the type of developer who can push the boundaries of what's being done on the web, you'll be happier with React or other tools. If you want to just follow instructions and tutorials online for how to build a website use Angular or even a CMS.
- 6y ago

john-shaffer 6y ago

The situation with Clojure/ClojureScript is a lot more stable. Most libraries are pretty rigorous about backwards-compatibility. When someone comes up with a better approach, they release it as a new library under a different name instead of making breaking changes to the old one. You will probably still need to pull in some npm packages, but you can cherry pick those and keep it to a manageable number.

mr_toad 6y ago

What’s wrong with MDN and the official React documentation? I’ve never even considered going to YouTube, of all places, for JavaScript documentation. What’s next, people reacting to JavaScript programming?

potta_coffee 6y ago

I work front and back end, I've seen frontend done the "simple" way but not often. The syndrome I'm observing is that guys are chasing the next thing so they can bump up to a better paying job, and nobody is ever worried about maintaining their flaming pile of garbage long-term. When new guys come in to find someone else's trash code, they always need to rewrite it in the new thing. It's really no that hard to use modern tools tastefully and with restraint, but it's so rare to see.

deleted 6y ago

[deleted]

eganjs 6y ago

I consider myself to traditionally be a backend engineer, though this has more been something I fell into rather than chose. I admit I feel I share some of your frustrations. In the past I have written production frontends in Angular and experimented with Vue and React. Out of all of them I found React to be the most enjoyable, but even then I still struggled with project setup and found the tooling confusing. I even quite like TS as a language, but I feel it's still quite limited by the fact it transpiles to JS. Recently, I discovered yew [0]. It is a Rust framework for building frontends using wasm. I really appreciate the robustness that Rust brings such as ownership checks and ADTs. I don't think it's for everyone, but it may be worth looking at if you perhaps find modern frontend development confusing frustrating. I've found it to be quite the breath of fresh air. If you do decide to have a look I found the examples [1] and getting started guide [2] very informative. [0] https://github.com/yewstack/yew https://github.com/yewstack/yew [1] https://github.com/yewstack/yew/tree/master/examples https://github.com/yewstack/yew/tree/master/examples [2] https://yew.rs/docs/en/getting-started/project-setup https://yew.rs/docs/en/getting-started/project-setup

literallycancer 6y ago

Expecting Amazon search results to do your research for you, that was never going to work.

ghufran_syed 6y ago

I can't make any promises, but many js engineers have found that clojurescript together with a framework like re-frame seems to offer a different mental model they find useful https://day8.github.io/re-frame/ https://day8.github.io/re-frame/