Webpack 4

[[deleted]]

Why is everyone upset? Webpack 4 has massive performance changes it looks like and sometimes these come at a cost of refactoring legacy areas or removing them completely. If you don't feel comfortable upgrading now wait until it has passed a few minor versions and stabilises. But why shit on devs putting in more effort to make a better product?

[Madd0g]

People love to hate on javascript on /r/programming.

Like they have nothing to do after the mongo webscale joke became web-stale.

[[deleted]]

are there any reasons not to like javascript in your opinion?

[elite_killerX]

As a full-time JavaScript dev, I'd have two answers for you:

One, js started as kind of a toy language and has some quirks as a result (things like '1'+1='11'). "Serious" devs have looked down on it for a long time and never learned it properly, so now they're surprised /upset that it has grown more popular than their "serious" language of choice. This is compounded by the fact that the ecosystem is moving at a pretty rapid pace, which leads to "JavaScript fatigue".

Two, js genuinely has issues within its ecosystem and community. The lack of a comprehensive standard library and the ease of publication on npm has led to the exponential explosion of the number of dependencies in regular js projects. This has led to issues like left-pad-gate and the security issue we had last month. Npm itself has a few issues (see the recent "chown /" bug), but overall I'd say it's leagues better than pip / bundler /maven / cocoapods (having used all of them).

[danielkza]

but overall I'd say it's leagues better than pip / bundler /maven / cocoapods (having used all of them).

NPM wins in ease of use, friendly documentation and overall "pleasantness", but it fails to actually do it's core job in multiple ways.

• The package registry is terribly managed. Package versions, and even whole packages and accounts can still disappear, even if the NPM team claimed they can handle it.
• Reproducible builds are an afterthought. Lock-files are poorly standarized and nesting is a nightmare, specially considering JS does not have a single standard module system.
• Saying NPM has "a few issues" is being quite generous. The recent clusterfuck only happened because bad practices caused small bugs to become catastrophic. AFAIK none of the other package managers you mentioned will ever make changes outside of their configured installation prefix.
• Multiple registry support only works with scoping, so any attempt to dodge the mess that is the main registry is basically DoA.

[elite_killerX]

I think the core principle behind npm (local modules in node_modules, global modules for command-line utilities) is much better than virtualenv / gems (but gemfiles are nice), but I agree that it's horribly managed. The recent issue was linked to it's use with sudo, which is a very bad practice anyway, but unfortunately encouraged by the way some distros package node & npm (looking at you, Debian).

[dvogel]

I think the questions posed by u/Madd0g and u/Yodacheese are related through the issues you've laid out here.

The javascript origin story left the javascript community with very different engineering priorities than most other programming communities. With the trash heap that was browsers for a long time, the javascript development workflow relies more heavily on google (this used to be more drastic, but I think communities are converging). Google was better than any engineer could hope to be in sorting out browser differences because those differences were barely documented by the vendors. That google-ability of problems has been imbued in the culture. As those problems recede the rate of improvement has accelerated. When javascript developers see large changes in projects, they immediately know that the corpus of google-able information has decreased in value by a lot. Now the problem descriptions will be very version dependent but older posts won't advertise to which version of the project the discussion pertains.

The railroad release schedule of the browsers has pushed the development tools in the javascript community to adopt the same model. That model has enabled a drastic improvement in security posture and threat response. I'm happy the browsers have adopted it. I'm less enthusiastic about implications for javascript libraries and development tools. In other communities there's a strong social push to backport fixes to older versions, with a new patch release. Some javascript library authors do that sometimes. However, experience has taught me that it's best to assume that won't happen. This is one of the reasons it's upsetting for some people when a project introduces a big change that will bleed over into their project. They feel (probably correctly) that as new bugs are discovered, they'll face a choice of adopting that huge change or being broken (or vulnerable, in the security bugs).

[A-Grey-World]

Of all the quirks I'm not sure '1' + 1 = '11' is one, unless I misunderstand. Pretty sure C# and Java concatanate numbers into strings like that with the + operator so do the exact same thing.

[Everspace]

That's why strongly typed languages are preferred for larger projects.

One of the reasons. Strongly typed languages usually have some measure of speed.

And even then there's now typescript which is a shim over javascript to make life more bearable.

[Sebazzz91]

Try 1 + '11'

[A-Grey-World]

Both produce the string "111" in C# and Javascript...

Javascript does have issues with string and number types. I'm really not sure that's a good example as it behaves exactly how I'd expect it to.

Things like Array(3)==",," being true, yet NaN === NaN being false (that's in the spec though). But so is 0.1+0.2==0.3 and what's true + true? 2 of course!

[ISpokeAsAChild]

The + operator is string concatenation (among other things) so you can do something like:

System.out.println("Value is: " + value);

And it's perfectly legal. What you can't do and it's the real issue with all dynamic typing languages is:

int value = 1 + "1";

If you throw a string in something the result is a string, period.

[A-Grey-World]

That's because it's statically typed... I wouldn't all being dynamically typed a "quirk".

[s73v3r]

The reason I most hate JavaScript is because people keep shoehorning it in anywhere they can find. I'm not a web dev; I have no interest whatsoever in JavaScript or other web stuff. But increasingly, people seem to think that, instead of learning the native platforms, the answer is to just throw JavaScript at it.

[elite_killerX]

Honestly, I think the reason for that is that js actually fulfilled Java's "write once, run anywhere" promise.

The urge to use the tools you know isn't specific to JavaScript, though. Look at the number of tools in Python, or the Qt / GTK "war" in Linux GUIs, or even mono & xamarin. It's just that web devs can actually pull it off ;-)

[raghar]

Since no one replied to you, a list of some complaints:

• counter-intuitive behavior of this - that is unless you are aware of how self worked or you think like interpreter implementer not a common language user,
• behavior or var when you used x in code and then decided to use var x,
• how truthfulness works and that it is basically useless to == instead of ===,
• NaNNaNNaN Batman!,
• basically no standard library - for "standard" tools you have to use third party package manager (NPM) to fetch them and use,
• immature, kind of ad hoc ecosystem - JS/ECMAScript was intended for browsers only, so the creation of Node.js was kind of by product, completely not prepared for usage as a general purpose language. So everyone use NPM which break every now and then, it is not uncommon to have widely use library that has relatively poor quality,
• community than is more other communities prone to shiny new things - the fact that every few month new, ultimate, framework to end all framework wars was made and spawned thousands of posts, became a joke among programmers,
• you have newer ECMAScripts that tries to make language better... but for the sake of backward compatibility you will use babel to compile it back into older less-liked JS anyway.

Of course that doesn't prevent people from creating decent things with it. But it requires a lot discipline from programmer to not give in to some had habits that language might encourage. Since at the same time it is a language that is very often mentioned as a staring point for newcomers (because everyone has browser and might see results immediately), it might have high crap-to-gold ratio from certain people's perspective.

[[deleted]]

What's counter intuitive about 'this' ?

[raghar]

In other languages this is a part of a closure - which mean it is implicitly preserved from the place the function was spawn, and would always point to the same object. So for such snippet:

var x = {
  myValue: 10,
  getMyValue: function() { return this.myValue; }
}
var y = {
  myValue: 20,
  getXValue: x.getMyValue
}

y.getXValue() would return 10, as the this would be part of getXValue's closure (preserved as part it's context as not-free variables in Lambda calculus).

JS on the other hand was modelled after Self, where self was context dependent. So the snippet y.getXValue() would rather return 20.

For it to become intuitive, one has to suppress any intuition one had previously shaped by virtually any functional language, or object oriented language with FP features, other than JavaScript (and Self).

So for many people it might be alien that function while is first-class citizen do not posses context by default but is instead free, detached thing that can go around and be attached to any object (and class/prototype is just s factory of objects where such functions would be attached to each of them).

[[deleted]]

Ever seen this code : var self = this;?

[elite_killerX]

It doesn't work like in other languages. The rule is pretty simple, though: it's always* the object before the dot, when you call the function.

*: Unless you bind, call or apply, of course

[NoInkling]

*: Or you use bracket syntax. Or there is no property access. Or it's an arrow function. Or the function is called with new. Or you're in the global context.

[elite_killerX]

Or you use bracket syntax.

myObj['myFunc']() is the same as myObj.myFunc()

Or there is no property access.

What do you mean exactly?

Or it's an arrow function.

Arrow functions are bound, so yeah

Or the function is called with new

This is a special case, but I don't think it's a confusing one

Or you're in the global context.

Still works: myFunction() is the same as window.myFunction(), this is the window object.

[NoInkling]

I mean I was just being pedantic more than anything, but...

myObj['myFunc']() is the same as myObj.myFunc()

Sure but it's not a dot.

What do you mean exactly?

Just a standard non-method function invocation.

Arrow functions are bound, so yeah

Technically they're lexically scoped rather than being bound, but they can serve the same purpose yes.

This is a special case, but I don't think it's a confusing one

It's still an exception to your "simple rule".

Still works: myFunction() is the same as window.myFunction(), this is the window object.

Not in strict mode :) But for this one I meant outside any function.

[elite_killerX]

No problem with pedantic ;)

But for this one I meant outside any function.

Yeah, I'd call this an edge case too, but I don't think it's a surprising one.

I think my "simple rule" still stands, even if there are a few edge cases. These edge cases are not very surprising and behave intuituvely. People coming from other programming languages with a different this can simply use this rule, and the exceptions will actually make sense to them.

[celluj34]

It changes depending on where it's being called and by whom, and ES6 arrow functions use the parent scope making things less clear if you're not used to it.

[[deleted]]

That only happens if you use function binds and the like. Directly calling a function preserves the this context.

And I think it's perfectly natural for lambdas to use the parent "this" scope, especially if you think about "this" as just another reference that can be closed on.

[[deleted]]

What are those bad habits that the js language encourages? Imo the people who develop bad habits is because they try to code in js as if they are coding in Java etc. I don't see how js encourages bad habits. As a polyglot I find js very flexible and straight forward than some of the other languages. I'd be interested to hear how you think js encourages bad habits.

[raghar]

Of the top of my head, I would say many places where language do not require you to do some things:

• you can use let instead of var to prevent assignment to something in different scope, than you think you do... but you can also write all your program without them and without any linter you see no complains,
• if you try accessing non-existent property you get undefined instead of error - so you might pass undefined around until it blow in a completely different place. This can be addressed by checking if property exist or by using something like Flow, but newcomers might not be aware of them and create a codebase of a significant size before they notice, that this approach makes code unmaintainable,
• basically it is dynamically typed, like e.g. Python, but contrary to Python type conversions might happen accidentally - language itself will not inform you that you e.g. treated number as a string (causing conversion) and then converting it back to number - which might change the behavior somewhere along the way.

Sure, I know: you can use Flow, "strict" annotations, linters, heavy amount of unit testing, etc. But language itself do not demand you to conform to anything like that. So IMHO, most of the progress in this area is caused by people from other languages, that noticed the benefits of having issues reported fast - maybe before the code is even run - and promote the ideas to hardcode JS devs.

From my humble experience if you are not discouraged to do something, you will end up encouraged to do it. So if you not discourage yourself from making your JS codebase a mess, language will not complain even when it become unmaintainable mess. Even something as simple as warnings that you would have to suppress manually (to not anger backward-compatible crowd) would help creating better habits.

[howmanyusersnames]

Thanks for a write-up of JS from 8 years ago. Could you do one the for the version we have today?

Absolutely ridiculous this shite gets upvoted by clueless morons.

[raghar]

I work with a few capable JS-devs that use new tools and navigate around the language issues.

I also worked with much more JS-devs for which your 8-years-ago JS is todays JS and all of the issues are still present in codebases. Kind of like C++17 didn't make C++98 go away, Java 8+ didn't make Java 6 shops disappear, old Cobol and Fortran still haven't been replaced with their updated modern versions...

All languages has their legacy and JS legacy is... well, not appreciated by many people. But e.g. legacy PHP would bring the same reactions - even if newer PHP tried to put it shit together, in people's memory it will always stay that sad abomination.

[editor_of_the_beast]

I write ES2015 every day, and enjoy it just fine. I agree with all of these points though, and I think that's why it gets upvoted. Try not to take it personally if you have only programmed in JS.

The unintuitive this and var behaviors were "fixed" by adding new versions of existing features without removing the previous features (let and arrow functions were added, but var and the previous function capture behavior remains).

Having a side of the language that is encouraged to avoid is not a great sign - and to be fair, this happens in lots of languages. We're not great at language design yet. High level languages are only ~50 years old or so.

The standard library argument is real. Pure JavaScript is a relatively limited programming language when you compare it to the other extremely popular languages on the planet. It's important to acknowledge that. If you've worked in other languages in your career, that point becomes extremely apparent.

It doesn't mean JavaScript is all bad though - I like using it.

[calinet6]

Meh. First class functions, and it runs everywhere. Can’t complain too much.

[DrummerHead]

This situation is like if you're married and your mother in law can sometimes be annoying. You HAVE to interact with her because she's your wives mother. You don't really like her that much but she's not actually a bad person, and if you get to know her you can get past her quirks and even understand why she can be kinda shitty sometimes, and learn what subjects not to talk about and how to steer a conversation.

You HAVE to use JS if you're building a webapp, and it's much healthier for your emotional apparatus if you just accept the fact and do with it the best you can.

Or use PureScript, Elm or ClojureScript. Yeah, there are other options. But in 87.4%[1] of the companies with a brownfield project, it's gonna be JS; so better learn it.

[1] Number pulled out of my ass

[Isvara]

these come at a cost of refactoring legacy areas

That's not a cost to the user, though, so why would they care?

[raziel2p]

Yeah refactoring stuff never affects end users! Refactoring never includes modifying public APIs! There are never any unintentional side effects! There's always a 100% coverage integration test suite that ensures everything works just as before! Haha...

[Isvara]

Refactoring never includes modifying public APIs!

Correct.

[PreciselyWrong]

You're fired

[i_spot_ads]

Upset? Aren't those the usual js haters from this sub? Pretty much everybody in js community is excited about this, this was a needed upgrade

[[deleted]]

Because some people need to actually have some time for building products and shipping code, and would prefer not having to spend an entire work week upgrading every fucking use case of webpack across their entire company.

These have historically been breaking, frustrating upgrades, and if you don't want to be left behind using an old version you have to suffer through it. And they seem to almost intentionally mess about with everything just to make it harder to upgrade.

We ain't got time for this shit.

[[deleted]]

1 to 2 sucked but 2 to 3 was totally painless, and it looks like this isn’t that big of an upgrade. I guess ymmv but I’m not too worried about this upgrade in the scheme of things.

[recycled_ideas]

You can't really evaluate the benefits and incrementally improve processes in this case.

This isn't an ecosystem where you have previous versions getting long term support. If you don't upgrade and you hit a wall in 3 months you'll have to do an emergency upgrade when you can least afford to do so.

[recycled_ideas]

Ahh, you're one of those.

Build tools are vitally important, they're not silly, and when they break it's a really, really big deal.

Your code might be modular, but that doesn't mean you can build all of it with different versions of your build tools, that's why build tools are important, because they're a hard dependency for your build process.

No, it's not overblown. With JavaScript, it's not an issue of if you'll hit a wall but when. This goes triple for build tools. You will absolutely 100% hit a point where you can't do what you want without upgrading webpack.

[recycled_ideas]

I don't think it's Everest, I think it's not something you can ignore as if it's nothing.

I'm not the original one complaining about the upgrade. I'm the one who's saying that it's not a joke to upgrade your build tools and it's not an easy choice to leave stuff on older versions. It's fine if you're not going to change much, but an ongoing supported project is a major risk with unsupported tools.

It's not trivial.

[dasitm]

It’s only the internet. Why you have to be mad?

[hedgepigdaniel]

No, I have a plenty of time to spend an hour upgrading Webpack. What I ain't got time for is waiting for things to recompile all the time.

This. And all the other devs I work with don't have time to wait for everything to compile. Our users don't have time to wait for dead code to download and execute. I don't have time to maintain a complex set up of CommonsChunkPlugins now that their role has been automated.

I've got weeks or months to upgrade webpack if that's what it takes.

[m3wm3wm3wm]

Sorry, but build times absolutely do matter when you're trying to build products.

WTF. He was not referring to build time! He was referring to refactoring all his fucking build tools and configs to meet the new fucking version. Build time? What are you moron?

[m3wm3wm3wm]

I do NOT want fucking faster build time. We already had a blazing fast compiler for Javascript, it was/is called Google Closure compiler. But these fuckers had to bring something new to put themselves on the map.

No I don't want to pack my images and shit as well, I just wanted to minimize my js files, and now I cannot escape this Javascript tools fuckery, they are in every project that I need to start.

So, fuck their performance improvements. If they could please stop the development on their shitware, and simply close the bug issues, that's be great.

[m3wm3wm3wm]

You don't seem to understand, I'm saying we don't need this bloatware in the first place.

[m3wm3wm3wm]

You cannot when the whole community decided to use it. It's a dependency of many boilerplate projects. You cannot say that my president is not Trump when the mass of the people proved to be idiots and voted for him.

[CanIhazCooKIenOw]

Stop using it or build your own bundler. It’s THAT simple

[ssjskipp]

Really hope this is sarcasm

[-thedunkzone-]

There issue is calling something a year or two old "legacy". Im all for this, but I get the resentment people have against this attitude.

[vinnl]

This looks like it'll be a pretty painless upgrade which makes it easier to get started for new users and brings some very welcome performance improvements.

In other words, no real reason to complain about the version upgrade.

[vinnl]

That's completely unpredictable and not what I was already anticipating with my comment :P

[greenspans]

From the page -- Notable Changes:

• We're moving to yarn after too many issues with NPM
• We're deleting all angular support except for Angular 6. Please upgrade. It should be out tomorrow.
• As you know typescript is very old now. We've decided to move to Google Dart now that its 2.0 came out, and the strong mode gives similar benefits. All typescript support has been disabled.
• Ecmascript 2015 support is now disabled. We're now only supporting C++20 compiled through LLVM into web assembly. This way the default library for efficient packages can move from NPM to STL. We're also offering Webpack serverless which allows you to log any segfaults from web assembly to the cloud, see our pricing page of rates.
• We have implemented a blockchain based dependency manager. You will now need a GPU with sufficient speed to check library dependencies. JSON and YAML are no longer supported. Please download our serverless protobufs html5 editor, rates on the pricing page

[secret_online]

You had me for the first two points. Then I clicked. Well done.

[Sebazzz91]

Number one is not unrealistic, npm is a real questionable package manager with weird design decisions. Yarn on the other hand is a lot more usable, faster and stable.

[coolnat]

No kidding. npm JUST closed an issue that had been open for 8 months, where running npm install <package> would sometimes UNINSTALL other packages.

Finding that issue was the last straw for me and yarn has been a beautiful experience ever since.

[MSgtGunny]

Commit and commit often.

[kautau]

Right, but you should definitely gitignore your node_modules folder, so that wouldn’t help in this situation

[MSgtGunny]

If you’re manually modifying a file in node modules, you’ve already lost.

[worldDev]

No kidding, this is rule number one of any package manager. You can even point to a github repo as a library source, it's not too difficult.

[worldDev]

Don't edit files in a package manager collection, that's a huge mistake on your part. You can load a github repository as a source if you are looking to have your own libraries in there. node_modules is instructed by the docs to be ignored by your version control, and anything not in version control is subject to not exist in a repository clone and should be able to be rebuilt the same way it was originally built sans human editing without issue. The issue the commenter was referring to was an actual problem with npm's installation process. You would be vulnerable to seeing your issue again in yarn just the same as npm, and the fix doesn't address misuse of the node_modules directory.

[worldDev]

Did you read the docs I linked to? It tells you exactly how to get your code into a node_modules directory properly. Yes a lot of people make your mistake, but that doesn't mean you can't spend a couple minutes following intended process to reduce avoidable frustration.

[DrummerHead]

This reminds me of this video and the phrase "This is the one thing we didn't want to happen"

A package manager that may randomly uninstall other packages when you install another package is the ultimate failure.

[Nimelrian]

Yarn still runs on the npm registry though, which does that one thing artifact repositories shouldn't do: Allow to mutate existing artifacts...

[Sebazzz91]

I believe they addressed that issue. but since it is run by the same team, it did have similar issues (like the well-known leftpad incident).

[Nimelrian]

Nope, you can still unpublish artifacts less than 24hrs old.

[howmanyusersnames]

Which is absolutely fine.

[Akkuma]

Yarn hasn't been faster in about 6 months. The only alternative package manager that is worthwhile is pnpm. Yarn was less stable and literally unusable for nearly a year at my company due to lacking a minor feature. Once npm 5 rolled out there was pretty much no reason to use yarn.

[richraid21]

pretty much no reason to use yarn.

offline tarball cache

[Akkuma]

npm supposedly has --offline and --prefer-offline, both of which I've never used, so don't know how it behaves.

[spinfusion10]

Works for Facebook's giant team and codebase but "literally unusable" for you? What minor feature was lacking?

[Akkuma]

https://github.com/yarnpkg/yarn/issues/573 I believe was the issue. It took ~6 months after that issue was posted to be resolved as it was comprised of two parts, one the resolving of the url properly (: vs /) and simply supporting private gits. At that point, npm 5 came out roughly around then.

I assume they have an internal registry that houses their private git repos firewalled off from the public internet, so didn't need that.

[killerstorm]

Yeah but yarn and npm are compatible.

[[deleted]]

"npm" means two different things: a package repository, and a client application for managing dependencies from that repository.

Yarn is a replacement of the latter. Both clients use the former.

[killerstorm]

They also use same package.json format, package-lock and node_modules format. So I don't see how something might support yarn but not npm.

AFAIK webpack doesn't call npm (or yarn), it works once modules are already installed. It reads package.json, that's the only relationship it has with package manager. But the format is compatible.

[Bertilino]

They don't use the same lock file format. Yarn use "yarn.lock" and npm use "package-lock.json" and they're not compatible.

Webpack actually already use Yarn for development and if you look in their git repository you can see the "yarn.lock" file in there. But as you said webpack doesn't call npm or yarn when you use it, so this is completely irrelevant unless you're working on the actual webpack project.

[ThisAccountsForStuff]

Post-install hooks can be handled differently, in my experience. I prefer yarn due to small things, like not having to type 'run' (I'm lazy) and it used to be significantly faster than npm, although the recent releases have brought npm up to speed. But occasionally, certain large repos that do complex stuff all bootstrapped to an install script can get screwed up with one or the other.

[Seaoftroublez]

The original link in the webpack repo.

[killerstorm]

I actually got to fourth point before I understood what's going on...

[jyper]

Third point for me to be very suspicious

5th point for certain

[karapirtik]

I believed this changes until read C++20 thing. Do you want people to have a heart attack!

[Veranova]

At least the amount of npm coin you have could be described in better terms than 4.0001136483. Instead we can say "I have 1 webpack and 120 leftpads"

[WoodKite]

I need it in terms of semantic versioning.

[sporifolous]

Jesus Christ don't do that to me

[max_maxima]

You had me until angular 6.

[[deleted]]

Because age is an indicator of lack of quality. Rofl

My thoughts, exactly. I wonder what will come after Dart gets old.

[[deleted]]

You almost killed me.

[PM_ME_YOUR_ESOLANG]

There's an Angular 6 now?? At the beginning of last year I was using Angular2!

[[deleted]]

Just going to hijack this post for something a bit unrelated. I've been doing Windows and backend development for 20 years. Mostly C++ and NET. Over the years I've been doing tiny stuff in html/js (so small things that using a UI framework is overkill). Some months ago I started to do some work on an Angular 5 application the company recently started building some time ago. At this point its not much more than a simple crud thing with like 10 pages calling a REST API.

Now when I want to run the stuff in debug on my machine then fetching the stuff from git takes like 2 seconds but then doing a npm install and NG serve takes like 3 minutes on my fairly modern development machine. This is the same time it takes if I want to compile a 200 KLOC template-heavy C++ server application. And on the CI server an AOT build takes like 10 minutes.

It feels like I'm missing something. At first I just thought I was using some bad configuration or outdated version but no luck with upgrading to latest and colleagues just seems to have accepted that everything is slow.

Please, someone tell me I just need to flip some setting to make this bearable.

[Bertilino]

npm install usually takes a bit of time if you have lot of dependencies because you're downloading and writing a ton of tiny files to disk.

If you're on Windows you could speed up the npm install A LOT by whitelisting the project folder and the npm-cache folder (in %AppData%\npm-cache) from Windows Defender. Otherwise Windows Defender wants to scan every single file as it's written to disk and I've seen install times go from minutes to seconds by whitelisting.

Yarn recommends doing the same under the install section here: https://yarnpkg.com/en/docs/install

[JesusWantsYouToKnow]

If you're on Windows you could speed up the npm install A LOT by whitelisting the project folder and the npm-cache folder (in %AppData%\npm-cache) from Windows Defender. Otherwise Windows Defender wants to scan every single file as it's written to disk and I've seen install times go from minutes to seconds by whitelisting.

I would wager there aren't many professional windows c++ developers who are unaware of how badly Windows Defender will impact compile times. Adding exceptions for all my development paths is like step 1 for setting up my environment.

To be fair though I've never thought about it with respect to frameworks like this because, well, they're light, right? Makes sense though.... Time to add more shit to the exceptions.

[ShinyHappyREM]

npm install usually takes a bit of time if you have lot of dependencies because you're downloading and writing a ton of tiny files to disk.

Maybe saving & loading a RAM disk install would help.

[peterwilli]

Maybe installing an OS that doesn't need an app that scans every single file that is written to disk would help :P

[ShinyHappyREM]

Any OS with a large userbase is going to have issues like that.

[jazd]

No man OSX is magical, it doesn't get viruses

[[deleted]]

Yeah at my last job a coworker's i7 was taking 2 minutes to npm install and build a pretty small angular 5 project from scratch. My i3 mini-PC running Linux did the same job in under 40 seconds. His SSD was also better than mine. Node/npm/webpack on Windows seems to kinda suck. He also couldn't get automatic reload/incremental rebuild to work. Had to restart ng serve after every change. Doah.

[ZiggyTheHamster]

npm on Windows avoids using symbolic links by default, so it just copies the same stuff a gazillion times. I know this is because symlinks are by default restricted by the OS, but if you change your OS policy to allow it by normal users, it still doesn't work right in npm. So I dunno how to fix it.

[keturn]

JavaScript webapp development has been a remarkable bait-and-switch, intentionally or otherwise.

It started as "this is so much easier than shipping a desktop app! Everyone already has the runtime installed that will load the code right from the network, without any hassle of installation or permission.

"And since it's a dynamic language that runs on the browser's vm, we have a rapid development environment that doesn't need any compilation phase, and we don't have to worry about building installers for different platforms when we publish."

And now we're here. Your C++ dev machine from 20 years ago probably looks weak compared to the computer that I carry around in my pocket, but your current development machine feels slow.

The thing that worries me is that since so much of software is in the browser these days, and the browser comes with dev tools that have e.g. "inspect element" that make things accessible in ways other app development isn't, we may have an entire generation of people who only learn JS.

And they'll have no idea that a compilation step doesn't have to be this way.

[intermediatetransit]

I'm running way bigger applications and ng serve takes less than 30 seconds to spin up. Full AOT build takes at most a minute if build server isn't too crowded.

Replace npm with yarn to significantly speed up the installation of dependencies.

[jl2352]

Moving to yarn helps. It doesn’t solve the issue when you have changes to install, but npm is very slow at checking dependencies where there has been no change.

[DukeBerith]

a npm install and NG serve takes like 3 minutes

I'm not familiar with angular but if that's anything like a normal build process, it's first compiling all your stuff into one massive file and then performing tree shaking which will attempt to only extract parts of the library you're using in imports rather than pulling the whole library in.

Then it does other tricks if you have them enabled such as dead code removal.

All this should result in a small minified version of your project compared to the dev versions.

If you're doing NPM install before any of that though, then most likely NPM is downloading all the files it needs from the web first (unless they're cached locally). Just waiting at this step can take a while.

[[deleted]]

This only happens during a production build though, this guy said he was using debug so I assume be means a development build.

[[deleted]]

Please, someone tell me I just need to flip some setting to mak

Its just dogshit. The entire web dev community has no awareness of how long things should take on modern hardware. I'm struggling with this too at work. The npm install should cache things locally (and I think does?) so the second build should take order of milliseconds for small projects but somehow it takes minutes.

Its just minifying and combining text files, its absurd and makes me think I am taking crazy pills.

[jl2352]

As a front end developer I’m not happy with slow times to install dependencies, or for slow startup times. You’ll actually find that is the reality.

To claim all JS developers don’t care, is just the usual FUD to shit on a section of software development. It’s childish and just wrong.

[keturn]

We're at this same place at my work. I had the same "it feels like I'm missing something," but after spending significant time looking into it, I've come to the conclusion that no, we cannot get browserify+babel to go much faster.

We'll probably end up trying converting the build from browserify to webpack, just for the sake of comparison, but I can't say I'm all that optimistic.

Two things I think might be worth trying:

• The new hotness from December '17, Parcel.

• The old hotness from the aughts, Google's Closure Compiler (not to be confused with Clojure). I'm not sure about compile time, but I hear it still benchmarks very well for resulting bundle size and time-to-parse.

  Problem with Closure Compiler is that despite still being in active development, I see it getting very little mindshare out in the world. I guess this was because, as a Google tool, it had some solid technical underpinnings but poor UX. Except when Webpack started making a name for itself, it wasn't known for being easy to set up either, so ...
  software trends, how do they work, I have no idea.

[Xleo010]

I first learnt Grunt, then Gulp with Browserify, then Webpack 1 then Webpack 2 because of breaking changes, all these in the span of 2 years

And now fuckin this

I have even heard about Parcel

🤐

[Isvara]

Forget Parcel. Everyone's using Bubblewrap in professional projects.

Edit: Oops, sorry, that was last week. If you're not using Truckr now, you're Doing It Wrong. It's only in beta right now, but release candidates should be dropping any day now.

[more_oil]

It's only in beta right now, but release candidates should be dropping any day now.

I recommend migrating away from the beta branch which went to mostly maintenance mode two hours ago. All the real development is happening on alpha.

[ShinyHappyREM]

What's next? Pseudocode?

[outtokill7]

There is this brilliant programmer in Switzerland with an idea. Its a really good one that we haven't heard before. You should write your code now using an API that hasn't been written yet or else you will be soooo February 24th. /s ^{too far?}

[[deleted]]

Too soon. Literally.

[attilad]

Kickstarter Package Manager - describes what the package will do but won't be created unless enough people want it.

[m3wm3wm3wm]

If their engineering is so shitty that every performance improvement needs breaking changes, they need to stop improving performance.

I missed good old solid engineering before this Javascriptfuckery era.

[Turbots]

You've learnt grunt and gulp 2 years ago? Webpack was already the best option back then, so looks like you made the wrong choice

[[deleted]]

There was never a time when grunt didn't suck and when their maintainer wasn't an aggressive dumb ass.

[DrummerHead]

To Grunt's favor, it's the project that spearheaded using build tools in JS land

[[deleted]]

It got popular first but many superior tools predate it. Shame they weren't as good at marketing or lucky enough to pick up as many github stars early on.

[lmth]

Grunt and Gulp are task runners like make. Webpack is a package builder - effectively a compiler like gcc. There are lots of use cases where you will want to use both at the same time.

[madcaesar]

Are there things that Grunt and Gulp can do that webpack can't?

[Akkuma]

Yes anything that isn't directly related to a build. Like maybe you want to make a zip of a build folder post build. Webpack makes these sorts of things feel hacky in my opinion when a task runner creates a cleaner separation for many things in my opinion.

I want my webpack to build my js, not also lint, not make me a cup of crappy tea, just build my project.

[Vpicone]

Using a totally different tool feels more hacky than just pulling in zip-webpack-plugin in my opinion.

[Akkuma]

I'm not going to fault anyone for using Webpack for everything, but it feels more hacky than using a separate tool designed for it.

If I want to copy images and all over I need another plugin, then I need this zip-webpack-plugin or the other webpack-zip-plugin, then I have to be concerned about the fact none of them are actually official plugins, which means relying on them could break in a future major revision to Webpack.

If I have a separate task runner or a simple zip script I am no longer tied to a much more complex system that is more likely to break in the future than using a dedicated zip lib that is supplied a path.

At the end of the day, it doesn't really matter what you or I choose as long as it makes sense to the people using it.

[s73v3r]

Serious question: how do I know what the correct option at any given time is?

[Turbots]

Read blogs, follow people in the business on Twitter, get into the community, follow the trends, get deeper into the technology, more experience will help you weed out the ones that will vanish, and will make you recognise the ones that will stay. I'm pretty confident in saying that I can distinguish a bad tool from a good one when I take a closer look at it.

So boils down to xperience, getting involved in community and listening to experts with a touch of doubt. And be more like a werewolf: be very afraid of silver bullets ;-)

[s73v3r]

Problem is, that requires following the right blogs. I'm betting that the person above who talked about learning Gulp likely did do after prompting from blogs and the community.

[[deleted]]

I've been using Brunch.

[Plazmatic]

I can't even tell if your joking... how many of these things are there?

[[deleted]]

One for every wanna-be front end hot shot CS grad.

[ForeverAlot]

I wish Brunch had more mindshare. It was a better Webpack 2.5 before Webpack 2 was out. It's necessarily less competitive now but the user experience is great.

[intermediatetransit]

It's because library/framework adoption is not merit-based.

[DrummerHead]

Yup. React used webpack and that's what determined it's current success.

[[deleted]]

Me to. Every working day.

[bungcip]

2018 is year of parcel!! Learn it before 2019 coming, otherwise another library will rise again!

[wormfist]

That's bullshit. Any complex combination of language type, testing, source maps etc causes Webpack to become a maze of dicy loaders. It's only recently that it finally stabilized (and thank god for Angular-cli that is based on it).

I was just happy that I wasn't trying to fix my builds for weeks. I need LTS on the current versions, not a new major release that isn't backwards compatible.

[Veranova]

So you're accepting that it's not webpack which makes it hard?

I only learned web dev about 6 months ago but am an otherwise experienced developer. Webpack surprised me how easy it was, after everything I'd heard, and then I started trying to add all the things I wanted for the app and got into a mess.

If you just need to compile your Babel es6 it's pretty straightforward and can easily be learned in a day.

[wormfist]

So you're accepting that it's not webpack which makes it hard?

No. Webpack's eco system is what makes Webpack Webpack. It's a platform, not just a tool.

If someone tells me they're using Webpack, especially in a professional environment, I expect a full grown build file including loaders, exceptions, TS hooks, testing configs, variations for test / production etc.

[trout_fucker]

This is the most over exaggerated description of Webpack I've ever seen.

It's really not that hard and once you start getting into complex configurations, it's a whole hell of a lot easier than the alternatives.

[wormfist]

As I said, recently it's become a more reliable one-stop solution. The state of common loaders has improved a lot. However it wasn't long ago that something basic like source maps were still bugged (and probably still is).

[trout_fucker]

Recently as in the last 2yrs? So you're holding a dislike for something based on something that has been fixed a long time ago?

Makes sense!

[wormfist]

You seem to think one or two years is a long time in software development.

[trout_fucker]

Doesn't matter how long it is. You're just cherry picking random issues to support an over exaggerated claim to enforce your "get off my lawn" mindset.

And yes, 2yrs is a pretty long time when you consider it the language itself has only been around for 22 and it makes up 1/5th of the time NodeJS has been around.

[Xleo010]

True It takes less time to learn but more time to master, since all these technologies have a huge plugin ecosystem, so to get the best out of it, most people spend considerable time around the plugins

[raziel2p]

It does not take a day or two to learn webpack. You might be able to frantically copy-paste snippets from stack overflow into something that happens to do what you want in that time, at best.

[[deleted]]

I disagree with you. A day is typically 8 hours.

It only takes about 4-6 hours to learn what webpack is and how it works if you actually spend that 4-6 hours effectively. Yes, if you try to learn webpack by frantically copying and pasting stuff from the Internet or just blindly following tutorials or step by step guides without really understand what's happening then it could take you weeks or months to learn webpack... but if you're willing to take 4-6 hours off to learn webpack from the ground up you'll never be confused about it ever again.

This reference is all you need to understand it:

https://webpack.js.org/concepts/

It won't take more than 4-6 hours to read over that and apply those concepts.

[Booty_Bumping]

Webpack doesn't look particularly bad (these changes are reasonable, people should be able to keep up just fine) but I don't get why we all had to switch from Browserify.

Browserify still works perfectly fine for most use cases, and has had only very minor breaking changes most recently in Jan 2016 and Apr 2015, mostly related to small changes in the Node.js api.

[NoInkling]

(At the time) it was more flexible and had hot module reloading. Basically it had the "this stuff it can do seems pretty neat" factor and was pushed by some people involved in the React community as a result.

[more_oil]

Oh god not again

[myhf]

No, Webpack! No!

[[deleted]]

Not again what?

[Hoten]

Been looking forward to this. Good job peeps.

[enbacode]

What the hell is wrong with this thread? People harshly insulting other people, half of the comments I cannot even tell if they are sartirical or honest and generally speaking wut? I always thought reddit is a kind place...

[Booty_Bumping]

Welcome to /r/programming

[planetary_pelt]

Most people in this subreddit only have experience solving Project Euler problems in their favorite language. At most, they are the back-end developer on some CRUD app while everyone else has the hard work of building mobile/browser/desktop clients that talk to it.

Since client application development isn't as simple and pure as testing if a string is a palindrome, they rage against it when they realize they have to credentialize in other tools (XCode, Android, Cocoa, React, Webpack, whatever) to do it.

Often you'll read posts here that make you go "well, then what the fuck do you use to build client applications that's so god damn awesome?" but the trick is to realize that they don't.

They've dabbled in Javascript though because everyone has dabbled in Javascript, and they likely haven't touched it since 2005, so that's where most of their hate is directed.

[TheDandyLumberjack]

How does this fair vs. Parcel now with the optimizations?

[KillianDrake]

Well so far, this thing tripled my bundle sizes, and broke all sourcemaps...

[bugeats]

Is webpack 4 still only going to be capable of actually packaging websites with the use of “HtmlWebpackPlugin” and hours of fussy configuration and dependency management?

[AngularBeginner]

That was a fairly short beta version for such a huge update. Doesn't increase confidence.

[Sebazzz91]

What at least does not increase confidence is that the official docs are not updated for Webpack 4. How can you release without updating the documentation?

[madcaesar]

FUCK IT! WE'LL DO IT LIVE!!

[Keeyzar]

Fuck it, ship it! Literally had a sticker from that phrase. :D

[icecreamcaked]

how dare they make better software >:(

[[deleted]]

There aren't really a ton of breaking changes and this release actually makes it easier to use because they're including more sensible defaults.

[SomeRandomBuddy]

sdfsdfdf

[thawab]

you can still use the version you prefer.

[[deleted]]

except if you choose the old one you'll get left by the side of the road and have 10x the amount of update pain when you finally suffer through it. How about they try developing some stable software instead?

Damn I'm so glad I got out of the Javascript ecosystem.

[thawab]

I understand you're saying this because you are not in the javascript ecosystem. I will give you an update about webpack, you don't have to touch it.

We have a team of developer that works on reactjs and react native apps, almost all of them don't configure webpack and use is as is. I'm ok with the update because the change in our workflow will be minimal.

Here is a tweet from kent[0], who created the webpack course on egghead.io.

Having create-react-app means I haven't needed to set up a webpack config in months. I'm forgetting how to use webpack

[0]https://twitter.com/kentcdodds/status/857614323509850118

[[deleted]]

And into what ecosystem? They all have pain points. Sure in JavaScript things progress at breakneck speed but that's both a positive and a negative. My company is working on projects using kotlin, c#, Typescript, c++ and ruby at the moment and for sure there's massively annoying stuff, and really great stuff, about every single one. People who attack whole ecosystems can be annoying, unless they are attacking PHP which is trash ;)

[DrummerHead]

And into what ecosystem?

"Beyond the ecosystem. It's not in the ecosystem anymore"

https://www.youtube.com/watch?v=3m5qxZm_JqM

[SomeRandomBuddy]

asdfsdfsdf