Building a front end that other humans will use is literally art. Like in the classical sense. Confounding this with an API surface, 2nd state machine and additional team (the backend developers) turns an already difficult mission into an impossible one.
Learning how to do the whole thing is a lot easier in 2025 than it was in 2010. You have a consistent browser API surface and a chatbot that has the capability of every junior developer on earth combined at your disposal.
Being put into the position of full ownership means you will reject bad technologies out of sheer survival instinct. You'll reach for approaches like SSR. Putting all of the state on the server (by using server side rendering exclusively) means that there is no more API. No more distributed state. You are now permitted to write sql queries that directly populate the relevant HTML partials without any intermediate bullshit. Imagine how quickly we could compose response bodies if the authoritative data store lives on an NVMe disk in the same machine. You could be measuring your page render times in microseconds instead of milliseconds.
Sort of. It's actually backwards because BE work should be demand based driven by the needs of the FE.
This allows 3 things: a BE API as a promise AND division of labor (when possible and/or necessary) AND building what's essential on-demand by thinking about the FE's planning and needs first.
The problem with building a BE first is that leads to unnecessary work.
I'm a bit biased because I prefer standardized/CoC, monolithic development that doesn't have too much disconnection between the FE and BE stacks.
This is all very fair, and yet I think many would agree that the “frontend ceiling” is a thing, that many candidates are not skilled enough for the roles, and that the general state of frontend engineering is not great.
This is perhaps less true in 2025 than it was in 2012, but I feel it was largely the same until maybe 2022, and is still not far off this.
I think the engineering is underestimated, but also I think job applicants are very bimodal - some coming from a design or boot camp background, able to be productive but not run scaled engineering projects, and some from perhaps a backend/etc background and can scale a codebase, but who are prone to trivialising frontend development and giving less consideration to design and UX.
There is also the "backend of frontend", for a lack of a better term. When you've got a complex webapp, you start managing a lot of state on the frontend. You basically end up with a second database that you keep in sync, possibly two.
I think it's pretty common nowadays to have indexdb to cache data, but also your state management framework (ngrx,redux,mobx,etc) which sits between indexdb and your rendering framework.
I am (unfortunately) a FE engineer nowadays but I write very little HTML/CSS. It's mostly wrangling FE state and making it "efficient", cache invalidation, optimistic updates that mimic BE operations, etc.
On top of that, the complexity of front end (for me, which is in a “real time” app) often comes down to providing a user experience that “feels good” while also accounting for the complexities of keeping things in sync with the backend(s). For example, I often want a user to be able to update a thing and I want that change to feel immediate, but if 1% of the time that errors out because of business logic reasons, I need to be able to undo the immediateness, restore the previous state, maybe reconcile the local state with the newer remote state, and then display the problem to the user.
Maybe I’m just doing things wrong but there’s just a lot of complexity related to that and I struggle compartmentalizing it in a maintainable way
It’s a pretty unconventional way to do it these days, but blow it all away and load the page fresh from the server.
Maintaining a consistent state is very difficult at the best of times. This obviously has implications for the backend, it needs to respond quickly and the page render in a decent time(minimal libraries).
Personally, to the degree that I ever distinguish between “web apps” and just normal sites, one of the distinguishing features of web apps for me is whether forcing a page reload on the majority of interactions would be unacceptably clunky to most users.
Provided page reloads are fast, I think far more sites would be completely fine with just being sites and not rich client apps.
It really depends. For a "regular" website or blog, I agree. I think people over use complicated web frameworks to just serve what amounts to a mostly static page.
But the approach just doesn't work for things like Slack, Figma, Google docs. When you're trying to create an experience that's somewhat similar to a native application on the web, you need to start worrying about local state.
I find that frontend takes most of the dev time for most apps, and I certainly consider it "harder" to get everything working to the quality level I want. However, backend work is usually more critical, as problems can result in data loss or security issues. Frontend problems often just result in bad UX, and they are easier to do a surface-level check too (just use the app and check that it works).
Due to this, companies may have a higher bar of expertise for backend which may give the impression that it is "harder", but I don't think this is a very important distinction.
I’m a frontend dev. I’ve done backend and database administration work at a few points in my career, but never on sizable products or for more than a year or two at a time.
I largely agree with your points. The backend has the largest security and reliability burden. It’s the bottleneck everything has to go through, and it can’t trust anything it’s receives. If it breaks nothing else can work. Also, backend deployments tend to involve a lot more moving parts.
> they are easier to do a surface-level check too (just use the app and check that it works)
If what you were getting at with this is that the make change -> see result loop for the frontend is overall faster, I’d thoroughly agree with that. It’s why I’ve never stayed on the backend for long. It’s pretty cool to be able to make a change and see it reflected in the UI within a couple hundred milliseconds without losing application state.
But while that’s probably the usual case, for a significant amount of the work it’s woefully insufficient. When trying to fix something, “just using the app” often involves significant deviations from the way you’d normally use it. Typical user bases use apps in maddeningly diverse ways. They have different browsers, operating systems, displays (DPI and color systems/accuracy), screen sizes, pointing devices (mouse vs touch), and assistive technologies (e.g. multiple screen readers, each of which has its own quirks). Members of product teams—particularly ones who aren’t web specialists—frequently forget some of these. Surface level tests obviously don’t include the entire testing matrix, but they often involve iterating on at least two combinations of use at the same time, and those combinations may involve significant overhead.
Accessibility presents a particularly hard challenge for quick tests, as most developers I’ve worked with don’t know how to use screen readers to do much, so just using the app isn’t possible for them without some additional learning.
Hopefully your testing matrix is mostly automated, but those automated tests are too slow to use during development. Initial bug isolation and getting proper tests around specific interactions can be extremely tricky.
I'm saying from the perspective of someone overseeing a frontend dev, that I can just try out the app feature and see if things seem to be working as expected. Though as you mention, it's necessary to check a variety of devices and other edge cases, depending on the project requirements.
With backend though, even if it seems to work, there can be severe hidden problems with the architecture and security, so I really need to trust the backend dev or verify things deeply myself in order to ensure quality.
If I'm making a quick app for a startup, I can often hire relatively less experienced frontend devs, but have to care much more about the backend.
It really depends what I'm building, and I find that these are often additional tasks that are done later after the core functionality is validated. I've most often built apps used internally or to test concepts for early user feedback, that had a relatively low bar. But regardless, I can verify these without as much deep knowledge of the code by trying them myself, but can't verify easily that the backend was coded securely and properly.
But, covering all these cases and doing all the polish and animations expected of high quality frontends has usually taken much longer when I've needed to do it, 80% of the dev time has been frontend in some cases.
> It really depends what I'm building, and I find that these are often additional tasks that are done later after the core functionality is validated. I've most often built apps used internally or to test concepts for early user feedback, that had a relatively low bar.
Prototyping and internal tooling are both obviously things with far different bars for quality (much as I wish internal tooling wasn’t treated like that). I’ve not felt much difference in prototyping endpoints on the backend versus new pages in the UI in terms of difficulty. Internal sites usually have dramatically lower quality bars than production apps, though hopefully you’re not treating accessibility any differently for them. A company can mandate that their employees use a specific browser. The company knows which hardware/OS are used. They also can often support only one language unless they’re large. Most tools don’t have to worry much about turning away customers.
Earlier you mentioned sneaking architectural issues. Frontends are rife with these, and this is part of why there’s so much churn in frontend frameworks and APIs. It’s often incredibly easy to make a UI which appears to work and satisfy the requirements as given, but unless you’re aware of the things listed in other comments the resulting codebase might need an entire rewrite to support the actual features which customers expect. Maybe you built an entire UX which fundamentally doesn’t work when using a screen reader or a software keyboard. You might you have no way to support optimistic updates or undo. Maybe your choice of routing framework won’t allow you to block a route update until some data is loaded or an animation is finished. Sometimes these things are easy to bolt on, sometimes they result in weeks of lost progress. All that might be acceptable for an internal site, but the vast majority of frontend developers spend most of their time on client-facing ones.
I guess my main point is that I frequently hear stuff like this from backend developers, and I also frequently have to fix the frontend code they wrote because they just didn’t know how much goes into making the slightest bit of a non-trivial workflow for customers. As an aside, I think the worst offenders in this regard are actually people who describe themselves as full stack. I have done a fair bit of backend work. I’m not full stack. My backend work rarely has to worry about load balancing or database consistency, but that’s because actual backend devs are catching those things for me. I know those things exist though, and that many more that I’m not aware of do too.
> I'm saying from the perspective of someone overseeing a frontend dev, that I can just try out the app feature and see if things seem to be working as expected
Not every project has a quality bar as low as this.
I haven't worked in the frontend in quite a while, but when I interact with it, the problem seems to be that is written by a lot of inexperienced people, so it's full of rookie mistakes which make the tech debt even more unmanageable than the backend.
Given that performance is more relevant to deliver a good ui in the frontend, unless you are going to but the devices yourself, the poor code ends up being a problem, so more people are hired to fix it, executing the vision of the more senior devs.
Given the situation with hiring, this might be good and still give some space to junior devs to exist. But I could be wrong and AI could be doing already a better job.
I'm surprised nobody's talking about the hireability of FE vs BE engineers. The specialist vs generalist debate has been raging on for multiple decades now and the general conclusion is that only early stage startups hire generalists. Everybody else wants a specialist.
I'll go one farther: nobody hires senior FE engineers.
FE is perceived as having a lower skill ceiling than BE[0]. I rarely see an FE position (or a "senior" FE position) require more than 3 years of experience. And can you blame them when FE technologies churn so much faster than BE ones? It's still fairly common to have a decade old Java backend running against an equally old postgresql database. Who still runs jquery (other than levelsio)?
[0]: I do not agree with this, but it's a common perception.
It used to be front end needed to learn a new framework every couple of years but now with the balkanization of build tools as well it's even worse. OK for the first two or three decades, then gets harder. Is AI now making this easier - have AI do the nitty gritty framework specific code?
I do full stack stuff at my job but front end is my favorite thing to work on, particularly if it's an interesting UX.
I think a good understanding of design is also something people don't get about front end. Limited designs from designers means I fill in the gaps in some places.
Dealing with every possible edge case. Breaking out the advanced web APIs when they can easily solve certain problems, e.g. Intersection Observers or Mutation Observers.
Breaking out the advanced CSS APIs like @property rules for super easy and smooth animations.
Improving tooling and JS builds. Making sites fast and reliable.
On and on. Front end can get looked down upon if you're making the same old stuff over and over again. A modal here, a toast there.
But when you get assigned the crazy shit designers come up with, it becomes a very intricate challenge to create the the simplest solutions you can.
Yeah. I am a backend dev these days because it pays more.
Backend people have this obnoxious attitude of looking down on frontend without having any idea what it entails.
Also demonising V8 and glorifying the JVM for some reason. In my experience frontend challenges around animation for example require a lot more reasoning than most backend tasks.
The demand is higher for FE Engineers precisely because it's easier. You have a low entry bar and more mediocre/inexperienced devs get in, create a mess and move on to better opportunities because now they have the 1 or 2 years extra of engineering xp and have also padded their resumes a bit.. also they need to higher more devs because tickets churn out rate is not the best either..
if you agree no need to up vote.. but if you disagree then do up vote as I told you something you needed to hear..
My opinion on this matter is that in the Good Old Days, that is before LLMs, frontend development was just more laborious for average, run of the mill business web and mobile projects. There were several frontend developers needed for one backender, just because for business apps, backend is usually simple.
I would say in 2025, it has become exponentially more complex, not simpler:
1. The ecosystem has fragmented further. Every app uses even more tools and frameworks, each with its own quirks and version incompatibilities
2. With E2EE and blockchain-based apps becoming mainstream, the frontend now handles complex cryptographic operations, key management, and secure data handling entirely client-side. Mistakes here are security vulnerabilities
> The ecosystem has fragmented further. Every app uses even more tools and frameworks, each with its own quirks and version incompatibilities
I disagree, at least partially. When this article was written, one of the biggest difficulties with front-end development was browser incompatibilities. Front-end developers were deploying to a hostile, inconsistent environment.
Things have gotten much better on that front. Browser support for standards is much better. People upgrade to the latest versions much more quickly. Systems that transcode from modern style to backwards compatible style, like Babel, TypeScript, Lightning CSS, or PostCSS, are commonplace.
The end result is that front-end developers are far more able to target modern APIs and functionality without worrying about compatibilities anywhere near as much. The browser environment has become much more consistent and capable.
Do some developers overcomplicate things with monstrous WebPack configs? They sure do. But the important thing is that they chose that. If you want to keep a super-simple build, you can do that too. You have the choice of how complicated your stack is; you don’t have a choice of how complicated the browser environment is.
> With E2EE and blockchain-based apps becoming mainstream
Blockchain isn’t mainstream, and hardly any front-end developers need to care about E2EE.
Full stack engineers are the best because they control the whole process. This is my method I made for myself: the Awful Backwards Software Method ABSM 1.) write your SQL queries first with all the CRLUD; the L is for logical deletes and updates 2.) then setup your database to use these queries modifying the queries as need be 3.) then in your front end create the functions which implement your queries in the language of your choice - John Eischen © ADAGP Paris art humanitarian use is authorized except for any AI uses
I don't think this is already a pattern but maybe somebody else is already doing it like the above so please let me know if it is the case
I agree that full stack is the best path.
Building a front end that other humans will use is literally art. Like in the classical sense. Confounding this with an API surface, 2nd state machine and additional team (the backend developers) turns an already difficult mission into an impossible one.
Learning how to do the whole thing is a lot easier in 2025 than it was in 2010. You have a consistent browser API surface and a chatbot that has the capability of every junior developer on earth combined at your disposal.
Being put into the position of full ownership means you will reject bad technologies out of sheer survival instinct. You'll reach for approaches like SSR. Putting all of the state on the server (by using server side rendering exclusively) means that there is no more API. No more distributed state. You are now permitted to write sql queries that directly populate the relevant HTML partials without any intermediate bullshit. Imagine how quickly we could compose response bodies if the authoritative data store lives on an NVMe disk in the same machine. You could be measuring your page render times in microseconds instead of milliseconds.
Sort of. It's actually backwards because BE work should be demand based driven by the needs of the FE.
This allows 3 things: a BE API as a promise AND division of labor (when possible and/or necessary) AND building what's essential on-demand by thinking about the FE's planning and needs first.
The problem with building a BE first is that leads to unnecessary work.
I'm a bit biased because I prefer standardized/CoC, monolithic development that doesn't have too much disconnection between the FE and BE stacks.
This is all very fair, and yet I think many would agree that the “frontend ceiling” is a thing, that many candidates are not skilled enough for the roles, and that the general state of frontend engineering is not great.
This is perhaps less true in 2025 than it was in 2012, but I feel it was largely the same until maybe 2022, and is still not far off this.
I think the engineering is underestimated, but also I think job applicants are very bimodal - some coming from a design or boot camp background, able to be productive but not run scaled engineering projects, and some from perhaps a backend/etc background and can scale a codebase, but who are prone to trivialising frontend development and giving less consideration to design and UX.
There is also the "backend of frontend", for a lack of a better term. When you've got a complex webapp, you start managing a lot of state on the frontend. You basically end up with a second database that you keep in sync, possibly two.
I think it's pretty common nowadays to have indexdb to cache data, but also your state management framework (ngrx,redux,mobx,etc) which sits between indexdb and your rendering framework.
I am (unfortunately) a FE engineer nowadays but I write very little HTML/CSS. It's mostly wrangling FE state and making it "efficient", cache invalidation, optimistic updates that mimic BE operations, etc.
Glad to see that BFF is not an outdated pattern. It makes sense.
Yep.
On top of that, the complexity of front end (for me, which is in a “real time” app) often comes down to providing a user experience that “feels good” while also accounting for the complexities of keeping things in sync with the backend(s). For example, I often want a user to be able to update a thing and I want that change to feel immediate, but if 1% of the time that errors out because of business logic reasons, I need to be able to undo the immediateness, restore the previous state, maybe reconcile the local state with the newer remote state, and then display the problem to the user.
Maybe I’m just doing things wrong but there’s just a lot of complexity related to that and I struggle compartmentalizing it in a maintainable way
It’s a pretty unconventional way to do it these days, but blow it all away and load the page fresh from the server.
Maintaining a consistent state is very difficult at the best of times. This obviously has implications for the backend, it needs to respond quickly and the page render in a decent time(minimal libraries).
Personally, to the degree that I ever distinguish between “web apps” and just normal sites, one of the distinguishing features of web apps for me is whether forcing a page reload on the majority of interactions would be unacceptably clunky to most users.
Provided page reloads are fast, I think far more sites would be completely fine with just being sites and not rich client apps.
It really depends. For a "regular" website or blog, I agree. I think people over use complicated web frameworks to just serve what amounts to a mostly static page.
But the approach just doesn't work for things like Slack, Figma, Google docs. When you're trying to create an experience that's somewhat similar to a native application on the web, you need to start worrying about local state.
I find that frontend takes most of the dev time for most apps, and I certainly consider it "harder" to get everything working to the quality level I want. However, backend work is usually more critical, as problems can result in data loss or security issues. Frontend problems often just result in bad UX, and they are easier to do a surface-level check too (just use the app and check that it works).
Due to this, companies may have a higher bar of expertise for backend which may give the impression that it is "harder", but I don't think this is a very important distinction.
I’m a frontend dev. I’ve done backend and database administration work at a few points in my career, but never on sizable products or for more than a year or two at a time.
I largely agree with your points. The backend has the largest security and reliability burden. It’s the bottleneck everything has to go through, and it can’t trust anything it’s receives. If it breaks nothing else can work. Also, backend deployments tend to involve a lot more moving parts.
> they are easier to do a surface-level check too (just use the app and check that it works)
If what you were getting at with this is that the make change -> see result loop for the frontend is overall faster, I’d thoroughly agree with that. It’s why I’ve never stayed on the backend for long. It’s pretty cool to be able to make a change and see it reflected in the UI within a couple hundred milliseconds without losing application state.
But while that’s probably the usual case, for a significant amount of the work it’s woefully insufficient. When trying to fix something, “just using the app” often involves significant deviations from the way you’d normally use it. Typical user bases use apps in maddeningly diverse ways. They have different browsers, operating systems, displays (DPI and color systems/accuracy), screen sizes, pointing devices (mouse vs touch), and assistive technologies (e.g. multiple screen readers, each of which has its own quirks). Members of product teams—particularly ones who aren’t web specialists—frequently forget some of these. Surface level tests obviously don’t include the entire testing matrix, but they often involve iterating on at least two combinations of use at the same time, and those combinations may involve significant overhead.
Accessibility presents a particularly hard challenge for quick tests, as most developers I’ve worked with don’t know how to use screen readers to do much, so just using the app isn’t possible for them without some additional learning.
Hopefully your testing matrix is mostly automated, but those automated tests are too slow to use during development. Initial bug isolation and getting proper tests around specific interactions can be extremely tricky.
I'm saying from the perspective of someone overseeing a frontend dev, that I can just try out the app feature and see if things seem to be working as expected. Though as you mention, it's necessary to check a variety of devices and other edge cases, depending on the project requirements.
With backend though, even if it seems to work, there can be severe hidden problems with the architecture and security, so I really need to trust the backend dev or verify things deeply myself in order to ensure quality.
If I'm making a quick app for a startup, I can often hire relatively less experienced frontend devs, but have to care much more about the backend.
I hope you're testing for all of the following:
- All of the widely used mobile and desktop browsers
- Inexpensive Android devices - very common, most devs don't test in them, frequently suffer from terrible frontend performance that goes overlooked
- Browsers running common ad blockers
- Screenreaders - frontend accessibility is a whole speciality in itself
- SEO concerns, making sure crawlers see the right stuff
- Slow network connections - simulate how the site behaves on devices in rural areas with bad connections
It really depends what I'm building, and I find that these are often additional tasks that are done later after the core functionality is validated. I've most often built apps used internally or to test concepts for early user feedback, that had a relatively low bar. But regardless, I can verify these without as much deep knowledge of the code by trying them myself, but can't verify easily that the backend was coded securely and properly.
But, covering all these cases and doing all the polish and animations expected of high quality frontends has usually taken much longer when I've needed to do it, 80% of the dev time has been frontend in some cases.
> It really depends what I'm building, and I find that these are often additional tasks that are done later after the core functionality is validated. I've most often built apps used internally or to test concepts for early user feedback, that had a relatively low bar.
Prototyping and internal tooling are both obviously things with far different bars for quality (much as I wish internal tooling wasn’t treated like that). I’ve not felt much difference in prototyping endpoints on the backend versus new pages in the UI in terms of difficulty. Internal sites usually have dramatically lower quality bars than production apps, though hopefully you’re not treating accessibility any differently for them. A company can mandate that their employees use a specific browser. The company knows which hardware/OS are used. They also can often support only one language unless they’re large. Most tools don’t have to worry much about turning away customers.
Earlier you mentioned sneaking architectural issues. Frontends are rife with these, and this is part of why there’s so much churn in frontend frameworks and APIs. It’s often incredibly easy to make a UI which appears to work and satisfy the requirements as given, but unless you’re aware of the things listed in other comments the resulting codebase might need an entire rewrite to support the actual features which customers expect. Maybe you built an entire UX which fundamentally doesn’t work when using a screen reader or a software keyboard. You might you have no way to support optimistic updates or undo. Maybe your choice of routing framework won’t allow you to block a route update until some data is loaded or an animation is finished. Sometimes these things are easy to bolt on, sometimes they result in weeks of lost progress. All that might be acceptable for an internal site, but the vast majority of frontend developers spend most of their time on client-facing ones.
I guess my main point is that I frequently hear stuff like this from backend developers, and I also frequently have to fix the frontend code they wrote because they just didn’t know how much goes into making the slightest bit of a non-trivial workflow for customers. As an aside, I think the worst offenders in this regard are actually people who describe themselves as full stack. I have done a fair bit of backend work. I’m not full stack. My backend work rarely has to worry about load balancing or database consistency, but that’s because actual backend devs are catching those things for me. I know those things exist though, and that many more that I’m not aware of do too.
> I'm saying from the perspective of someone overseeing a frontend dev, that I can just try out the app feature and see if things seem to be working as expected
Not every project has a quality bar as low as this.
I haven't worked in the frontend in quite a while, but when I interact with it, the problem seems to be that is written by a lot of inexperienced people, so it's full of rookie mistakes which make the tech debt even more unmanageable than the backend. Given that performance is more relevant to deliver a good ui in the frontend, unless you are going to but the devices yourself, the poor code ends up being a problem, so more people are hired to fix it, executing the vision of the more senior devs.
Given the situation with hiring, this might be good and still give some space to junior devs to exist. But I could be wrong and AI could be doing already a better job.
I'm surprised nobody's talking about the hireability of FE vs BE engineers. The specialist vs generalist debate has been raging on for multiple decades now and the general conclusion is that only early stage startups hire generalists. Everybody else wants a specialist.
I'll go one farther: nobody hires senior FE engineers.
FE is perceived as having a lower skill ceiling than BE[0]. I rarely see an FE position (or a "senior" FE position) require more than 3 years of experience. And can you blame them when FE technologies churn so much faster than BE ones? It's still fairly common to have a decade old Java backend running against an equally old postgresql database. Who still runs jquery (other than levelsio)?
[0]: I do not agree with this, but it's a common perception.
It used to be front end needed to learn a new framework every couple of years but now with the balkanization of build tools as well it's even worse. OK for the first two or three decades, then gets harder. Is AI now making this easier - have AI do the nitty gritty framework specific code?
I do full stack stuff at my job but front end is my favorite thing to work on, particularly if it's an interesting UX.
I think a good understanding of design is also something people don't get about front end. Limited designs from designers means I fill in the gaps in some places.
Dealing with every possible edge case. Breaking out the advanced web APIs when they can easily solve certain problems, e.g. Intersection Observers or Mutation Observers.
Breaking out the advanced CSS APIs like @property rules for super easy and smooth animations.
Improving tooling and JS builds. Making sites fast and reliable.
On and on. Front end can get looked down upon if you're making the same old stuff over and over again. A modal here, a toast there.
But when you get assigned the crazy shit designers come up with, it becomes a very intricate challenge to create the the simplest solutions you can.
Yeah. I am a backend dev these days because it pays more. Backend people have this obnoxious attitude of looking down on frontend without having any idea what it entails. Also demonising V8 and glorifying the JVM for some reason. In my experience frontend challenges around animation for example require a lot more reasoning than most backend tasks.
The demand is higher for FE Engineers precisely because it's easier. You have a low entry bar and more mediocre/inexperienced devs get in, create a mess and move on to better opportunities because now they have the 1 or 2 years extra of engineering xp and have also padded their resumes a bit.. also they need to higher more devs because tickets churn out rate is not the best either..
if you agree no need to up vote.. but if you disagree then do up vote as I told you something you needed to hear..
Because of endless design churn
Frontend isn’t easier.
Because front-end is the messier. Everything changes every 12-18 months.
My opinion on this matter is that in the Good Old Days, that is before LLMs, frontend development was just more laborious for average, run of the mill business web and mobile projects. There were several frontend developers needed for one backender, just because for business apps, backend is usually simple.
Man you and I are familiar with very different "business apps".
I would say in 2025, it has become exponentially more complex, not simpler:
1. The ecosystem has fragmented further. Every app uses even more tools and frameworks, each with its own quirks and version incompatibilities
2. With E2EE and blockchain-based apps becoming mainstream, the frontend now handles complex cryptographic operations, key management, and secure data handling entirely client-side. Mistakes here are security vulnerabilities
3. Advanced interactions, personalization, and real-time updates require sophisticated client-side computation. We're beyond "thin clients"
4. The Big 4 invest $millions in each interface and users expect the same level of UX/UI from anyone. Let's talk about simplicity on the surface :)
> The ecosystem has fragmented further. Every app uses even more tools and frameworks, each with its own quirks and version incompatibilities
I disagree, at least partially. When this article was written, one of the biggest difficulties with front-end development was browser incompatibilities. Front-end developers were deploying to a hostile, inconsistent environment.
Things have gotten much better on that front. Browser support for standards is much better. People upgrade to the latest versions much more quickly. Systems that transcode from modern style to backwards compatible style, like Babel, TypeScript, Lightning CSS, or PostCSS, are commonplace.
The end result is that front-end developers are far more able to target modern APIs and functionality without worrying about compatibilities anywhere near as much. The browser environment has become much more consistent and capable.
Do some developers overcomplicate things with monstrous WebPack configs? They sure do. But the important thing is that they chose that. If you want to keep a super-simple build, you can do that too. You have the choice of how complicated your stack is; you don’t have a choice of how complicated the browser environment is.
> With E2EE and blockchain-based apps becoming mainstream
Blockchain isn’t mainstream, and hardly any front-end developers need to care about E2EE.
> Advanced interactions, personalization, and real-time updates require sophisticated client-side computation. We're beyond "thin clients"
This is marketing speak that doesn’t reflect the day-to-day work of a front-end developer.
> The Big 4 invest $millions in each interface and users expect the same level of UX/UI from anyone. Let's talk about simplicity on the surface :)
What do accounting firms have to do with this?