What's New in Webpack 2 • Hacker News Board

Re: What's New in Webpack 2

#61

Post by wildpeaks » Tue, Feb 02, 2016, 3:08 PM UTC

matt4077 wrote: post #52

octref wrote: post #41

What's needed for Webpack 2: better documentation.

Indeed! I gave up trying to configure it to load files relative to the root and just lived with all the import '../../../lib/compents/...'. I just tried the new beta and – surprise – it works! I still think the structure of, say, Grunt is much nicer to work with – it's just code and easy to understsand & modify. Webpack has what must be the most awkward configuration file format currently in use. The website also loo…

You can use a subfolder node_modules for using simpler paths (such as "components/something" instead of "../../components/something/index.js").

For example, if your entry point is in "/src/application.js", it can require('components/something') from folder "/src/node_modules/components/something". And that works in native Node, Browserify and Webpack, so you're not tied to a specific build tool.

Any module in /src (and subfolders) first searches for modules in "/src/node_modules", but can still also load thirdparty npm-installed modules from the root "/node_modules".

Re: What's New in Webpack 2

#62

Post by [deleted] » Tue, Feb 02, 2016, 3:20 PM UTC

sotojuan wrote: post #55

For me the big thing in this version is tree shaking. I think it will change usage of JS stuff more than most people think. For example, I will use Cycle more because currently I feel bad importing all of RxJS for my toy projects.

[deleted]

Re: What's New in Webpack 2

#63

Post by Matthias247 » Tue, Feb 02, 2016, 3:39 PM UTC

k__ wrote: post #35

DCoder wrote: post #4

Earlier quoted context omitted.

Have you looked into TypeScript? Type system helps you catch even more errors.

Why not purescript or elm? I have the feeling that those Haskell like type-systems are superior to this whole Java/C# stuff.

I would guess that compatibility with existing JS libs is far easier with Typescript. You can trivially consume an existing JS lib from TS or export/compile your TS lib to pure JS, which other JS then can seamlessly consume.

Although I don't have bigger experience with Elm, Purescript, Scala.js, Ceylon, Websharper & Co I guess its more complicated with them. An advantage here is also that Typescript does not bring along it's own standard library (e.g. new collection types) which could cause problems on interoperability.

Another advantage is getting other people on board. Getting developers from pure JS to typescript is not difficult, especially when they are used to Java/C++/C# (which most developers are). The learning curve for the other languages will be higher for most developers.

Re: What's New in Webpack 2

#64

Post by s986s » Tue, Feb 02, 2016, 3:46 PM UTC

Chris_Newton wrote: post #57

s986s wrote: post #51

Earlier quoted context omitted.

I selfishly want more people like you in the javascript ecosystem. I had a debate with a freind if mine about gulp. My argument is that all of these tools are useless since they can be done without them. If only certian tasks should be run, create a commander script that takes in amount of args and runs each of those tasks. His argument is that these gulp and grunt files standardize build and test scripts. Now its so…

I guess I just don’t see what benefit is gained by writing a dozen lines of fragile boilerplate to run Browserify via Gulp. If you want to put the build automation in a well-known location, a typical Browserify+Babel build is one line in the scripts section in package.json that says something like "js": "browserify src/index.js -o dist/index.js -t [ babelify --presets [ es2015 ] ]" If you need more complicated config…

Again, I agree. Picture this: mocha gives testing globals, browser offers the window and dom, node offers process arguments. Coming from a partial teachers perspective (well, I wasnt hired to teach but I did talk to the students alot) gulp seemed to offer comfort and order in a world where "you can do anything" seems to cause imobilization. That problem I believe can be solved through introducing students to a philosophy of "you are in control, machines are dumb, only google can save you" but I can see where seperation makes people much more comfortable

Re: What's New in Webpack 2

#65

Post by hardwaresofton » Tue, Feb 02, 2016, 4:08 PM UTC

sandGorgon wrote: post #25

hardwaresofton wrote: post #21

Earlier quoted context omitted.

What's your full build/bundle time like? May be faster to just bundle the parts you need and build them (and use the compiled output). Also ensure caching is enabled for the stuff you want to cache (deps, I assume). Cachebusting is possible with systemjs. Looks like this project is a good start: https://github.com/stealjs/cache-bust Here's a quick-n-dirty fix for this same problem when working with Aurelia: https://g…

i was looking at the last issue. it seems inconclusive - I like to serve my js from CDN, so this is very very important. what is your opinion of webpack in general though ?

Ahh unfortunately I don't one worth sharing -- I've only used webpack once, most other projects (big or small) I've worked on have used RequireJS, JSPM, or Ember CLI.

Also, please look at the other responses, bundling deps seems to be the definitive answer to how to speed up JSPM. Though of course your cache busting issue is separate.

Re: What's New in Webpack 2

#66

Post by rco8786 » Tue, Feb 02, 2016, 5:11 PM UTC

I'm really curious about the decision to support es6 modules here. Seems like Webpack is stepping into Babel's territory, but I'm not sure to what end?

Re: What's New in Webpack 2

#67

Post by sandGorgon » Tue, Feb 02, 2016, 5:41 PM UTC

hardwaresofton wrote: post #65

sandGorgon wrote: post #25

Earlier quoted context omitted.

i was looking at the last issue. it seems inconclusive - I like to serve my js from CDN, so this is very very important. what is your opinion of webpack in general though ?

Ahh unfortunately I don't one worth sharing -- I've only used webpack once, most other projects (big or small) I've worked on have used RequireJS, JSPM, or Ember CLI. Also, please look at the other responses, bundling deps seems to be the definitive answer to how to speed up JSPM. Though of course your cache busting issue is separate.

so im a little confused. coming from the Rails world I thought cache busting was pretty fundamental.. especially if you want to use CDN.

Is this not baked into every build tool out there ? How does one take care of caching while serving assets .. or is the general philosophy of JS right now around SPA (so dont care to cache) ?

Re: What's New in Webpack 2

#68

Post by hardwaresofton » Tue, Feb 02, 2016, 6:41 PM UTC

sandGorgon wrote: post #67

hardwaresofton wrote: post #65

Earlier quoted context omitted.

Ahh unfortunately I don't one worth sharing -- I've only used webpack once, most other projects (big or small) I've worked on have used RequireJS, JSPM, or Ember CLI. Also, please look at the other responses, bundling deps seems to be the definitive answer to how to speed up JSPM. Though of course your cache busting issue is separate.

so im a little confused. coming from the Rails world I thought cache busting was pretty fundamental.. especially if you want to use CDN. Is this not baked into every build tool out there ? How does one take care of caching while serving assets .. or is the general philosophy of JS right now around SPA (so dont care to cache) ?

Caching is definitely important for front end tooling, but it depends on which tooling you're having perform the job. It is also generally considered a deployment worry. Cache busting can be implemented in various ways-- by using a templating language (ex. ERB), by using a build tool like grunt/gulp, by using you JS bundler, or by using your module resolver (in the case that the bundler and resolver are not the same entity).

JSPM just doesn't take a built-in stance on it (as of now, as I noted there is a ticket to get it included), but it certainly is configurable enough to allow you to add cache busting (by changing the loader). Not trying to apologize for JSPM -- it would certainly be better if they had some sort of cache busting option that was easily available and obvious.

I think the thought here is that when you're ready to push to production, and you build your actual bundle, you name that file whatever you need to to bust caches.

Re: What's New in Webpack 2

#69

Post by quaffapint » Tue, Feb 02, 2016, 6:55 PM UTC

For people in corporate environments that can't run webpack/browserify are there any standalone tool alternatives?

Re: What's New in Webpack 2

#70

Post by pgz » Fri, Feb 05, 2016, 5:24 PM UTC

pgz wrote: post #11

sandGorgon wrote: post #8

has anyone used systemjs + jspm here ? I inherited a codebase using jspm (due to the override registry system that works great with legacy javascript packages - like Handsontabe) and am wondering about webpack.

We are using jspm on an inherited codebase that was concatenated "by hand" with Rails' asset-pipeline (it has lots of old libraries and the overrides are very good to handle them). What we hate is jspm is extremely slow in development for us. There are two main causes: - The amount of xhr. This is solvable with http2's server push (but our dev server is in Ruby, and there's no http2 webserver yet). - Apparently jspm…

We solved this with https://github.com/jackfranklin/jspm-dev-builder

It's so fast now.