Hey Sean from webpack, this was really just about our third party plugin ecosystem needing to catch up to v5. If you are feeling IRL Stress, then please don't update yet. Sometimes you have to break things to create progress and ship major versions+bring new features. You don't have to use them, you can just use webpack's zero config out of the box.
Sorry I offended. These aren't rumors just things we've been blogging about, etc. and I'll own being unclear. The Electron and UWP bits are things we've tossed around internally. I don't want to give more details because then it's more then I really know, which is unfair to the teams really working on it, etc.
Blanket statements don't really make great arguments. That aside, in my experience (webpack for one), projects at scale with JavaScript, are harder to maintain without some type safety and are a bit more bug prone and slower to refactor.
But at the end of the day, its still compiled to JavaScript, whether you chose to slap a .ts file in there, or just use the typechecker standalone is a mere implementation detail.
Those are product decisions someone like me can't actually confirm right? I just know that the purpose or the goal is having a single code base, single toolchain, many targets. I just know I've heard of all of those targets being experimented with! A bit early to assume anything, especially from lowly me!
Yup, and that really was what the tweet was trying to portrait. JavaScript, and many scripting (or maybe author meant interpreted languages), are incredible languages to start with.
I have a love for the "sharper" langs like Rust, and AssemblyScript, however the ease of use, hyper backwards compatible, super super accessible package manager, and OSS Ecosystem for JavaScript are what make it world-eating. Plus its only 7-11% slower then C++ execution (last I checked).
Hi there, original tweeter here. Just to clarify: no one said when this work would land, simply that we are working on it! Sorry to disappoint XD, but I guess blame the OP.
For sure! That's our preferred way of using JavaScript. TypeScript in the end is just a static type linter that compiles to JS. Heck you can even "use" TypeScript's typechecker without even using a .ts file. We do this for the webpack project using JSDOC Annotations (Project: https://github.com/webpack/webpack, Example: https://github.com/webpack/webpack/blob/master/lib/ChunkTemp...) because we didn't want a build step.
For a development environment this is great. However if there's any takeaway from this post, it is the reminder that all of the resolve, parse, eval, execute, graph traversal, and linking has to be done at runtime, so if you are okay with your app taking 1000x longer to load then if you bundle it, then I guess that's a personal preference.
However, we will continue to endorse for the sake of web performance that you bundle your code, and not use modules natively :-)
I honestly don't feel you did! In fact this gist we actually had from a contributor kind enough to document his experience so we could identify exactly what hot path migration would look like for users. So we were really happy to have this gist created. And we have it tied to our docs PR/issues :)
Sure, but since your experience is not configuring anything, how are you going to know what it's actually doing to your code. And what are the tradeoffs? Seems like many don't have this answer because they don't have good archetectural reasons for choosing it.