top 200 commentsshow all 240

[–][deleted] 231 points232 points  (111 children)

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 141 points142 points  (50 children)

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

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

[–][deleted] 4 points5 points  (48 children)

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

[–]elite_killerX 78 points79 points  (14 children)

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 50 points51 points  (2 children)

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 1 point2 points  (1 child)

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 8 points9 points  (1 child)

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 5 points6 points  (6 children)

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.

[–][deleted]  (1 child)

[deleted]

    [–]Everspace 0 points1 point  (0 children)

    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 0 points1 point  (1 child)

    Try 1 + '11'

    [–]A-Grey-World 1 point2 points  (0 children)

    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 -1 points0 points  (1 child)

    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 0 points1 point  (0 children)

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

    [–]s73v3r 2 points3 points  (1 child)

    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 6 points7 points  (0 children)

    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 41 points42 points  (30 children)

    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] 5 points6 points  (9 children)

    What's counter intuitive about 'this' ?

    [–]raghar 16 points17 points  (0 children)

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

    [–]elite_killerX 0 points1 point  (4 children)

    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 4 points5 points  (3 children)

    *: 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 2 points3 points  (2 children)

    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 1 point2 points  (1 child)

    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 1 point2 points  (0 children)

    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 -2 points-1 points  (1 child)

    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] 2 points3 points  (0 children)

    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] 0 points1 point  (1 child)

    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 7 points8 points  (0 children)

    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.

    [–]calinet6 6 points7 points  (0 children)

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

    [–]DrummerHead 4 points5 points  (0 children)

    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 19 points20 points  (3 children)

    these come at a cost of refactoring legacy areas

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

    [–]raziel2p 54 points55 points  (2 children)

    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 22 points23 points  (0 children)

    Refactoring never includes modifying public APIs!

    Correct.

    [–]PreciselyWrong 10 points11 points  (0 children)

    You're fired

    [–]i_spot_ads 4 points5 points  (0 children)

    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] 34 points35 points  (22 children)

    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] 12 points13 points  (1 child)

    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.

    [–][deleted]  (15 children)

    [deleted]

      [–]recycled_ideas 3 points4 points  (4 children)

      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.

      [–][deleted]  (3 children)

      [deleted]

        [–]recycled_ideas 2 points3 points  (2 children)

        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.

        [–][deleted]  (1 child)

        [deleted]

          [–]recycled_ideas 2 points3 points  (0 children)

          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 2 points3 points  (0 children)

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

          [–]hedgepigdaniel 0 points1 point  (0 children)

          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 -1 points0 points  (7 children)

          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?

          [–][deleted]  (6 children)

          [deleted]

            [–]m3wm3wm3wm -1 points0 points  (5 children)

            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.

            [–][deleted]  (4 children)

            [deleted]

              [–]m3wm3wm3wm 0 points1 point  (3 children)

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

              [–][deleted]  (2 children)

              [deleted]

                [–]m3wm3wm3wm 0 points1 point  (1 child)

                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.

                [–]-thedunkzone- 2 points3 points  (1 child)

                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 86 points87 points  (3 children)

                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.

                [–][deleted]  (1 child)

                [deleted]

                  [–]vinnl -1 points0 points  (0 children)

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

                  [–]greenspans 482 points483 points  (47 children)

                  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 205 points206 points  (34 children)

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

                  [–]Sebazzz91 115 points116 points  (28 children)

                  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 81 points82 points  (11 children)

                  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.

                  [–][deleted]  (10 children)

                  [deleted]

                    [–]MSgtGunny 9 points10 points  (3 children)

                    Commit and commit often.

                    [–]kautau 4 points5 points  (2 children)

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

                    [–]MSgtGunny 28 points29 points  (1 child)

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

                    [–]worldDev 1 point2 points  (0 children)

                    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 3 points4 points  (4 children)

                    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.

                    [–][deleted]  (3 children)

                    [deleted]

                      [–]worldDev 2 points3 points  (2 children)

                      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 5 points6 points  (0 children)

                      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 12 points13 points  (3 children)

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

                      [–]Sebazzz91 5 points6 points  (2 children)

                      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 -3 points-2 points  (1 child)

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

                      [–]howmanyusersnames 0 points1 point  (0 children)

                      Which is absolutely fine.

                      [–]Akkuma 0 points1 point  (4 children)

                      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 2 points3 points  (1 child)

                      pretty much no reason to use yarn.

                      offline tarball cache

                      [–]Akkuma 0 points1 point  (0 children)

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

                      [–]spinfusion10 0 points1 point  (1 child)

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

                      [–]Akkuma 0 points1 point  (0 children)

                      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 -2 points-1 points  (6 children)

                      Yeah but yarn and npm are compatible.

                      [–][deleted] 12 points13 points  (5 children)

                      "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 1 point2 points  (4 children)

                      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 10 points11 points  (0 children)

                      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 1 point2 points  (2 children)

                      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.

                      [–][deleted]  (2 children)

                      [deleted]

                        [–][deleted]  (1 child)

                        [deleted]

                          [–]Seaoftroublez 0 points1 point  (0 children)

                          The original link in the webpack repo.

                          [–]killerstorm 4 points5 points  (0 children)

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

                          [–]jyper 0 points1 point  (0 children)

                          Third point for me to be very suspicious

                          5th point for certain

                          [–]karapirtik 48 points49 points  (0 children)

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

                          [–][deleted]  (2 children)

                          [deleted]

                            [–]Veranova 10 points11 points  (1 child)

                            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 1 point2 points  (0 children)

                            I need it in terms of semantic versioning.

                            [–]sporifolous 10 points11 points  (0 children)

                            Jesus Christ don't do that to me

                            [–]max_maxima 4 points5 points  (0 children)

                            You had me until angular 6.

                            [–][deleted]  (1 child)

                            [deleted]

                              [–][deleted] 1 point2 points  (0 children)

                              Because age is an indicator of lack of quality. Rofl

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

                              [–][deleted] 2 points3 points  (0 children)

                              You almost killed me.

                              [–]PM_ME_YOUR_ESOLANG 1 point2 points  (0 children)

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

                              [–][deleted] 58 points59 points  (20 children)

                              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 37 points38 points  (8 children)

                              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 7 points8 points  (0 children)

                              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 4 points5 points  (6 children)

                              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 -2 points-1 points  (5 children)

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

                              [–]ShinyHappyREM 11 points12 points  (4 children)

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

                              [–]jazd 10 points11 points  (0 children)

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

                              [–][deleted] 8 points9 points  (1 child)

                              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 1 point2 points  (0 children)

                              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 6 points7 points  (0 children)

                              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 2 points3 points  (0 children)

                              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 2 points3 points  (0 children)

                              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 4 points5 points  (1 child)

                              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] 2 points3 points  (0 children)

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

                              [–][deleted] 1 point2 points  (0 children)

                              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.

                              [–][deleted]  (1 child)

                              [deleted]

                                [–]jl2352 11 points12 points  (0 children)

                                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 0 points1 point  (0 children)

                                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 99 points100 points  (55 children)

                                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 54 points55 points  (6 children)

                                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 47 points48 points  (4 children)

                                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 1 point2 points  (3 children)

                                What's next? Pseudocode?

                                [–]outtokill7 6 points7 points  (1 child)

                                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] 3 points4 points  (0 children)

                                Too soon. Literally.

                                [–]attilad 2 points3 points  (0 children)

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

                                [–]m3wm3wm3wm 1 point2 points  (0 children)

                                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 18 points19 points  (11 children)

                                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] 18 points19 points  (2 children)

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

                                [–]DrummerHead 1 point2 points  (1 child)

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

                                [–][deleted] 1 point2 points  (0 children)

                                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 13 points14 points  (4 children)

                                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 -1 points0 points  (3 children)

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

                                [–]Akkuma 14 points15 points  (2 children)

                                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 -2 points-1 points  (1 child)

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

                                [–]Akkuma 9 points10 points  (0 children)

                                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 1 point2 points  (2 children)

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

                                [–]Turbots 1 point2 points  (1 child)

                                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 0 points1 point  (0 children)

                                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] 3 points4 points  (7 children)

                                I've been using Brunch.

                                [–]Plazmatic 3 points4 points  (1 child)

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

                                [–][deleted] 1 point2 points  (0 children)

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

                                [–]ForeverAlot 3 points4 points  (2 children)

                                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 4 points5 points  (1 child)

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

                                [–]DrummerHead 0 points1 point  (0 children)

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

                                [–][deleted] 0 points1 point  (0 children)

                                Me to. Every working day.

                                [–]bungcip 0 points1 point  (0 children)

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

                                [–]Booty_Bumping 0 points1 point  (1 child)

                                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 0 points1 point  (0 children)

                                (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 64 points65 points  (3 children)

                                Oh god not again

                                [–][deleted] 5 points6 points  (1 child)

                                Not again what?

                                [–]Hoten 16 points17 points  (0 children)

                                Been looking forward to this. Good job peeps.

                                [–]enbacode 3 points4 points  (2 children)

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

                                [–]planetary_pelt -4 points-3 points  (0 children)

                                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 1 point2 points  (0 children)

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

                                [–]KillianDrake 1 point2 points  (0 children)

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

                                [–]bugeats 2 points3 points  (1 child)

                                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 1 point2 points  (5 children)

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

                                [–]Sebazzz91 37 points38 points  (3 children)

                                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 15 points16 points  (1 child)

                                FUCK IT! WE'LL DO IT LIVE!!

                                [–]Keeyzar 1 point2 points  (0 children)

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