The problem isn't that JavaScript is a bad language (that's purely subjective), it's that it has a terrible ecosystem and a community that, apparently, is willing to accept very low standards in library and package management.
Two follow-ups if you don't mind: (1) "terrible" in what kinds of ways, and (2) compared to what, specifically? (Genuinely curious.)
Compare to maven in java. Yes, you need to write XML, but it is not that hard, you mostly add <dependency>. And then it just works.
And with npm, I get - this doesn't work with that version of npm (which BTW has a funny versioning that is almost exponential, there are 0.x and x.x versions), but it doesn't say that the version is wrong, it just does not work and you are to figure out why.
More over, npm package locations, you can have three places, in project directory, in home directory and system wide. And to make matters worse you switch between those by using a command line switch. And it breaks, because once you downloaded a package into home dir (accident) and then your packages in current dir don't work, just because - build breaks and you are out of luck. I don't even count how many times I had to remove all npm directories to get rid of some package that was downloaded.
With maven you have simple system, that is constraint and because of that you have much fewer places where it will shoot you in the foot.
With npm (+gulp) you get wild west of package management, just like it was with ant days of java.
And don't get me started on the AngularJS - I thought that I won't see anything that complicated since the days of EJB < 3.
I don't disagree with you though; just saying.
My experience has been the complete opposite. Angular has been best for simple, straightforward apps. The larger the app got, the more convoluted the code grew, and the more I found myself fighting with the "angular way".
Maybe 2.0+ is different. I wouldn't know, and have no interest in finding out.
Web dev has a fast cycle time, mainly (imo) because products are created and used and discarded quickly - lots of websites are short-lived one offs. So, naturally, there's churn.
And as to what my sibling commenter said, I agree. I'm starting to move from angular 1 to 2, and 2 is better. It has some downright amazing features, and the tooling is quite excellent. That's why, personally, I'm learning the new thing.
Angular 4, you mean (or just "Angular").
Of course - it also helps I understand that tech stack enough to efficiently explain it to younger engineers. That said - these three technologies have a LOT of material on the web and consensus on that tech has helped my folks build things "more right" more often, without having to do all the nuanced consideration themselves.
When it comes to X resources, Y time, and Z goals, it's all about the right tool.
I think many people give JS shit because it isn't always the right tool - but people choose it anyway due to hotness/hype/vague advantages.
So I'd agree its a mix of skill, resources, and goal. Arguably another manager with amazing React skillsets could do the same thing with a different stack. I'd love to see that guy in action, especially if he can have a more productive team for the choices.
But for us - most UI Frontends are fancy buttons on backend service APIS, or stupid CRUD. Rails does this with confidence.
We need some sort of js beginner walk through that has a section for each step in the process and explains the solutions and differences between projects.
ex: step 1 is language fundamentals, step 2 dom manipulation step 3 bundlers and why you need them. Step 4 frameworks and libraries to build your frontend. Something like this would be useful but I don't know if anyone is building something like this for beginners :/
So, I learned Angular 1 for a project. Some concept there really are everywhere (promises, DI), but you might as well not even call Anuglar 2 Angular. It is totally different and even getting started in it took so much effort I gave up. I have almost never done that as a hacker. But the sheer amount of stuff to install and learn just to implement Hello World was more than I was willing to deal with at the time.
But after all that, I can see why some people would be frustrated.
Being on the inside and doing js for the past 3 years it's more exciting than looking in. We keep getting new awesome language additions as of late!
In terms of what? Can you please do a npm vs pip and a nvm vs virtualenv?
Thanks
I've had the complete opposite experience. Crates, composer, and npm are my go-to examples of good package mangers. Python is my go-to example for lack of a good package manager.
But I more meant the ecosystem in general:
A "batteries included" language makes me create my own UTC tzinfo implementation so I can get a datetime in UTC... Python's time situation is maddening and by far the worst I've worked with. I'm sure others feel this way because there are a bakers dozen of time libraries trying to fill the gaps.
I almost rage quit the industry trying to save and retrieve a UTC datetime from the database with sqlalchemy. Luckily I found Arrow and ArrowType and that's been working well enough for now.
On the subject of time this has been open for close to five years? https://bugs.python.org/issue15873 . I get the impression that lots of proposed improvements are languishing like this.
sqlalchemy and alembic feel like JUST ONE GUY is working on them. Massive achievement, but the gaps are visible.
The module system feels stale; a holdout of a system from different workflow times. Splitting stuff off into separate files for maintainability(including improving multi-dev workflows trying to reduce conflicts) creates some gross imports.
It feels like there is a reluctance to evolve the language itself; a lot of enhancements appear to be made via more magic metaprogramming and function usage. super(Cls, self).__init__() comes off as an artifact of this. Not really my cup of tea these days, but I can see how this is very subjective.
The propper way to handle generated members with pylint is supposedly a plugin; which almost no projects provide.
Type annotations are supposed to go a long way in 3.x, but the prevalence of metaprogramming and lack of tooling awareness has probably defeated more jedi than Darth Vader.
boto3 has no official async support even though lambda just released support for Python 3.6. Meanwhile the javascript sdk is shipping with TypeScript definitions and a new promise interface.
A lot of this is very subjective(other than perhaps the languishing of certain library areas) of course. To me though, after having worked with a lot of other languages, it just feels like Python is a bit of a ghetto these days. It's like the language world has built north and Python is.. Not living to the north.
EDIT: The pipenv announcement thread has some comments that go into more detail on package/project management situation: https://news.ycombinator.com/item?id=13459740 . sjellis and sametmax touch on most of the stuff I've run into.
[0]https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
I must be getting old and grumpy, but I really am tired of learning 'new' frameworks and ideas unless they actually provide some sort of benefit.
For example, I started using Docker here and there. There's a bit of a learning curve and I initially thought 'how is this all that much different than running a VM or two?' Only later, when a single docker compose file set me up with a full CMS, DB, NGINX, etc. stack did I understand just how cool it was.
To compare, I've spent a few years now on various projects where the front-end guys have added all sorts of bloat - bower, then grunt, gulp, Angular, React, Browserify, JSPM, onto Webpack. Hell, it looks like npm is now being replaced by Yarn - WTF?
And the vast majority of this crap is absolutely no better for the user than the old school MVC server side template apps+JQuery that worked for years.
Recurring amnesia.
It's because the industry (number of programmers) is grower faster than the rate of diffusion of knowledge (experience).
Also, easier communication mediums has greatly increased the noise to signal ratio. So maintaining our BS filters requires that much more effort.