| The problem with the JS learning curve is the HUGE amount of StackOverflow and blog posts that are insanely outdated, with no way for the casual reader to check if the question or the answers are actually usable on a modern version. I believe that this, combined with complex, incomplete or outright missing documentation (hello Webpack, though the situation has improved since a couple of months) is something that holds the JS community back very hard - also because people complain all the time to framework authors "the example I c&p d from stackoverflow doesn't work" and answering these complaints takes nerve and time. The PHP community suffers from the same fate, btw - remember mysql_*? People still find it in the top 10 Google results for some questions. The only environments that have managed to resist this problem are Win32 and the userspace part of the Linux Kernel. In a lot of cases one is able to even open a VC6 project in a modern Visual Studio, have it converted and building - or at least just having to mess with the VC build process, but thanks to a hell of #ifdef's, the Win32 code still builds - and runs! For what it's worth, I can run Windows 95-era EarthSiege 2 on a 64-bit processor and the only things broken are the joystick input (by disassembly I believe the responsible code suffers from a bad version check on a struct) and some timer that binds a specific movement to the framerate and naturally overspeeds as a modern system can easily hit 100 FPS. Same holds true for the Linux kernel, it's amazing that a statically compiled game like UT2004 still runs on a modern day Linux system. In contrast, JavaScript - "npm install <whatever>", as many tutorials describe, is likely to already give an incompatible (with the instructions) package when the book finally gets printed. I have the feeling that like with libraries, major versions should always be backwards-compatible for their subversions, and have different NAMES for their major versions, e.g. "npm install angularjs1" vs "npm install angularjs2". |