Yes, but if only the tooling was too complicated, it would not be too bad. IMAO the entire front-end JS world is one big pile of MISERY, complicated is not the word or the problem at all.
Not 1 year you can write the same kind of code (professionally), every month new libraries you have to use, always a new framework or cloud service on the horizon, always a new hype in the making. And if all the new things in the JS world would be great solutions it could be awesome (maybe). But the reality learns that it only gets more complex and tiresome every day. Juggling with design patterns, not because they are a better solution than the design pattern you were using before, no, it's because some famous JS artist came up with an 'idea' and the entire JS herd is following it blindly. Think you can still write in the old fashion? Nope, PR declined! You protest? Beware of the company politics, the herd always wins.
Oh btw, I guess the title is inappropriate, JS is deprecated, it's Typescript now! Not sure for how long, but the jobs where you can write JS are disappearing. So web developers are now forced to write in another language, with all it's brand new issues and pain points. Nice! Did I have problems with types in JS? Hardly, but that doesn't count, I now write about 20% more code to get the same result and regularly spend a few hours to get a basic line of code working because the TS compiler complains. It goes on and on, really, unbelievable.. Web development took all the love I had for programming away.. And I acknowledge it is a great recipe for burn-out, if you fancy that.
I originally came from C++ and recently went back to it after 8 years of web development. I totally unexpected rediscovered my joy for programming. I can code things again that actually work and are understandable, without all those black boxes of magic that are pure hell when something goes wrong. I gave up on it, it's not for me.. But still, I can imagine when you're young you can kind of enjoy the JS(TS) world with all those new and exiting things.
Also originally from C++, now been working with the likes of React for about five years. After grappling with Redux, React Router, Immutable, Typescript, Flow Typing and a hundred other libraries, my solution was to go back to basics: build applications with vanilla JS, using a bare minimum of libraries and a lot of standard browser APIs. In my case, basically React only. How do I do client-side routing? addEventListener('hashchange'). Type safety? Unit tests. Mapping actions to components? onClick: dispatch(new CustomEvent('foo')) etc.
Edit: Parcel for module bundling and transpile, but I'm waiting for JS native modules. Eventually React too, will go away in favor of Web Components.
I remember a time when jQuery was considered so standard that every StackOverflow question about "How do I X in JS?" had as the top voted answer "Use $X() in jQuery". All that accumulated knowledge is now essentially a graveyard. I feel React too will be supplanted by something more closer to a WHATWG standard in the future.
But jQuery was just syntactic sugar on top of a broken API. For all intents and purposes, React _fixes_ HTML and DOM. The reason we _have_ such complexity in the front end these days is because _we can_. We've eschewed all the bullshitty parts of web development (global styling, unpredictable browser APIs, hand-holding DOM through complex interactions) and opened ourselves up to actually writing applications.
The problem, as I see it, is front end developers are still expected to churn out features like they used to in large scale organizations, but we've matured as developers. It's no longer throw a .js file, a .css file and an .html file at a browser and woo hoo you have a site. It requires more time and bootstrapping, but the promise is code that breaks less often and is easier to maintain. It also means we have front end developers that are now specialists in different facets of frontend, such as builds, data layer, typing, feature development and framework design. Notice these are meta jobs.
In order to meet the demands put upon us by our former velocity, we often have to resign ourselves to blackbox libraries and such, which don't always contribute positively to one's stack. Just today we ditched a node module we'd been using because the owner refused to update it. We should be building more internally than we do.
React in itself is a simple (and ugly, if you ask me) templating library. The real mess comes with the many libraries around it.
The worst offender for me are reactive stores. I'm reviewing a simple candidates' programming assignment (in Angular, though). There is a simple taks to perform. The horrendously complicated and generally broken ones are those where the candidates decided to use a reactive store. Just tons of unnecessary code impossible to follow and decipher.
> every month new libraries you have to use, always a new framework or cloud service on the horizon, always a new hype in the making
Did your job actually make you switch frameworks or use new libraries every month? Or is this just a trope you're repeating. That's not a problem with JavaScript, but a problem with your management.
And BTW, there are three big frameworks that are all like 5 or 6 years old. React isn't exactly new.
> Think you can still write in the old fashion? Nope, PR declined!
I read posts every day where people talk about JavaScript's horrible language design. Now the language is expanding and solving a lot of those problems, all while maintaining full backwards compatibility, and you're complaining that it changes too often? The last major language update was in 2015, and everything else has been an annual gift of a couple of new features, all of which are developed with the input of the community, and you're still complaining?
The truth is, a lot of people are using JavaScript and it's very flexible, so, yeah, people come up with design patterns all the time. Some of them are good and stick. Some of them are not. But part of the fun of being a JS dev is you can choose to explore that or not.
> JS is deprecated, it's Typescript now!
TypeScript isn't my thing, but again, people are constantly complaining about JavaScript for not having classical language features like strong types. Then an alternative comes out, and is embraced by a large portion of the community, and again with the complaining! Just don't use it! And BTW it seems bizarre to complain about TS being too verbose when you are a C++ dev.
I'm not saying you can't enjoy C++ but your reasons for hating JavaScript just sound like repeated tropes. If you get better at the language (and this applies to TS too), it will stop being so opaque.
Respectfully, I think it's unfair to say these are straw points. Perhaps there is some hyperbole in suggesting you need to use every new framework. You really do not. But as devs we are highly encouraged to stay abreast of these sorts of shifts. The industry is always in motion, and modern JS can be particularly brutal. In fact, ECMAScript itself recently moved to a much more rapid release cycle.
The market, if not your particular company, requires that you know the latest iterations/tooling of your chosen framework. Even if you're not forced to use the very latest versions, just being aware of all of that movement has cognitive overhead. If you choose not to pay much attention, you can quickly fall behind the curve. There is an inherent anxiety to that reality, whether it's legitimate or not.
Multiply the number of different tools in a given stack by the frequency of major updates to each, breaking changes between different tool/plugin versions, and you can start to grasp why people often complain about FE dev. These tropes are repeated for a reason.
> I guess the title is inappropriate, JS is deprecated, it's Typescript now! Not sure for how long, but the jobs where you can write JS are disappearing. So web developers are now forced to write in another language, with all it's brand new issues and pain points. Nice! Did I have problems with types in JS? Hardly, but that doesn't count, I now write about 20% more code to get the same result and regularly spend a few hours to get a basic line of code working because the TS compiler complains.
Typescript is a superset of JavaScript and your type issues could just be because you lack understanding of how type coercion works in JS. Additionally your tsconfig settings could be overly strict.
I had a similar experience when switching from JS to Dart.
I am not using any framework just plain old DOM as my projects tend to be smallish.
But programming in Dart is a real joy.
> Not 1 year you can write the same kind of code (professionally), every month new libraries you have to use
Huh, that's weird, because I've been writing in Angular & React and using the same basic libraries for years now. And before that it was jQuery and Handlebars and a lot of the same basic libraries for years.
I've made two large shifts in JS development over a decade.
Not sure why you seem to need to switch every month?
What I'm hearing you say is that the rapid increase in flexibility of choice within the JS ecosystem has a tradeoff of enabling dilettantes to further muddle the mixture.
I would argue that we should not be intentionally relying on technical design decisions to bust through difficulties which are more related to human factors and office politics than software architecture or implementation.
I use server side generated HTML pages with progressive enhancement using JQuery (I prefere it to plain Javascript). Not complicated and works very well.
I would argue this actually is popular - I've come across it on most projects I've been contracted to work on. Clients often defend their choice, saying react/vue/angular/webpack prevents them from 'just getting things done'. It's funny because they worry they're in the dark ages, but in reality many young and old projects alike are still using this approach.
As for being cool, my opinion is that shipping stuff is cool, and if your project is maintainable that's very cool no matter how you do it.
There are a million cool camping gadgets out there... Before I go out on a trip I take a sec to figure out what I'm doing on this trip, and what I'm gonna need. A lot of cool gadgets get left on the floor because they're totally irrelevant.
It's odd that we're coming up on 2020 and software projects checking their dependencies and overhead against their goals is still seen as a matter of fashion. KISS isn't sexy, and doesn't sell consultant hours. Those are features, not bugs, IMO.
I use the latest and greatest React at my work. It is definitely better than jquery, some of the stuff I can do in 100 lines and how clear it is to me is impressive (React hooks are awesome).
I have a ton of worry about other devs, especially ones with no React experience walking into my code though.
With jquery it is totally reasonable to expect anyone who calls themselves a front end developer to have a working understanding of it. Can’t think of any other JS framework that can boast that.
Most of my JavaScript these days is little interactive things embedded in web pages, and I use raw JavaScript. All the stuff I used jQuery for back in the 1990's is in the language and DOM API now.
They generally have the form:
document.addEventListener('DOMContentLoaded', function() {
var m = {
...model fields...
_observers: new Set(),
notify: function() {
this._observers.forEach(function(observer) {
observer();
}
}
};
var elem1 = document.getElementById('...');
elem1.addEventListener('...', function() {
...update fields on m...
m.notify();
});
m._observers.add(function() {
...update elem1 from m...
});
m.notify();
});
...am I going crazy? There was a library with the $ that we used in the late '90's to handle cross browser issues. I thought it was an early version of jQuery. What was it called?
Nope, you're not... everyone seems to forget the decade of 2000-2010 when calculating any dates nowadays. It's like that old saying... Remember kids, 1990 was 28 years ago, not 18.
In practice, a lot of complexity in front-end development comes because front-end developers only solve problems by adding layers of abstraction, never removing them.
Like, in vanilla JavaScript, you have a single global tree representing the state (the DOM), and you write event handlers that manipulate that tree. But that isn't a good fit for every use case, so you introduce React, which encapsulates all your functionality into components.
But that turns out not to be a good fit for every use case, so you add a state-management library like Redux on top. With Redux, you have a single global tree representing your state (the Redux store), and you write actions that manipulate it.
Congratulations, you are now back where you started, but you've introduced two third-party library dependencies (probably more, if your libraries need separate adapter libraries to work with one another) and a bunch of overhead and complexity.
See also: client-side navigation. "Pages on my website load slowly because the browser has to run all the JavaScript I wrote. How can I solve this? Oh I know, even more JavaScript!"
I am proposing that, in many cases, data is trivially representable as document elements. Lots of websites don't actually have much state to store -- at least in terms of the front-end developer's idea of state, of course you often need a database and user sessions and stuff -- beyond what's currently being shown on the page (and occasionally display:none'd, reordered, or scrolled off-screen).
"State management" is a problem you think you have only because you're trying to use React for things it isn't good at.
Why not storing local state in the components themselves? Why do you need global state management at all, except for the very rare cases in which many totally unrelated components need to tap into the data?
Because some complex application have multitude of variables that need to be passed along various components and that's exactly what is doing redux. In these cases it is much simpler to work with the tools that the community built, and as soon as you actually understand how redux and connect work, you are usually rather happy about what it does for you.
Yes. I think that some applications, with multitudes of variables that need to be shared between unrelated components, will benefit from a store that manages only those variables.
For all the other cases, I don't see any reason to use one, and my experience of the same application developed, by different people, with and without a reactive store, tells me that the solutions without a store are generally much simpler and look way more maintainable.
Many GUI programs use components to store data instead of using them only for display, but this eventually means that your program's state is contained in lots of different data structures with different ways of accessing them. Having everything centralized yet organized enables managing a lot more complexity.
I don't understand, it seems you could say the exact same about object oriented programming in general. But encapsulation is a feature- it allows you to expose to the rest of the application only the data that really needs to be exposed, through a well defined interface. It allows to compose applications of parts that are completely self-contained, without having to think of their interaction with the entire application. I get that in some cases you might need components to plug into a global state that can have multiple sources of change, but this is more an exception than the norm.
This might the conventional wisdom, but the reality is that in a single thread, hiding data behind all sorts of obstacles is a huge detriment. If you can already get to it, you might as well be organized so you can get to it easily. 'object oriented programming' (whatever it means exactly) is good for creating interfaces to data. The GUI might need an interface to its data, but the state of whatever is being processed and manipulated is less likely to need a special interface and almost definitely not whatever a component meant to display data provides.
If you 'encapsulate' every tiny bit of information inside GUI components you end up with things like storing a string in a GUI label or storing a list in a list selection component. Then every time you want to access that information you have to extract it from the GUI, possibly keeping in mind the lifetime of the UI components.
It has long been my conviction that tech stacks like React are necessary and/or seen as good because the frontend is trying to solve overly complicated problems. All of those framework-du-jour praises sound to me like people have found The New Great Tool for building a Tower of Babel¹.
Just, you know, have simpler problems?
SoC your stuff, solve the 80% instead of the 99%, challenge your assumptions about what you need and you'd be surprised how little complications you can get away with.
¹ one common tool in the pipeline actually being called babel never fails to amuse me.
> tech stacks like React are necessary and/or seen as good because the frontend is trying to solve overly complicated problems
I think a lot of these issues are symptomatic of front-end oriented toolkits trying to solve combined frontend and backend issues, causing oodles of arbitrary complexity.
It's hugely beneficial for some kinds of projects/teams, but so much of the challenge is simply due to domain impedence and using suboptimal tools for the job. Client-oriented solutions to server-client issues have some fundamental limitations.
Instead of jQuery why not use a more minimalistic reactive library like Vue.JS?
Using jQuery will just make you suffer in the end. You end up having to write loads of code to manage the state of the DOM and it just gets more complicated as your project expands.
Modern JS is a dream to work with. The days of pre-transpilation and modularization with hundreds of script tags and giant IIFE's and worrying about cross-browser was a total mess. It finally feels like the web has matured as an application platform and I've been waiting for this day for a long time.
I could understand what was going on before transpilation. There was just Javascript, and while some functions might not exist in different browsers, the core was the same.
Now I have to figure out the difference between: ‘umd’, ‘commonjs’, ‘esnext’, ‘es2015’, ‘es2018’, and a whole bunch more.
I don’t want to keep up with JS politics just to be able to develop with the latest version.
Just about the time Chrome and Firefox came out with working debuggers for JavaScript, everybody rushed onto non-debuggable bandwagons, so we’re back to the bad old days of using “alert” to debug...
Blanket statements about "web development" are not reasonable to make because there's such a wide variety of applications.
Is using TypeScript, Webpack, React, and 20 other external libraries "too complicated" for a static marketing site? Probably. For a 200,000 LOC complex productivity tool? Probably not.
Seriously, it's just poor professional discretion. I work on a cross-browser multimedia sequencer, no fucking way you're hand writing all necessary DOM management code. You absolutely need React for that to prevent that kind of shit show. This custom video player project the team got assigned? Probably can write those on our own. To be fair though, framework and library marketing tends to be fairly disinterested in talking about suitable and unsuitable problem cases. I don't think that's completely intentional, but front-end tends to have more engineers with non-CS and other untraditional software education backgrounds in situations where they feel pressure to "get shit done"
But most other languages only provides up to Grunt and Gulp equivalent, namely Gradle, Fake etc.
As who had maintained large Gulp scripts, those Scripts would eventually become a huge pile of non-standard and ad-hoc scripts.
Webpack is complicated, I admit. But it's much better than Gulp I my experience, so why is everyone complaining?
It turns out the problem Webpack or JavaScript solves are more complex than other language solves. JavaScript is the center of the Web, you cannot expect let CSS bundling itself, so do images and fonts. Let alone compression, prefixing, and giving fonts and stuff size thresholds to in-line them in JavaScript.
There would definitely better tools in the future like Parcel and Pika are trying but the problem doesn't go away.
I'm looking forward to see other languages facing the same issue in WASM age.
JavaScript itself has a complicated, hairy history. It's hard to write a single line of code without wondering, must I query https://caniuse.com to be sure this API is supported by all of my organization's targeted browsers? It shouldn't be all that surprising, that in order to rectify the lack of parity, we have to accept come additional levels of complexity in our tooling.
Sure, I could import all of corejs and call it a day. Everything would be polyfilled, but then I'd be wasting precious bytes and negatively impacting page load times. Some will even say the concern is no more than bikeshedding. But if you give little thought to bundle optimization, your carelessness will add up, and materially impact TTFB. It's a death by a thousand cuts.
My personal answer is no. Whether it's Stockholm Syndrome or not, you can conquer the complexities of shipping web applications written in modern JavaScript.
Becoming aware of the nuances has made me a stronger developer. Developing a deep understanding of polyfills, bundlers, transpilers, module formats (CJS, SystemJS, UMD, ES Module) and which browsers support which APIs has made led to me being more thoughtful in the code that I write. For people just looking to solve a business problem, without understanding the more tedious parts of JavaScript, it absolutely is too complicated for them. I empathize. But if you want to be a skilled front-end software engineer, it's in your interest to tackle these tools with some zeal.
> But if you want to be a skilled front-end software engineer, it's in your interest to tackle these tools with some zeal.
I guess what we are saying is that there must be a better, not yet invented way to do frontend, without having to deal with this huge complexity that is unique to this specific field.
Seeing a lot of hate here for modern JS workflows. The truth is you can make a mess no matter what ecosystem you buy into. I’ve encountered some absolute trash fires of complexity in Java, PHP, C, and (yes) Javascript code bases. They all suffered from the same problem: lack of communication and planning. This is a framework agnostic problem IMHO.
Different perspective: In Java, PHP and C (I've worked with each), comes very close to "no assembly required" to get a simple project running: install, write code, optionally compile and then run. In JS, unless you're doing vanilla JS, you need to select and bolt together a lot of different third party tooling first, or you have to use a boilerplate, of which there are many versions to choose from.
> In JS, unless you're doing vanilla JS, you need to select and bolt together a lot of different third party tooling first, or you have to use a boilerplate, of which there are many versions to choose from.
That might have been true once but its not anymore. Assuming you have node installed, its a one liner to get started in React[0] and Angular[1].
I've found that many of the criticisms of the modern JS stack come from outdated views about the ecosystem (no offense intended). I'd encourage you to give it another try (especially TypeScript) It's matured quite a bit.
definitely - having recently started working in Java it's far from "no assembly required" for certain things but feels _much_ more sane the types of problems I'd encounter in web/mobile dev land
- there are too many ways to do something: it's hard to understand patterns (they change with every framework, for example), many different standards that aren't compatible with each other.
- javascript delays failure and fails silently: it makes software prone to bugs as well and it also makes the language hard to debug.
NodeJS, npm, yarn, millions of frameworks and libs just add complexity to the language.
All of this can be addressed with best practices. Just enforcing lint rules can mitigate the majority of your complaints. Flow and Typescript can take that even further. Webpack will streamline your process.
My primary complaint would be that working in Javascript is absurdly difficult for the beginner. It's ridiculously hard to understand the fundamentals when they have been a moving target since the early 2000's.
I don't agree with this. Over the last few years I've watched the JS universe coalesce largely around three points:
- Structural, optional typing is good. Use it. TypeScript seems to have de facto "won", but just use something; the very act of thinking about input and output types tends towards better code and you always have the flexibility, within your module boundaries, to go outside the type system if need be.
- Structured, functional-or-mostly-so view libraries make your system less fragile. Use them. React, Vue, whatever. They discourage your developers from making tag soup; this is a good enough reason. (Yes, there are some people on the "vanilla JS" train, but there are reasons it's a minority group--it's harder, you run the very real risk of making a worse thing, and there's less out there to bail you out if you get yourself into a corner.)
- Do the work up front: lint aggressively, format consistently, run coverage tests, and so on. It's an investment in correct code, and get in the habit early.
What you use matters less in putting into effect good practices. Why you use it and what they do matter much more.
I'm afraid the "javascript sucks" meme has taken hold. The infection is terminal now. At least, in the minds of most developers judging web development from the outside.
I mean, from the outside I get it. For a very long time I avoided frontend jobs because JavaScript did suck. And I'd say that JavaScript-as-it-was--not writing ES6, not polyfilling browsers, not using a sane framework--sucks today.
These days I write pretty exclusively NestJS serverside and React/React Native on clients, using TypeScript through the whole stack and Swagger-generated clients for plumbing, and it definitely no longer sucks. But I had to 1) have a reason to get into it, and 2) spend a ton of effort to weld together a consistent environment that values developer time.
There probably is too much nonsense going on at any one point in the JavaScript ecosystem. I mostly work in infrastructure/devops roles, where it's just expected that you know ten thousand little things that are arbitrary and stupid but will eventually bite you; having to hold an entire stack in my head and understand how to pivot and manipulate it is kind of what I do everyday, but it's not a standard programmer skill. If you don't have somebody who can do that--and it's a mixture of human communication and empathy, technical skill, and a certain kind of technical taste, so it's not as common as one might like--I still, today, see why somebody might say that JavaScript sucks.
We decided about a year ago. So I spend a year writing side projects in React and Redux. In the meantime, a new dev was hired to begin writing the React/Redux code. I just jumped into his code today and tried to add my own stuff, and I feel like I'm learning programming all over again, because it looks like absolute gibberish compared to the code I had been writing on the side.
So even if you are using React and Redux, you can write code that has virtually no resemblance to another repo.
I think there are a lot more barriers to entry, in terms of if you haven't worked in JS much previously. Meaning, pre-Webpack/Babel/ES6 Modules etc, it was just JS and so newbies could learn JS and then go from there. Now, there's a bigger learning curve in the initial stages, I believe.
Honestly. I used to build the buildmaster for Ant builds back in the day. They could actually be quite incredibly elegant (if you used Ant-contrib). The reason was actually a lack of magic. SURE, ant was very verbose compared to modern build systems, but it did a lot of things relatively straightforward. You invoke tools in the chain you want.
Today it is very different. There is a huge chain of auto-wiring tools with very cryptic error messages. To just build a basic ES6 javascript webpack project with React I need over 800 libraries, many of which are automagically invoked via convention.
I literally have no idea what my build does, and hope my lucky underwear actually works today. Most of the time I am browsing through weird bug reports trying random snippets on the internet because there's no sane way to debug anything.
So the point is, explicit is a huge virtue. It is code you can trace and debug. Sure it adds a bit of time, but it is time up front that saves A LOT down stream. Meanwhile today's tools are built to save time up front and waste time downstream. You either follow the exact formula the original developers wanted or you're shit out of luck.
Everything terrible about the front-end is a consequence of scale and demand for warm bodies pumping out code that targets the world's largest networked application runtime: upper- and middle-management everywhere exerting downward pressure to ship for the cheapest rates facilitating code bootcamps, etc to pump out more non-traditional CS educated labor, meaning less shared generational communal knowledge that normally standardizes names for things like patterns, etc. Devs are thus even more interchangeable and we see less opportunity for mentoring, yet another means of transferring generational knowledge (and software engineering is _not_ a science), and people regularly leaving companies after 1 - 5 years. None of this really has anything to do with the question of whether JS tooling is too complicated save for the implication that professional _discretion_ has less and less reason to be cultivated - grab a framework/library and glue it together to meet the deadline that isn't a deadline but it's actually a deadline
Most young Javascript devs have no experience of hacking "DHTML" for Netscape Navigator and sundry incompatible versions of IE back in the late 90s. That was the real low point of front-end development. Nothing comes close to those life-sapping days so enjoy the immense resources you have today, particularly evergreen browsers following a standard.
And yet, with a little thought, we could use those hard-won compatible apis more directly, and for the vast majority of websites, write less code, configuration, etc.
But we still act as though the very basic DOM functionality is some arcane art that has to be "fixed" by a library like jQuery, or as is more common now, an entire stack of large tools.
Having done paid work with React-stack apps, and personal projects with vanilla JS, I still see more advantage with less code on the vanilla side.
I agree that a lot of mainstream tooling and frameworks are too complicated.
But there are simple tools out there for building your typical business applications. Stateful apps with NodeRun.com (https://noderun.com/docs/concepts/stateful-apps) make development similar to what VB used to be like back in the day (but for JavaScript). There is a Visual drag-and-drop designer for the UI and inherent database integration. I find that building normal database-driven apps is 10x easier compared to rolling your own HTML, CSS, React, Angular, Express, etc.
The answer is simple: Don't use a tool if the benefit doesn't outweigh the cost. Also, only use tools that are "market leaders" in their segment. So that there will be plenty of fixes/tutorials/help available to get you over bumps on the road.
Not 1 year you can write the same kind of code (professionally), every month new libraries you have to use, always a new framework or cloud service on the horizon, always a new hype in the making. And if all the new things in the JS world would be great solutions it could be awesome (maybe). But the reality learns that it only gets more complex and tiresome every day. Juggling with design patterns, not because they are a better solution than the design pattern you were using before, no, it's because some famous JS artist came up with an 'idea' and the entire JS herd is following it blindly. Think you can still write in the old fashion? Nope, PR declined! You protest? Beware of the company politics, the herd always wins.
Oh btw, I guess the title is inappropriate, JS is deprecated, it's Typescript now! Not sure for how long, but the jobs where you can write JS are disappearing. So web developers are now forced to write in another language, with all it's brand new issues and pain points. Nice! Did I have problems with types in JS? Hardly, but that doesn't count, I now write about 20% more code to get the same result and regularly spend a few hours to get a basic line of code working because the TS compiler complains. It goes on and on, really, unbelievable.. Web development took all the love I had for programming away.. And I acknowledge it is a great recipe for burn-out, if you fancy that.
I originally came from C++ and recently went back to it after 8 years of web development. I totally unexpected rediscovered my joy for programming. I can code things again that actually work and are understandable, without all those black boxes of magic that are pure hell when something goes wrong. I gave up on it, it's not for me.. But still, I can imagine when you're young you can kind of enjoy the JS(TS) world with all those new and exiting things.