Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Webpack 2, RC 4

github.com

Post reply on HN
Print view View original

11–20 of 24 posts

Re: Webpack 2, RC 4

#11

Post by dvcc »

seniorsassycat wrote: post #8

I recently setup a typescript > webpack project and I was really disappointed with the dev-tools debugging experience. Webpack renames imported bindings, so import {foo} from './bar'; becomes something like this let __webpack_require_foo_bar = _webpack_modules[5 /* foo */].bar; So if you are paused in the debugger and want to use foo in a watch statement, or use it in a computation you'll have to reference the real s…

Doesn't this have more to do with Babel and less to do with Webpack? I think this originates with how Babel treats ES6 Modules differently from CommonJS, and if you were to instead do:

  const foo = require('./bar').foo
it would keep the name the same?

EDIT: https://github.com/jamietre/babel-plugin-transform-es2015-mo...

There is a better explanation with a partial solution.

Re: Webpack 2, RC 4

#12

Post by simplify »

k__ wrote: post #3

I tried the dynamic import/require once and it was really nice. I could just write a normal SPA and require some stuff in every route, so the client only downloads the code that is used for the current page and things worked fine without extras needed.

That almost sounds like server-side rendering :)

Re: Webpack 2, RC 4

#13

Post by saosebastiao »

seniorsassycat wrote: post #8

I recently setup a typescript > webpack project and I was really disappointed with the dev-tools debugging experience. Webpack renames imported bindings, so import {foo} from './bar'; becomes something like this let __webpack_require_foo_bar = _webpack_modules[5 /* foo */].bar; So if you are paused in the debugger and want to use foo in a watch statement, or use it in a computation you'll have to reference the real s…

Stuff like this is the reason the Unix Philosophy of small "composable" tools doesn't work in this ecosystem. Because if you run your code through three different preprocessor steps, everything breaks and your source maps aren't even close to usable anymore, so you can't debug anymore.

I've been campaigning for more of a monolithic design in the TS ecosystem. Not that the architecture of the TS compiler needs to be monolithic, but rather that TS users should have a blessed and supported stack for everything. We should be able to rely on TS components for linking/packaging, polyfills, optimization, conditional compilation, minification, source map packaging, asset prepackaging and loading, ES6+ standards compliance, etc.

But since advocating for anything rhyming with -olith is heresy in the programming world, I'm not confident we'll get there.

Re: Webpack 2, RC 4

#14

Post by patates »

simplify wrote: post #12
k__ wrote: post #3

I tried the dynamic import/require once and it was really nice. I could just write a normal SPA and require some stuff in every route, so the client only downloads the code that is used for the current page and things worked fine without extras needed.

That almost sounds like server-side rendering :)

But SSR means you send everything around the content again and again.

Re: Webpack 2, RC 4

#15

Post by djmashko2 »

seniorsassycat wrote: post #8

I recently setup a typescript > webpack project and I was really disappointed with the dev-tools debugging experience. Webpack renames imported bindings, so import {foo} from './bar'; becomes something like this let __webpack_require_foo_bar = _webpack_modules[5 /* foo */].bar; So if you are paused in the debugger and want to use foo in a watch statement, or use it in a computation you'll have to reference the real s…

This is a big benefit of Meteor's build system - it has several improvements that make debugging more straightforward than with Webpack and default Babel import compilation.

Re: Webpack 2, RC 4

#16

Post by simplify »

patates wrote: post #14
simplify wrote: post #12

Earlier quoted context omitted.

That almost sounds like server-side rendering :)

But SSR means you send everything around the content again and again.

If each page has different dependencies, you're not sending much duplicate content. Also, SSR supports incremental rendering (due to HTTP streaming), something that is currently impossible to do with SPAs.

See this article for more detail: https://jakearchibald.com/2016/fun-hacks-faster-content/

Re: Webpack 2, RC 4

#17

Post by seniorsassycat »

dvcc wrote: post #11
seniorsassycat wrote: post #8

I recently setup a typescript > webpack project and I was really disappointed with the dev-tools debugging experience. Webpack renames imported bindings, so import {foo} from './bar'; becomes something like this let __webpack_require_foo_bar = _webpack_modules[5 /* foo */].bar; So if you are paused in the debugger and want to use foo in a watch statement, or use it in a computation you'll have to reference the real s…

Doesn't this have more to do with Babel and less to do with Webpack? I think this originates with how Babel treats ES6 Modules differently from CommonJS, and if you were to instead do: const foo = require('./bar').foo it would keep the name the same? EDIT: https://github.com/jamietre/babel-plugin-transform-es2015-mo... There is a better explanation with a partial solution .

I don't think Babel is the cause, not in this case. Im using typescript in full es6 mode, module and target are both es6. Babel isn't even in my node_modules.

Re: Webpack 2, RC 4

#18

Post by jamra »

dvcc wrote: post #11
seniorsassycat wrote: post #8

I recently setup a typescript > webpack project and I was really disappointed with the dev-tools debugging experience. Webpack renames imported bindings, so import {foo} from './bar'; becomes something like this let __webpack_require_foo_bar = _webpack_modules[5 /* foo */].bar; So if you are paused in the debugger and want to use foo in a watch statement, or use it in a computation you'll have to reference the real s…

Doesn't this have more to do with Babel and less to do with Webpack? I think this originates with how Babel treats ES6 Modules differently from CommonJS, and if you were to instead do: const foo = require('./bar').foo it would keep the name the same? EDIT: https://github.com/jamietre/babel-plugin-transform-es2015-mo... There is a better explanation with a partial solution .

Typescript doesn't need babel since the typescript compiler supports es6.

Re: Webpack 2, RC 4

#19

Post by [deleted] »

dvcc wrote: post #11
seniorsassycat wrote: post #8

I recently setup a typescript > webpack project and I was really disappointed with the dev-tools debugging experience. Webpack renames imported bindings, so import {foo} from './bar'; becomes something like this let __webpack_require_foo_bar = _webpack_modules[5 /* foo */].bar; So if you are paused in the debugger and want to use foo in a watch statement, or use it in a computation you'll have to reference the real s…

Doesn't this have more to do with Babel and less to do with Webpack? I think this originates with how Babel treats ES6 Modules differently from CommonJS, and if you were to instead do: const foo = require('./bar').foo it would keep the name the same? EDIT: https://github.com/jamietre/babel-plugin-transform-es2015-mo... There is a better explanation with a partial solution .

[deleted]

Re: Webpack 2, RC 4

#20

Post by dvcc »

jamra wrote: post #18
dvcc wrote: post #11

Earlier quoted context omitted.

Doesn't this have more to do with Babel and less to do with Webpack? I think this originates with how Babel treats ES6 Modules differently from CommonJS, and if you were to instead do: const foo = require('./bar').foo it would keep the name the same? EDIT: https://github.com/jamietre/babel-plugin-transform-es2015-mo... There is a better explanation with a partial solution .

Typescript doesn't need babel since the typescript compiler supports es6.

The 'let' should have made me re-think the problem.
Post reply on HN