While I agree with everything you have said, and it's been my motto since I read, "I'm sure you're joking, Mr. Feynman." The point of the post was to point out (maybe I did it wrongly) that those things you have described are pretty impossible given the ecosystem we have nowadays in Javascript (as a whole!). Of course, you can try to theorize and try to get a hypothesis on things and then try to prove those, but it's just too hard to keep track of everything.
In addition, we are using lock files and good practices but it's just too much to handle for our small team (small startup) so we will plan to migrate onto a more stable platform.
It's really funny the heated arguments this post generated but I have been using Javascript for 12 years to these days, still this looks as a nightmare to me.
Tsdoing has a good video trying to install React from scratch, that's exactly how I felt during this debugging process
Another random story from this week: we have been using `nanoid` to generate IDs internally for an internal tool. Apparently, they did a breaking change release, and now you cannot use it anymore on commonJS env. See my point? where's the hypothesis we can make? It's hours and hours spent tinkering with code and other people's dependencies, and if, as you said, put a theory that theory won't match if you think how real systems work (the networking section on the blog post)
> The point of the post was to point out (maybe I did it wrongly) that those things you have described are pretty impossible given the ecosystem we have nowadays in Javascript (as a whole!).
That's the thing, nothing you have asserted as impossible actually is as you'll see throughout this thread. I have been writing JavaScript/Typescript professionally since for about the same amount of time and I am not intimidated or challenged by my projects in the way you lament about.
That being said, if you've been at it 12 years and this is still your opinion, fair enough, try something else then.
You don't have a mechanism of trust in Javascript. Typescript up to this point is just sugar syntax. npm is a dumpsterfire (see npm everything package)
If you are not intimidated by the complexities of this Babel tower, it's up to you. For me, this was just a personal catharsis in my personal blog that I wrote mostly for me (and I didn't share it here)
I believe there's no point on discussing this with particularly you since you have been commenting all around trying to just confirm your view instead of just comprehend that this is not sustainable for new developers (try to follow the conversations on packaging, lol)
It's simply too much burden just to maintain someone else mess. We will pay a high bill in the future for all of this.
> I believe there's no point on discussing this with particularly you since you have been commenting all around trying to just confirm your view instead of just comprehend that this is not sustainable for new developers
I don't need to confirm my view at all. Advocating for one's view doesn't imply a lack of conviction, rather the opposite.
No need for a personal attack here. It's definitely sustainable for new developers who learn the stack. It has a learning curve but so does everything else. I've built applications in just about every stack there is (except for the more esoteric stuff like OCaml, Erlang, etc) and over those years complaints like those you raised are easily levied against any language or stack that is practically used in the industry. The common thread is that these sorts of complaints arise when there are more unknowns for a developer than knowns-- and as developers we are in the business of eliminating unknowns. When you encounter unknowns and your response is "this is why this tool isn't fit for use" instead of "let me turn unknowns into knowns", this is often the result.
> (try to follow the conversations on packaging, lol)
There isn't a packaging system out there without complications, but my posts regarding NPM's behavior points to how it actually already works to reduce or eliminate the version pinning failures you appear to have hit. Now if you are using very old versions of the tooling or if you do things like remove or ignore the version pinning tooling and how it should work, then yes the kind of problems you hit can happen. But that does not mean this problem isn't already solved, or at least the problem becomes an education one; which is why I'm out here trying to solve the education problem.
> It's simply too much burden just to maintain someone else mess. We will pay a high bill in the future for all of this.
That's, like, your opinion man. I've yet to find a development stack without it's costs, and once you are fluent in how to work in the ecosystem, Javascript's are not significantly higher than any of the others. And personally the cost/benefit of the Typescript ecosystem for me is quite rosy compared to the limitations of other stacks. I'm clearly not alone in that calculus.
Well your reply still doesn't explain the administrative (not technical) reason why you had to spend some 36 hours uninterrupted hunting for this bug. Particularly since it was 'a demo' and what broke was 'PDF export', while other exports still worked. Hardly the end of the world if you ask me.
Technically though, I have hardly met this dependency update problem with C++ simply because dependencies are rarely if ever updated. Android on the other hand was a nightmare. I had colleagues quitting in a rage and swearing to never again touch Android in their life. Probably half the effort was spent fixing crap that was broken by updated dependencies. Luckily I'm back to C++ now and hope never again will I have to touch such a crazy system. The whole 'update for the sake of update' seems to be a grave problem of the Android / Kotlin / Javascript universe. The mentality is like 'bread won't be sliced anymore, eggs won't hatch, sun won't rise if we don't absolutely have the latest bleeding edge alpha version of all libraries'.
While I agree with everything you have said, and it's been my motto since I read, "I'm sure you're joking, Mr. Feynman." The point of the post was to point out (maybe I did it wrongly) that those things you have described are pretty impossible given the ecosystem we have nowadays in Javascript (as a whole!). Of course, you can try to theorize and try to get a hypothesis on things and then try to prove those, but it's just too hard to keep track of everything.
In addition, we are using lock files and good practices but it's just too much to handle for our small team (small startup) so we will plan to migrate onto a more stable platform.
It's really funny the heated arguments this post generated but I have been using Javascript for 12 years to these days, still this looks as a nightmare to me.
Tsdoing has a good video trying to install React from scratch, that's exactly how I felt during this debugging process
Another random story from this week: we have been using `nanoid` to generate IDs internally for an internal tool. Apparently, they did a breaking change release, and now you cannot use it anymore on commonJS env. See my point? where's the hypothesis we can make? It's hours and hours spent tinkering with code and other people's dependencies, and if, as you said, put a theory that theory won't match if you think how real systems work (the networking section on the blog post)