I have a nagging feeling that server side JavaScript will soon become the new PHP. It is getting more and more popular among not-so-good programmers, and given its loose syntax I think it will lead to disastrous code. Not to mention that ECMA is working toward ADDING new feature to the language instead of deprecating some obscure ones, which would make the language easier to use.
Of course, PHP makers made their share of mistakes with their decisions - register_globals, safe_mode (which was not), inconsistent function naming in standard libs, myriad of weird bugs (like syntax error (still) throwing HTTP response 200),...
> Not to mention that ECMA is working toward ADDING new feature to the language instead of deprecating some obscure ones, which would make the language easier to use.
We'll see what happens longer-term. Certainly until recently the focus has been on the web (and deprecating features on the web is rather pointless: the web still supports things that were deprecated two decades ago, as dropping support breaks sites which makes users change browser or stick with an older version).
There's plenty of things listed in Appendix B of the spec, "Additional ECMAScript Features for Web Browsers", which contains much of the worst parts. Perhaps more will move there in the future, or to some separate section of previously-standardised-but-now-optional features.
As a fan of node.js, I'm afraid you are probably right... and not just front end guys. Some of the most horrific JS code tends to come from (imho) "enterprise" C# and Java devs... there are some patterns you just do not need to do in a dynamic language environment... and only complicates things for no real gain.
There are some really beautiful patterns emerging in the JS community though. React (mercury and others), Redux, RxJS, Koa, etc... But it takes a different kind of discipline to break up modules, and write pure functions instead of relying on typical OO paradigms for systems development. I cringe every time I see a senseless/useless DI/IoC system in JS that adds nothing but indirection and complexity (looking at you Angular).
If you're doing node-style (cjs) modules, you can use something like proxyquire[1] with testing to inject dependencies without complicating your modules, or creating logical indirection. If the only reason you have DI is for testing in a scripted platform, you're probably doing something wrong.
You can write, compose and composite plain objects and pure functions in JS modules that can be tested very easily without resorting to complex DI systems (with naming disconnects even).
Of course, PHP makers made their share of mistakes with their decisions - register_globals, safe_mode (which was not), inconsistent function naming in standard libs, myriad of weird bugs (like syntax error (still) throwing HTTP response 200),...