Parcel: Fast, zero configuration web application bundler • Hacker News Board

Re: Parcel: Fast, zero configuration web application bundler

#31

Post by cjhanks » Tue, Jul 17, 2018, 6:23 AM UTC

yzmtf2008 wrote: post #28

cjhanks wrote: post #23

Earlier quoted context omitted.

If you do absolutely zero instruction optimization or re-ordering. Literally mapping the BNF grammar to a syntax tree capable of simple syntactic reduction... I would be surprised if it did not lag behind disk read speeds. Traversing that tree to remove unambiguous dead branches seems pretty clear. Perhaps if you get into a tricky manipulation between strings and syntax you could add a little runtime...

If you do absolutely zero instruction optimization or re-ordering, JavaScript takes 0 seconds to compile, and you can use almost-complete feature set of ES6. /s Come on man, that's beyond the point. Just because JavaScript needs to be compiled, doesn't mean it has a worse experience than compiling C++.

Instruction optimization is procedure of measuring expected CPU latency given the expected current state to identify which instruction set transition is optimal for the CPU. It would not be applicable to JavaScript unless I missed something.

Instruction ordering is largely bound to instruction pipelining and the estimation of CPU instruction transitioning to reduce latency. Given that V8 uses some degree of virtual indirection... I don't think that's possible in JavaScript.

Re: Parcel: Fast, zero configuration web application bundler

#32

Post by yoz-y » Tue, Jul 17, 2018, 6:23 AM UTC

bradknowles wrote: post #12

IMO, the fact that 1726 modules is a “reasonable” number for a web app is a clear indication that there is something seriously wrong with this process.

I think the JavaScript ecosystem needs something akin to Boost. I do not like using Boost in C++, however the way their libraries are built and integrated into standard is awesome.

Re: Parcel: Fast, zero configuration web application bundler

#33

Post by crooked-v » Tue, Jul 17, 2018, 6:25 AM UTC

bradknowles wrote: post #12

IMO, the fact that 1726 modules is a “reasonable” number for a web app is a clear indication that there is something seriously wrong with this process.

That's the result of JS lacking anything resembling a standard library. Just look at how long it took just for Object.entries to make its way into the language.

Re: Parcel: Fast, zero configuration web application bundler

#34

Post by tomnipotent » Tue, Jul 17, 2018, 6:26 AM UTC

cjhanks wrote: post #26

tomnipotent wrote: post #16

Earlier quoted context omitted.

Oh no! One language has a build process and toolchain... We should clearly throw everything else out and just use this one hammer for everything! /s Believe it or not, some people have problems in domains with contexts that have nothing to do with yours and the things they come up with are equally valid solutions.

It is not a question of C++ being better than JavaScript or vice-versa in some esoteric sense. Compiling code from C++ to WASM is counter-productive if the native JavaScript is fine. It's just that native languages seem to perform quite a bit better in the domains of graph construction, graph optimization, and even basic string manipulation.

> Compiling code from C++ to WASM is counter-productive

When did WASM come into the picture? I use Parcel because my time is valuable and I don't want to master the arcane arts of modern JS build toolchains but I still NEED to benefit from them if I'm to run a successful business and make sure my investors get their money back and a language I can deliver plain text over HTTP/S that runs performantly across billions of devices that I can modify on the fly is beyond valuable.

> native languages

C++ isn't going to help me deliver my product to my customers in any measurable way that influences the outcome of our relationship. JavaScript, frankly, does - the less time my organization spends writing code, the less we have to charge for things to make up for that margin impact.

Re: Parcel: Fast, zero configuration web application bundler

#35

Post by mattbreeden » Tue, Jul 17, 2018, 6:29 AM UTC

I hate doing javascript. I have no desire to attempt to understand or mess with JS or build systems past the bare minimum I can manage to get a project working so I can move on with my life.

So I tried using this. It was nice while what I was doing fit inside of everything that was default settings and/or what maintainers used. As soon as I stepped outside of that I ran into things like having to hope someone implemented a Parcel plugin for some random transform (an issue that applies to Webpack, too, but Webpack has so many more users that you're guaranteed someone actually did make one that actually works correctly), or: https://github.com/parcel-bundler/parcel/issues/645. Having an issue on something as popular as Bootstrap 4 be open for 6+ months is pretty frustrating. I spent several hours flailing at this issue to no avail.

I switched to Webpack 4 and had all of my existing build system and some additional niceties working in <45 minutes.

Re: Parcel: Fast, zero configuration web application bundler

#36

Post by crooked-v » Tue, Jul 17, 2018, 6:29 AM UTC

The main complication remaining with Parcel, IMO, is one that mostly derives from the syntax being used: there's no clear way to separate "I want this file to be added to the bundle, and a string URL for it" and "I want the appropriate representation of this file's contents".

My line of thought here is helper methods in an empty package namespace, so that they only exist at build time and are stripped out in the result.

Re: Parcel: Fast, zero configuration web application bundler

#37

Post by mattbreeden » Tue, Jul 17, 2018, 6:31 AM UTC

ivanfon wrote: post #18

Is something really wrong with WebPack? Didn’t we decide that we want more modularity and plugins, instead of “zero configuration” solutions that lock you into a few technologies? What about the next hip new frameworks that release in the future? Will they just be piled into parcel, or will they add a plugin system? This seems like an unsustainable model.

> or will they add a plugin system?

https://parceljs.org/plugins.html

Re: Parcel: Fast, zero configuration web application bundler

#38

Post by alex_suzuki » Tue, Jul 17, 2018, 6:33 AM UTC

yoz-y wrote: post #32

bradknowles wrote: post #12

IMO, the fact that 1726 modules is a “reasonable” number for a web app is a clear indication that there is something seriously wrong with this process.

I think the JavaScript ecosystem needs something akin to Boost. I do not like using Boost in C++, however the way their libraries are built and integrated into standard is awesome.

Wasn't that jQuery?

Re: Parcel: Fast, zero configuration web application bundler

#39

Post by cjhanks » Tue, Jul 17, 2018, 6:36 AM UTC

tomnipotent wrote: post #34

cjhanks wrote: post #26

Earlier quoted context omitted.

It is not a question of C++ being better than JavaScript or vice-versa in some esoteric sense. Compiling code from C++ to WASM is counter-productive if the native JavaScript is fine. It's just that native languages seem to perform quite a bit better in the domains of graph construction, graph optimization, and even basic string manipulation.

> Compiling code from C++ to WASM is counter-productive When did WASM come into the picture? I use Parcel because my time is valuable and I don't want to master the arcane arts of modern JS build toolchains but I still NEED to benefit from them if I'm to run a successful business and make sure my investors get their money back and a language I can deliver plain text over HTTP/S that runs performantly across billions…

What do you want me to say? Maybe you have reading comprehension issues?

Re: Parcel: Fast, zero configuration web application bundler

#40

Post by Jasper_ » Tue, Jul 17, 2018, 6:39 AM UTC

I spent the day finally adding a modern build system / bundler to my side project, and I chose Parcel. Parcel is really cool! I really wish they'd stop calling it "zero-configuration". It has configuration options (--out-dir, --public-url), there's just no configuration file for them. I really wish they would make one, since it's annoying to have your configuration be hidden in a batch file.