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.
>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.
> All the front end devs are like, "You have to wait how many minutes for compile times?" for instance.
This is a shocking argument coming from any front end dev. Since when is static type checking, working on serious big repositories that take time to compile, have proper architecture with hundreds if not thousands of programmers working on it comparable to 3 frontend folks working on a web application? There is so much wrong with this argument and haven't scratched the surface.
I think you have a fairly dated understanding of what front end is, it's scale, and the complexity of delivering an experience that's fast and well optimized.
These days front end engineering can be every bit as rigorous and complex as back end engineering. The constraints are a bit different, and the environments are very different, but the scale and complexity of engineering is not.
I believe you might have a slightly biased view of what front-end development largely looks like. What you're describing is the type of front-end development that goes on at the organizations that actually develop these frameworks.
The vast majority of front-end development outside of that world is misguidedly trying to mimic that complexity on their static business informational page they maintain with a duct taped mess of bad practices everywhere.
Now if you take a look at development outside of front-end and go to some large non-tech, mid-sized, or small business you'll probably also find poor practices (from my experience), but nothing like the mess I see in these
same organizations trying front-end development now.
If someone is making a static business informational page, it’s significantly more likely that they’re using WordPress and jQuery than e.g. React [1]. Like, significantly significantly — 20x more likely to be using jQuery (which is on a full 83% of all webpages) than React, and 30x more likely to be using WordPress than Gatsby or whatever.
People on HN talk about React and friends because they’re building client-side apps that deserve full frameworks. But it’s absolutely not representative of most web development.
Perhaps, I've only seen front end projects at FAANG and personal projects. That said, my front projects have at least an eslint config and usually a CI/CD deployment strategy if not full on tests.
Do you ever wonder whether we cause the complexity ourselves. Did we need React? Flux? Graphql? Since we introduced these concepts we needed to rethink a huge amount of other stuff to keep it performant.
Compare the simplicity of jQuery vs a modern tool chain. Like creating a form. It gets pretty insane with React. And jQuery would be dead simple.
You have to stay on the bandwagon because it’s where the community is now. There’s certainly a lot more fun to be had remaking everything in React though.
The main advantage of react in my opinion is the reusability of components. Most developers are not artists and can't design aesthetic and ergonomic interfaces from basic web elements, whereas with react you can install a component library (like material UI) and effectively just focus on business logic.
I'm mainly a backend developer so can't comment on how this tradeoff works out when you have the resources for artistic UI/UX folks and reduced development pace.
If all you’re doing is submitting a form with Ajax, sure, jQuery would be fine. But I’ll venture that most frontend apps are at least somewhat more complicated than that.
My side project is a web app that lets you create music visualizer videos. There’s a ton of UI, state, complex interaction between parts, etc. If I weren’t using React, I’d be using something — but it would surely be another full-on framework, not a simple library like jQuery.
It’s pretty clear you haven’t worked on any modern front end site. Go and try and build any front end site demanded by most business owners in jquery. It’s not just bandwagon, it’s solving problems in the environment in which they are required with the tools that are present. It’s so incredibly naive to think the efforts of tens of thousands is all pointless if they just used this one tool.
The reality is that most front-ends at most companies don't require that level of engineering. Sure if you work at Netflix or Facebook, there may be a lot of "real engineering" going on but most people don't work at those companies. But the guys at these small companies want to feel special, so they reach for whatever the big guys are doing and try to implement it, regardless of need. The same thing happens with (insert your domain here). Like, we have a single webstore with 10k customers, we need a Kubernetes cluster etc etc because Google does it.
It brings a package.json and a lockfile into your repo. There's arguments to be made against NPM but it doesn't bring any diffent "crud" into your repo than Composer, Maven, Pip/Pipenv/Poetry, or any other package manager.
That's an odd comment to make, you just inadvertently proved their point. Most large web products are serious (?), have 'proper architecture' and hundreds of frontend developers working on them. Google products, Spotify, AirBnB, JIRA/Atlassian, Booking.com, Trello, GitHub.. you name it. You may also notice TypeScript in the first paragraph of the report, which is a type checker and has been enjoying massive adoption.
Not 'his', 'their', but yes, I agree that the projects being done on the web are hugely complex these days and have a rich set of building, linting, releasing, testing, etc. tools.
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.