4 ms·

While there are some good ideas brought up in this post, in my opinion, author misses the main point about JS and, JS fatigue, which leads to the vague advice l

by divan 8y ago

While there are some good ideas brought up in this post, in my opinion, author misses the main point about JS and, JS fatigue, which leads to the vague advice like "solve problems". The point is, as Fred Brooks put it, in software there are two kinds of complexity – essential and accidental complexity. First one – is exactly those "problems" author talks about – it's the complexity of the real-world problems we try to solve with software. Second one – accidental complexity – is the complexity we bring into the process by using our tools, frameworks and languages. And JS ecosystem is largely revolves around accidental complexity. Let's be clear – JS is a historical accident that, by unpredicted twist of events, became the only language in the unexpectedly dominant platform – web. We, developers, did not have choice – if we need to reach users/customers via web – we were forced to use JS. Language, poorly designed under the pressure in 2 weeks, coupled with incredibly sloppy and constantly changing technologies like DOM and CSS, accidentally became the only way your business can reach users. Of course, people started to solve those problems of the JS/DOM/CSS poor design, by creating more tools, more frameworks, more solutions – bringing more accidental complexity, which required new hacks, tools and solutions to solve that. The process then repeats itself, as web world was changing and growing. Accidental complexity in JS world is astronomical. But the worst thing is that newcomers, unable to see perils of that through the prism of experience, accept it as a normal state of things. They embrace this madness and happy to write more hacks and tools, for solving problems, created by other tools. The whole JS ecosystem thus is a huge mess of hacks on top of hacks. Most of developers' time is spent in not "solving the problems", but dealing with tooling and accidental complexity. And that's exactly what software engineering should fight with. But it's really hard and challenging task. As Edsger Wybe Dijkstra said in 1984: “Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.” So, I think JS fatigue is exactly what happens when you find yourself inundated in accidental complexity and ugly designed tools and frameworks.

commandlinefan 8y ago
It doesn’t help that these tools are very terribly documented, and changing all the time either. I learned AngularJS a few years ago. I didn’t learn it because I had a specific problem I was trying to solve and I needed a “framework” to solve it - I learned it because the team I was on was using it, and I had to learn it to be productive. And they didn’t use it because they had a specific problem to solve and needed a “framework” to solve it - they used it because it was trendy and had some press around it. So nobody actually understood what it was. Not just in the “how do I do _x_ in Angular” sense but in the “why does Angular even exist and how is using Angular better than using nothing at all?” sense. I couldn’t admit that it didn’t make a lot of sense to me, because they were all pretending that they understood it (which I only verified later, after I actually did understand it, that they didn’t), but I could read the documentation. It was awful. There were a couple of online tutorials that stepped through some incredibly trivial problems that could be much more easily solved with plain-old Javascript. I picked up a couple of books that weren’t much better (and lost weeks reading them). I finally ended up mostly just reading through the codebase to make sense of it and when I finally figured out really what Angular did and what it was for I realized that the reason nobody ever explains that is because it sounds so trivial, although it’s actually fairly important.

by divan 8y ago

commandlinefan 8y ago

It doesn’t help that these tools are very terribly documented, and changing all the time either. I learned AngularJS a few years ago. I didn’t learn it because I had a specific problem I was trying to solve and I needed a “framework” to solve it - I learned it because the team I was on was using it, and I had to learn it to be productive. And they didn’t use it because they had a specific problem to solve and needed a “framework” to solve it - they used it because it was trendy and had some press around it. So nobody actually understood what it was. Not just in the “how do I do _x_ in Angular” sense but in the “why does Angular even exist and how is using Angular better than using nothing at all?” sense. I couldn’t admit that it didn’t make a lot of sense to me, because they were all pretending that they understood it (which I only verified later, after I actually did understand it, that they didn’t), but I could read the documentation. It was awful. There were a couple of online tutorials that stepped through some incredibly trivial problems that could be much more easily solved with plain-old Javascript. I picked up a couple of books that weren’t much better (and lost weeks reading them). I finally ended up mostly just reading through the codebase to make sense of it and when I finally figured out really what Angular did and what it was for I realized that the reason nobody ever explains that is because it sounds so trivial, although it’s actually fairly important.