Can I ask what exactly you're tired of in the frontend world?
Is it constantly having to relearn new ways of doing the same thing, without any tangible benefit? If so, yeah, that really sucks, but I guess that's the unavoidable growing pains of a rapidly-expanding industry with different companies all inventing their own wheels. Have you ever thought about working in a slower-pace field (whether it's a different vertical, or a different part of tech, like firmware, hardware, enterprise backends, legacy business apps)?
Is it having a bunch of competing Javascript frameworks (Next/Nuxt/Gatsby/Netlify) and languages (Typescript, React, Vue, Svelte)? If so, it doesn't really matter, just choose one you like and stick with it and find jobs that use it. It doesn't matter how many more spring up, wait a few years and either the dust will settle or something new will come along anyway, but you can skip all the in-between ones. They are all "good enough" these days, there's no need to let the perfect be the enemy of the good.
Is it the buildchain/toolchain, like webpack and babel and parcel and all that crap? If so, maybe use a bolts-included framework like Next.js that takes care of all of that for you with sane defaults -- that one framework can replace a lot of what Redux, React Router, Axios, Create React App, etc. do, and it preconfigures the common things (Typescript and ESlint) for you so you don't have to tinker with that.
Is it having to clobber together a hundred third-party NPM packages to make a functioning site? If so, well, you can either go bolts-included (something like MUI which takes care of a lot of the mundane UI), or go the opposite direction and make everything yourself. You don't HAVE to buy in to the greater JS ecosystem if you don't want to... most of us are just lazy.
FWIW, just as an anecdote, I moved from fullstack to frontend JS and have never been happier with the simplicity. Yes, the JS ecosystem is absolutely a mess, but at least it's ONE ecosystem with messy components, rather than ten smaller ecosystems trying to coexist. Back in the LEMP days (which wasn't really that long ago...), to be a web dev, you had to know some subset of HTML, XHTML, XML, JSON, SQL, Apache, Nginx, Varnish, SQL, Postgres, MySQL, Maria, Perl, PHP, xdebug, Laravel, Symfony, Ruby, redis, memcached, DNS, HTTP, HTTPS, ssh, VPNs, Linux, systemctl, monit, TCP/IP, iptables, Docker, Drupal, Wordpress, Liquid, jQuery, each browser-specific JS (no ES6 yet), CSS browser prefixes, CDNs, cache expirations, S3, EC2, EBS... it was ALWAYS a mess. But these days so much of it is abstracted away behind frameworks and Jamstack hosts. The frameworks are complicated, yes, but they are shielding you from even more complexity. In like 100-200 lines of Next.js code combined with a headless CMS (or someone else's backend), you can do what used to take ten different frameworks in four different languages. Then you can one-push deploy it to the web and it's automatically CDNed and HTTPsed everywhere... in like a minute. It used to take days & weeks to figure all that stuff out, and every part of it would constantly break under load or whenever someone forgot to update a certificate. These days we mostly take all that stuff for granted, and you can just write UI code and not worry about the rest of the stack so much. THAT should be the joy of modern frontend, to allow you to code for UX instead of against your tech stack.
Maybe, instead of hating the job overall, have you thought about what specific parts of it you actually DO like? If you like the design part, maybe move into UI design? If you like the UX part, become a UX person? If you like the actual frontend coding part but not the buildchains and third-party packages, find a company that already has their own devops and frameworks set up so you don't have to do all that? Or think about doing frontend work in a vendor-dominated space (meaning Apple/Microsoft/Google apps, not web apps) using a different presentation framework? If you like interactivity, maybe games dev? If you like solid engineering rather than quick and dirty UI code, maybe more enterprise backend stuff, or work for a SaaS/PaaS vendor instead of the frontend stuff -- i.e. you don't have to work on end-user facing frontends, but maybe dev-facing frontends like monitoring dashboards or the frameworks themselves or admin panels or whatever. Or are there some special frontend techs/use cases you really enjoyed working with outside the DOM, like Canvas or WebGL or WebAssembly or WebSockets or whatever? Real-time multiplayer sync? Web maps? Edge architectures and serverless?
TLDR (and really sorry that was so long and ranty), one of the incredibly lucky things for us as web devs is that there are a million sub-paths you can transition to without having to entirely reinvent yourself. Just a few weeks/months of learning a new system and you can start working in it, vs other professions that have to spend years back at school just to enter a field. You just have to find your own niche(s) and move towards them rather than letting your employers & jobs toss you about in a direction you don't like. For me, that was getting away from the backend and the rest of the stack, but for you it might be another direction. Good luck...!
Thanks for the great post from a different perspective. I kind of agree with you. But the problem is that there are way too many options for a given task, and it's difficult to evaluate all and zero in on something. I need a small help from you. I am new to web development. After a lot of research, I have zeroed in next.js. I loved the overall design, api/workers integration, deployment using vercel. But struggling to design something from scratch. Also, finding the jsx syntax very complex. (I come from java background). Could you recommend a good headless cms for working with next.js? This is for hoppy project, not for day work.
We evaluated a dozen or so for work last year, and my two personal favorites were DatoCMS and GraphCMS (now called Hygraph). A bit more details in this thread here (https://news.ycombinator.com/item?id=32993835), but basically DatoCMS had a great out of the box editor experience, while Hygraph had a slightly better/more flexible data model and GraphQL mutability. There are a LOT of options out there now though... you can see a big list here (not my site): https://cms-comparison.io/#/card
If I were you, I'd just pick a CMS and try to get started with a demo project. Here's Dato's tutorials for Next.js, including videos and step by steps to start from: https://www.datocms.com/docs/next-js
Once you make a simple prototype in one, you can begin to understand how they tie together with the frontend. And then you can swap out any backend (or any frontend) you like once you understand the nuances better.
As for JSX, I can't really help there because I never learned Java, but it's basically just HTML + Javascript. LinkedIn Learning has a bunch of great videos on how to learn React, and there are free resources out there too (not sure about quality though). At the end of the day JSX is just a templating language that lets you inject JS into HTML. React is more than just JSX and that can get complicated though, so some tutorials might be helpful (or look at the example templates above).
Is it constantly having to relearn new ways of doing the same thing, without any tangible benefit? If so, yeah, that really sucks, but I guess that's the unavoidable growing pains of a rapidly-expanding industry with different companies all inventing their own wheels. Have you ever thought about working in a slower-pace field (whether it's a different vertical, or a different part of tech, like firmware, hardware, enterprise backends, legacy business apps)?
Is it having a bunch of competing Javascript frameworks (Next/Nuxt/Gatsby/Netlify) and languages (Typescript, React, Vue, Svelte)? If so, it doesn't really matter, just choose one you like and stick with it and find jobs that use it. It doesn't matter how many more spring up, wait a few years and either the dust will settle or something new will come along anyway, but you can skip all the in-between ones. They are all "good enough" these days, there's no need to let the perfect be the enemy of the good.
Is it the buildchain/toolchain, like webpack and babel and parcel and all that crap? If so, maybe use a bolts-included framework like Next.js that takes care of all of that for you with sane defaults -- that one framework can replace a lot of what Redux, React Router, Axios, Create React App, etc. do, and it preconfigures the common things (Typescript and ESlint) for you so you don't have to tinker with that.
Is it having to clobber together a hundred third-party NPM packages to make a functioning site? If so, well, you can either go bolts-included (something like MUI which takes care of a lot of the mundane UI), or go the opposite direction and make everything yourself. You don't HAVE to buy in to the greater JS ecosystem if you don't want to... most of us are just lazy.
FWIW, just as an anecdote, I moved from fullstack to frontend JS and have never been happier with the simplicity. Yes, the JS ecosystem is absolutely a mess, but at least it's ONE ecosystem with messy components, rather than ten smaller ecosystems trying to coexist. Back in the LEMP days (which wasn't really that long ago...), to be a web dev, you had to know some subset of HTML, XHTML, XML, JSON, SQL, Apache, Nginx, Varnish, SQL, Postgres, MySQL, Maria, Perl, PHP, xdebug, Laravel, Symfony, Ruby, redis, memcached, DNS, HTTP, HTTPS, ssh, VPNs, Linux, systemctl, monit, TCP/IP, iptables, Docker, Drupal, Wordpress, Liquid, jQuery, each browser-specific JS (no ES6 yet), CSS browser prefixes, CDNs, cache expirations, S3, EC2, EBS... it was ALWAYS a mess. But these days so much of it is abstracted away behind frameworks and Jamstack hosts. The frameworks are complicated, yes, but they are shielding you from even more complexity. In like 100-200 lines of Next.js code combined with a headless CMS (or someone else's backend), you can do what used to take ten different frameworks in four different languages. Then you can one-push deploy it to the web and it's automatically CDNed and HTTPsed everywhere... in like a minute. It used to take days & weeks to figure all that stuff out, and every part of it would constantly break under load or whenever someone forgot to update a certificate. These days we mostly take all that stuff for granted, and you can just write UI code and not worry about the rest of the stack so much. THAT should be the joy of modern frontend, to allow you to code for UX instead of against your tech stack.
Maybe, instead of hating the job overall, have you thought about what specific parts of it you actually DO like? If you like the design part, maybe move into UI design? If you like the UX part, become a UX person? If you like the actual frontend coding part but not the buildchains and third-party packages, find a company that already has their own devops and frameworks set up so you don't have to do all that? Or think about doing frontend work in a vendor-dominated space (meaning Apple/Microsoft/Google apps, not web apps) using a different presentation framework? If you like interactivity, maybe games dev? If you like solid engineering rather than quick and dirty UI code, maybe more enterprise backend stuff, or work for a SaaS/PaaS vendor instead of the frontend stuff -- i.e. you don't have to work on end-user facing frontends, but maybe dev-facing frontends like monitoring dashboards or the frameworks themselves or admin panels or whatever. Or are there some special frontend techs/use cases you really enjoyed working with outside the DOM, like Canvas or WebGL or WebAssembly or WebSockets or whatever? Real-time multiplayer sync? Web maps? Edge architectures and serverless?
TLDR (and really sorry that was so long and ranty), one of the incredibly lucky things for us as web devs is that there are a million sub-paths you can transition to without having to entirely reinvent yourself. Just a few weeks/months of learning a new system and you can start working in it, vs other professions that have to spend years back at school just to enter a field. You just have to find your own niche(s) and move towards them rather than letting your employers & jobs toss you about in a direction you don't like. For me, that was getting away from the backend and the rest of the stack, but for you it might be another direction. Good luck...!