4 ms·
How many years have you been doing this? How many hours have teams you've worked on spent configuring build pipelines? How many people have you seen to go other
by rektide 4y ago
How many years have you been doing this? How many hours have teams you've worked on spent configuring build pipelines? How many people have you seen to go other mentors or helpers in your org when they are setting up a new project? How many many times have you seen someone start from from nothing & be done in <1 hour?
This post feels like a trivialization of how complicated everything is, how complexly interlinked build systems are.
It also misses one of the biggest harms. It doesn't consider what a pain in the ass it is when the source/libraries you are consuming have already been downcompiled into lesser JS via someone elses perhaps-poorly configured build pipeline. I'd guess that >80% of TypeScript modules don't export ESM right now. TypeScript 4.7 is about two weeks old & it's the first time TypeScript and Node's ESM play well[1]. Because it all involves complex transpilation. How many modules do you think will get updated, ever?
You know what would be great? If we could just write code. If we didn't have to worry about build pipelines. If my toolchain could make what it would of other code, be it JS or JS+TypeScript Type Annotations or JS+Flow Type Annotations.
> "For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever" "For backend node, you simply edit a couple of lines in the package.json"
The amount of dissympathy for the real complexity here, for how hard a couple specific projects have worked to make things "just go" is staggering. The amount of ink spread to support, the amount of stack overflow questions struggling through, is probably enough to reprint the Apollo Missions guidance software a couple times over.
This is hard stuff. It's complex & interlinked. There are not singular solutions; there's many many interlinked & complected tools & systems & options.
Easing the path back towards- it will work. Towards just being able to ship code, without necessarily needing to typecheck it, transpile it, downcompile it: it helps a huge range of people who are really really in need of help. Who don't have teams, companies, support. Who just want to start to learn, want to start to get going. This change may or may not (I'd argue more that it may but...) have huge impact on your life as a highly-late industrial supercorp developer, but it has huge impacts on the ecosystem, it's approachability, it's friendliness. Writing all that off, just pretending we have some magic wands we can wave & these dilemnas, these pitfalls, are not really here: woe be un to us if we are not willing to assess the real cost of this all. I can't see your post as taking for real the costs.
JS used to be extremely low cost & light weight to play with, to get started with. It used to be a joy. It still is, but the barrier to entry is much higher, using modules has never been the same dream as slapping some <script src="http://jquery.com/jquery.js"></script>'s http://jquery.com/jquery.js"></script>'s down on the page (not a real link) and having it just work. This goal is fulfillent to a noble & excellent intent to once again spark joy.
[1] https://devblogs.microsoft.com/typescript/announcing-typescript-4-7/ https://devblogs.microsoft.com/typescript/announcing-typescr...
- zackify 4y ago80% of typescript modules don’t export esm? What? Most people write code using esm for the past few years. If anything the problem is that shared libraries are only exporting esm so tools like jest that still require commonjs don’t work. Just use Tsdx or other tooling to automatically expose the different bundle types. Even still, if JS developers took the time to understand the different module types we would be in a much better place on the shared packages front
- rektide 4y ago> Most people write code using esm for the past few years. But what do they target? TypeScript projects targetting only es2015 or only cjs are all too numerous. Much of nobility of this Type Annotations work is we could (potentially) stop transpiling. The source could be the source. > Just use Tsdx Just use ____ is the center square of the JS bingo game. It's a terrible answer, but it's almost always the answer, and the answer always changes. That there's an ever rotating constellation of "just use" answers to newcomers questions, all of which are semi-required "zero configuration" "just works" new tools to fix the previous pile of cobbled together stuff: painfully Python-esque.
- codethief 4y ago> painfully Python-esque I agreed with every single thing you wrote until that last line. In what universe is the ever-changing mess that is the JavaScript ecosystem even remotely comparable to the Python ecosystem?
- rektide 4y agoA not unreasonable call out at all. The multi-layers of pip, setuptools, easy_install, virtualenv stuff made me very sad at the time. Nodejs was such a relief at the time. My understanding is recently Python docs have started to encorporate a little more guidance on handling dependencies in virtualenvs, and some specific suggestions & write up about tools. Which is great. I think your right that JS probably has a lot more build/compiling/lifting machinery, & is much more confusing. To be fair, it also has a much harder job (since the build-target is only sometimes the local machine).