As a JavaScript developer I have a perspective on this. For the common corporate JavaScript developer about 90% of the effort involves putting text on screen. That's literally it.<p>Yes, there are outliers who focus on things like accessibility, security, performance, advanced interaction, SVG, WebGL, and so on. But, that is astonishingly rare. 90% of the effort is just putting text on screen. This is only slightly less true for the average full stack developer because they must dabble in SQL or something else outside the browser, but the goal remains: put text on screen. Even more to the point the software platform, the web and browsers, are almost 35 years old and all baseline to standards that are about 24 years old.<p>When I look at some lengthy corporate bullshit product I often think to myself... I could do that in a weekend. I am right about 50% of the time, but when I am right that weekend project tends to execute orders of magnitude more quickly and be more durable than the corporate equivalent. So... WTF. I promise that I am not a genius and the corporate world is not stupid (not entirely, at least).<p>I have a 15 year career writing JavaScript full time in the corporate world (or 25 year career as a design/front-end developer without programming). By far the single greatest challenge employers face with regards to web technologies is hiring. Most employers have no idea what they are doing when it comes to candidate selection and simultaneously most candidates have no idea what they are doing when it comes to the technology. At the end of the day the employer still needs to put bodies in seats and ship a product even if fragile, defective, and slow.<p>The first time I noticed the "I could do this in a weekend" phenomenon was working as the A/B test experiment developer for Travelocity a million years ago. Our experiment code was throw away code designed to have a life space of anywhere from 3 days to 3 weeks. On one hand we had to write the code as quickly as possible, because it serves a single purpose and then is thrown away. On the other hand it had to be ridiculously durable, because defects introduced by that throw away code would bias the experiment and would harm revenue. As a result this throw away code tended to be written in the equivalent of a weekend and yet regularly executed faster and with fewer defects than the production equivalent that would roll out later. The difference was staggering... WTF.<p>The biggest reason my team could identify for this performance gap were constraints. I was allowed to write my experiment code any way I wanted so long as I wrote it quickly and it was durable. I had no constraints. The production code, on the other hand, was heavily constrained to the existing requirements of the existing application... some enormous Java monolithic nightmare.<p>Most JavaScript code in the corporate world is likewise heavily constrained by bundlers, frameworks (plural), unit test harnesses, a web of configuration nonsense, and so forth. This is both fragile and slower to execute. It is also much slower to write against and more challenging to debug. That is an accepted business risk, because the greatest challenge to the employer is hiring. If all the constraints allow for a wider selection from potential employees the shittiness of it all pays for itself almost immediately.