thelarkinn

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.

I never said there wasn't a cost. Every technical decision comes with trade-offs.

But costs don't hold us back from developing amazing new features [for developers and consumers] for the future. <3

On the Edge team and I can tell you, in no way, does supporting IE, hold back our development capabilities.

If anything, it enables more companies to adopt Edge without concern of breaking support for their legacy applications.

We see that Developers are the ones held back by older versions, and we see this as a huge win for them.

/* Looks to other top HN Posts */

A majority of consumers do not expect Google to track their activities (niemanlab.org)

Ironic?

Technically JavaScript is only ~7% slower then C++ to execute. But snipe away at that stats with real data.

No harm done <3

This is right, its more nativeish apis and webview for UI and friends. Worthy Snipe and misinformation on my part in thread.

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.

> JS would be unusable for projects of this scope

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!

Could be! Didn't we just announce (and got meme'd to death by InfoSec world) that Excel is going to be able to _run_ JavaScript.

BTW this isn't breaking news, we have been talking about our love, bets, and use of ReactNative and ReactNativeWindows for a while now!

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).

If by "They" you mean me, someone who doesn't work on the project itself, but is advising over a toolchain for it.

Also, I do not know what the Linux plans are (but hey maybe a great time to voice that special love you have for Linus T. and his masterpiece)!

I don't think I mentioned Skype for Business anywhere did I? :-)

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.

Exactly. Alt-Title: Why we use webpack.

Hi there!!! Sean from the webpack team!

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.

PS: I submitted this response also in Reddit for those who come across it twice. It's not meant to be disingenuous (as I'll likely respond to individual comments also), just meant to show what our statement is.

Hi all,

We appreciate the feedback. So whether you care to know or not I'll explain where we stand as a project for our docs.

So in this major release we want to try different ways to impact as many users as possible. So this time we consiously put priority on working directly with framework and tooling authors like angular, react, preact, vue to ensure they were unblocked on implementing v4.

With this we decided: since plugins and loaders will also need time, we will give them a month and release our final version without breaking changes from RC. However I as a maintainer orchestrating all of our separate ecosystem, docs, and teams didn't realise we had been behind on contributions and work from our docs and when the 30 day window elapsed v4 shipped as promise.

To not hold back v4 with docs is an organizational and communication error on my part and maybe even a side-effect of juggling my full-time job at Microsoft and the 120-140 hours I spend a month on webpack.

I'm more then willing to own this, and for anyone frustrated, its on me and I'm sorry. However we grow and improve after any mistakes we make. So, we have some takeaways that we will build on for our next Major Release.

A complete migration guide will be a primary shipping dependency for any future Major version of webpack going here forward. We learned that instead of focusing on frameworks as heavily to provide impact and upgrade paths, (which not have all done this yet), that instead focusing on content accessible to everyone is a far more impactful result. For now, we have the PR pending for our docs upgrade and I'll likely spend the majority of my free time ensuring we have it ready to release as soon as possible. Thank you all for being reasonable and patient with this.

Major version releases like webpack 4 are much less likely to happen. This major release included the rewrite in our plugin system, which is the cause of incompatible loaders and plugins. We have no plans to rewrite it again as it is exactly where we need it to be in terms of performance, capabilities, etc. Therefore, look to most future Major versions to be less severe and impactful to loaders and plugins.

I plan to spend much more focus on ensuring all of our separate teams are communicating for releases by coordinating all hands ship meetings. This ensures that we are on the same page and everyone is aware what each team has a dependency on.

We actually only do have one full time engineer. And have attempted to fully fund a documentation team to work on it full time! It takes a considerable amount of effort to do right. And so thanks for understanding while we continue to work on it. Contributions are always welcome along with constructive feedback.

Regardless, we appreciate as always support the positive comments we've seen here but also the actionable criticisms. It probably sounds redundant but we really stress the high bar and expectations that are set for us in the ecosystem as so many of you rely on webpack to ship your products and solutions to the web. We will keep on improving as we have since 2012 and hope you all continue to help us along the way.

Sean + webpack Team (@TheLarkInn)

And we haven't implemented persistent caching and multithreading yet ;) just getting faster and faster.

The number one cause of slowness for a page is the time it takes to parse, eval, and execute JavaScript (even if it is dead code).

So this static async bundle creation helps ensure that you are only shipping what you need on initial download.

Ah yes so we removed the page but is all still under our WIKI on webpack/webpack. Mind submitting an issue and we could surface a little note on our README?

We strive to be as backwards compatible as possible. But we also hold ourselves accountable to keeping pace with the ecosystem.

Most breaking changes are to accommodate the number one ask of our users: faster, smaller builds.

We asked what the time frame they wanted for releases. We got out of a couple thousand responses 6mo being the sweet spot. Appreciate the candid feedback though.

In regards to the v1 docs: we wanted to have a fresh start. I don't imagine our docs pages now changing for awhile. Each major breaking change we ship a migration guide so that people can upgrade.

This isn't our intention, rather to recognize those who helped make webpack what it is today. I wouldn't have been able to fit everyone on one page of image otherwise :)

We just find that it reaches people better!!! Sometimes in the JavaScipt ecosystem it takes a lot for a 6 year old tool to stay on top of people's focus and attn. But it got yours right?

Hi @mbrumlow. Sean here from the webpack team.

We did a lot of study and testing on HTTP/2 and we found that your claims are entirely incorrect. But don't take my word for it, see the stats!

https://medium.com/webpack/webpack-http-2-7083ec3f3ce6

HOWEVER! HTTP/2 and webpack become even more powerful when used together! This is something we are really excited to share and build on!

We heard this feedback infact and we wrote the entire plugin system for webpack 4! (https://github.com/webpack/tapable). Take a look at the only PR open which is us working to provide the best Type system possible for our new API (which was infact designed to support it).

Even better is that you can find all the "hooks" on an instance by doing `compiler.hooks` so now you get a far better authoring experience :-D

Hey thanks for the candid opinion!!! Sean from the webpack team here!!! Maybe it's been awhile since you have taken a look at our documentation! (webpack.js.org)!

I think something that individuals who try to make comparisons to their backend tooling that "just works" is that none of these tool have ecosystem constraints like the Web. I wanted to really talk about something that is important to understand about tooling, and why webpack might have some of the features it does.

In the web, you should only ship no more then ~<200kb of JavaScript (uncompressed), for your initial download. From there, you should be "dynamically" delivering JavaScript asynchronously in bundles/chunks. In addition, there are multiple module types that exist in the JavaScript ecosystem that libraries are published in. Sadly, some of the most popular libraries are being published with AMD Modules, or CommonJS, or no module system at all, and there is no consistency or way to know this about those modules without looking at their source code. Therefore, webpack out of the box supports the ability to load all of them. Not only that, but we employ a set of plugins that help optimize code using complex topological sorting, (aka things you'd probably never want to implement or hand optimize yourself) to ensure that your delivered code is the smallest possible.

Compare this to C++, or any "build" static toolchains. There are really _no_ size limits for the amount of dependencies or code that needs to be linked together. Therefore, there is no care in the world for application developers if they are generating 600GB Video Games, 10MB-100MB Applications, etc. Think if there was 5 ways to write C++ Modules/Java Modules, etc. and you had to apply the same constraints as the Web. (You'd probably see a lot more webpack's or a lot more convention tools that wrap things like webpack).

Anyways, as a maintainer of the project, we can't say this enough: "We are owned by our community". This means that if there are things we aren't doing right, that we owe you to make things easier to use, more conventional, when needed, and progressive in a way that lets you layer features and need on top of an awesome, and fast core product <3.

So if you have great ideas, please let me know. :-D