4 ms·
I see lot of frontend people say this (since their baseline is "nothing"), but as someone who's used to compiled languages, all JS-ecosystem tooling is quite at
by o11c 2y ago
I see lot of frontend people say this (since their baseline is "nothing"), but as someone who's used to compiled languages, all JS-ecosystem tooling is quite atrocious. It's still missing many of the useful basics that other ecosystems take for granted.
- fidotron 2y agoThe way around this is to build your own tools. For instance, I used esbuild as a library to write a custom obfuscator that links the hand written JS and GLSL together. (This is why the shader link symbols are also obfuscated). I came from many years of compiled languages in the games industry. I would not assume the current state of React and TypeScript is bad, far from it. There are reasons this stuff has eaten away at more native approaches, or inspired things like SwiftUI. Edit to add: To also add that in my time I've seen more WebKit added to games in order to do the UI. For instance, that Sim City which was always connected to the cloud, or big bits of the PS4 interface.
- o11c 2y ago"build your own tools" is also known as "the ecosystem is lacking"
- leptons 2y agoOne tool does not necessarily fit all the things. And that would be true of any "ecosystem" that has as many diverse uses as Javascript does. Versatility is one of Javascript's strengths, not a weakness. And with that versatility you get what seems like too many frameworks.
- fidotron 2y agoI have never met an existing ecosystem where building your tools did not make your life easier, at least in the short term. The trick is knowing when to abandon them in favour of a standard solution. To put this in perspective one team I was on built their own Android NDK, until the normal one caught up.
- o11c 2y agoTrue, but I've never met an ecosystem where building your own tools is required.
- supermatt 2y agoCould you give some examples of these many missing basics?
- o11c 2y agoTwo blatant ones: 1. conditional compilation (typecheck and use these apis only in some environments), and 2. being able to compile "hello world" in under 1 second. I know I keep finding more but these ones I can't even write trivial programs without running into. I've been trying to emulate conditional compilation using multiple directories, but that runs into problems with each tool using different path lookup logic.
- supermatt 2y agoThis sounds more like lack of knowledge/experience of the tooling rather than problems with the tooling itself. Many build tools will “tree-shake” unused code and support conditionals when compiling their bundles. Build time varies considerably depending on the tooling you use and the size/complexity of the project, and is definitely much slower than many other languages, but while developing people will use incremental builds which can complete faster than you can type a new statement. What other basics are “missing”?
- o11c 2y agoIgnoring the massive vtable problem for a moment ... If tree shaking is so good, show me how to write something like this: * when targeting browser, use dom * when targeting node, use process/fs * typescript should bail out if a mixture of APIs is used. That is, the type-checking must be done twice - once for browser-only, once for node-only. (nodejs is also rather abominable for implementing APIs that really, really only make sense in browsers, like `navigator`, breaking everybody's runtime detection, but all non-browser environments require evil hacks anyway)
- supermatt 2y agoThe obvious way is to use separate configs for each target - most bundlers support running these builds in parallel. It seems like you are trying to do something in a specific way instead of using the available tooling correctly. That’s not a problem with the tool. You just need to RTFM As for the “massive vtable problem”, that’s not even a tooling issue. Why are you even using JavaScript if that’s a problem for you.
- MrJohz 2y agoCan you describe some of those basics? In my experience, the JS ecosystem is surprisingly good, and most of the issues tend to be due to a lack of experience rather than directly tooling issues. For example, NPM is one of the better package managers out there, but like all package managers, if you haphazardly chuck dependencies at it, and don't pay attention to what you're going, you're going to have issues. A lot of people run into those sorts of issues and assume that this is a general NPM problem, but it doesn't have to be that way.
- o11c 2y agoI've replied more in the other tree, but I'm not even touching NPM yet. The stuff I'm writing is simple enough not to need any dependencies.
- zeta_ 2y agoWhy don't you give us some examples?