Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think the difference lies is how pleasant the tooling/build process are. In the case of C, Go, C#, and other non-web languages, there are comparatively few gripes — the most common being “building takes a long time” with Rust and Swift for example, which is a fairly mild problem. The negative parts of the experience for these languages more often than not get fixed.

With JS, it seems like many of the negatives are much more sticky and refuse to go away. Not sure why. Perhaps it’s related to how that ecosystem has a tendency towards cyclical reinvention of the upper layers while foundational/structural issues get considerably less attention, and so they get swept under the rug more often than they’re fixed, leading them to rear their heads every so often to remind everybody of their existence.



> I think the difference lies is how pleasant the tooling/build process are.

> With JS, it seems like many of the negatives are much more sticky and refuse to go away. Not sure why.

Spot on. I think there is a quality/cultural problem around the javascript ecosystem, but I'm also not sure why it persists. If I had to hazard a guess, I suspect that it has to do with what javascript programmers are usually trying to build. Those things are mostly visual, and the audience cannot see the quality or lack thereof easily, and outputs do not often live long. These incentives steer people to create fast and not worry so much about the soundness, sustainability, or longevity of their solutions.

I made a comment to a colleague recently that javascript tooling is a 'labyrinth of complexity'. That is my main gripe with all of the 'stuff' that comes with the front end. It all feels overcomplicated and thrown together.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: