GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-12-05) - page 1 of 10
 
___________________________________________________________________
Parcel - A fast, zero configuration web application bundler
223 points by KeitIG
https://parceljs.org/
___________________________________________________________________
 
xchaotic - 1 hours ago
Explain to me why do we web app need bundlers?
 
  GijsjanB - 9 minutes ago
  I long for the day I can use browser native import to retrieve
  all my modules and deps, but at this point it doesn't resolve
  node_modules and that makes it unusable to me and the reason I am
  using a bundler.
 
stevefan1999 - 4 hours ago
The two coolest things about Parcel for me, are 1) multi-core
support, and 2) a simpler, ES6-esque API. Without these two
distinct elements, I think Parcel is nothing more than a simple
Webpack boilerplate which could easily been generated by yeoman.I
see its potential regarding Parcel?s competitiveness against
Webpack, but it also has worsen the JavaScript fatigue, which is
considered a nightmare for many newcomers webdevs because of huge
fragmentation and thus bigotry in the industry.
 
bovermyer - 3 hours ago
I am not the target audience for this.However, my first reaction
was "yet another build tool, huh?"My next thought was "...I must be
getting old."
 
  ardi93 - 25 minutes ago
  Wait for another 6 months, and we may have "yet another build
  tool" again
 
  desireco42 - 3 hours ago
  You might be getting old, but you are still of sound mind :)
 
thrownaway954 - 4 hours ago
how does this handle existing 3rd party jquery plugins? The single
biggest problem and configuration nightmare I always face is
bundling something like CKeditor.
 
stupidcar - 4 hours ago
The eternal cycle of developer tool bullshit:1. "Ugh, OldTool?
v3.0.0 is overcomplicated, bloated, slow and unnecessarily
configurable!"2. "Introducing SuperTool? v1.0.0, which just does
the stuff you really need. No bloated configuration. No huge
ecosystem of extensions. Simple, straightforward and fast."3.
"SuperTool? v1.0.0 is great! But our setup really needs it to do
something a bit different, so we've hacked in this
extension."...repeat for a while...10. "Introducing SuperTool?
v2.0.0, which now has a more flexible API and configuration ,
allowing many former hacks to be done in a straightforward way."11.
"SuperTool? v2.0.0 is great! But our setup really needs it to do
something a bit different, so we've hacked in this
extension."...repeat for a while...20. "Introducing SuperTool?
v3.0.0, with a whole new, flexible, pipeline based API. Everything
is a plugin! There's even a plugin to send email!"21. "Ugh,
SuperTool? v3.0.0 is overcomplicated, bloated, slow and
unnecessarily configurable!"22. "Introducing HyperTool? v1.0.0,
which just does the stuff you really need. No bloated
configuration. No huge ecosystem of extensions. Simple,
straightforward and fast."
 
  amazingman - 3 hours ago
  The cycle described here is perfectly acceptable in principle,
  not to mention unavoidable in practice. Our developer tools will
  stop changing when humans stop changing.
 
    brucephillips - 10 minutes ago
    Not really.  Fragmentation is only inevitable when there exist
    feature tradeoffs.  If Parcel's advantage is parallelism and
    caching, it's possible those features could have been added to
    Webpack.
 
    [deleted]
 
  chatmasta - 3 hours ago
  God forbid we improve existing tools. What exactly is your
  problem here? Do you think we should all be using the Borland C++
  compiler too?
 
    icholy - 3 hours ago
    Change != Improvement.
 
      eikenberry - 48 minutes ago
      Change + Time == Improvement
 
      chatmasta - 3 hours ago
      Does the release of parcel mean you can no longer use
      webpack, or gulp, or grunt or whatever you?re using now?If
      you don?t like a new tool, don?t use it. I can?t stand this
      kind of meritless complaints. If you?ve got a problem with
      the implementation of a new tool, that?s understandable. But
      to take issue with its existence? That?s just petty and a
      waste of everyone?s time.
 
        coldtea - 1 hours ago
        >Does the release of parcel mean you can no longer use
        webpack, or gulp, or grunt or whatever you?re using now?If
        it takes away from their community and momentum, then
        yes.Attention in FOSS is close to a zero-sum game.Not to
        mention when the devs themselves get bored with tool X
        they've created and jump to creating some newer tool Y,
        dropping the whole community...
 
          hk__2 - 56 minutes ago
          > Not to mention when the devs themselves get bored with
          tool X they've created and jump to creating some newer
          tool Y, dropping the whole community...Given that you
          don?t pay for the product I don?t see anything wrong
          here. People work on what they want then change if
          they?re bored; you can?t do anything about that but pay
          them to continue supporting the tool you decided to use.
 
          brucephillips - 5 minutes ago
          > you can?t do anything about thatYou can.  You can
          encourage developers to contribute to a single project,
          rather than create fragmentation, which is exactly what's
          happening in this forum.
 
          transpostmeta - 56 minutes ago
          Oh, so if you don't pay for a tool you can't control the
          development of it? How unexpected!
 
        lhorie - 2 hours ago
        Agreed. It's more like Competition == Improvement
 
      joekrill - 1 hours ago
      But also:Change != !ImprovementSo I'm not seeing the point
      here.
 
  SadWebDeveloper - 4 hours ago
  Welcome to developing in 2016-201X, were you spend 60% of your
  time configuring tooling, 35% developing test and 5% developing
  your app.
 
    hannofcart - 2 hours ago
    Sounds good to me. If I could spend 60 hours on developing the
    initial tooling, and if I could spend just 5 hours writing
    minimal code to get things working as I want, and spend the
    rest of the 35 hours on testing and making everything
    watertight, I'd call it a job well done.
 
      [deleted]
 
    djstein - 4 hours ago
    35% developing tests? What great institution do you work for?
 
      IanCal - 4 hours ago
      Depends if they're talking about adding tests or battling
      tests/test frameworks to just get something out.
 
      je42 - 4 hours ago
      90% developer tests here
 
      SadWebDeveloper - 3 hours ago
      Slack /s
 
    borellvi - 4 hours ago
    Have you ever tried a tool like
    https://github.com/facebookincubator/create-react-app ? It
    makes your comment totally irrelevant.
 
      Boxxed - 4 hours ago
      Unfortunately the whole world isn't developing a react app.
      And the fact that create-react-app even exists is definitely
      proving the point!
 
        borellvi - 4 hours ago
        Is not about React, it is about tools that makes our life
        easier. If you want you can stick to ES5, no frameworks, no
        tools but good luck scaling your app to work with a big
        teams.
 
          lhorie - 3 hours ago
          IMHO, unless your company is also working on a tool like
          Bazel or Buck, you don't really have a team scalability
          problem.
 
          notheguyouthink - 3 hours ago
          Yea, as a user of CRNA (create react native app) with a
          moderately simple app, dependency hell is something we're
          already in. We don't see a choice, for reasons, but CNRA
          is definitely not somehow above these problems.Node/JS in
          general has a pretty terrible track record for me with
          version hell.
 
          tropshop - 3 hours ago
          Strong technical leadership and defining clear code
          boundaries is the secret sauce to scaling successfully.
          The shiniest tooling will not save your team.
 
    at-fates-hands - 3 hours ago
    THIS.I used to love writing code and building stuff from
    scratch. Nowadays it's exactly what you said. I spend more time
    configuring stuff and finding tools that work well together
    than actually writing the underlying code that makes the app or
    the website work.
 
      cortesoft - 2 hours ago
      How about you don't do that, then? What is stopping you from
      developing things like you used to? Those older tools still
      work.
 
        SadWebDeveloper - 2 hours ago
        Go try to find a job that doesn't require any of the new
        tooling experience or look at the other extreme... looks
        for those asking 15-years proven experience of Cobol.
 
    awalton - 4 hours ago
    Cute that you think this started in 2016...
 
      SadWebDeveloper - 3 hours ago
      To be fair, i originally wanted to put 2010 but there are so
      many butthurt nodejs fans that will get easily offended.
 
    nip - 4 hours ago
    Or stick to something that works for you and keep using the
    same tool over and over again.No one is forcing you to use the
    latest bundler / tool / programming language.  Let others
    experiment.  You?ll be happy to reap the benefits of their work
    when something mature comes out of it.
 
      weego - 3 hours ago
      I agree in a lot of environments, but web/js build tools seem
      to have a high frequency of fragmenting and becoming
      abandoned before any real long-term maturity is established.
 
        deoxxa - 2 hours ago
        It sure looks that way if you follow the news, but my
        webpack config has barely changed for two years now and I'm
        still getting work done.
 
      dmitriid - 2 hours ago
      > Or stick to something that works for you and keep using the
      same tool over and over again.(in JS ecosystem)1. It's really
      hard to find something that works2. It's really hard to
      figure out all the dependencies, and configs, and plugins,
      and conventions, and ..., and ... for something that works3.
      Once you have it figured out, each and every moving part,
      including the tool itself, will get updated with deprecations
      and breaking changes.
 
      SadWebDeveloper - 3 hours ago
      > No one is forcing you to use the latest bundler / tool /
      programming languageExcept everyone is using them and you get
      quickly outdated, specially if you are looking for a job with
      heavy experience on python, php and asp.net web development.
      The market already shifted to "3 Years worth of experience on
      Parcel".
 
      nathan_long - 3 hours ago
      > No one is forcing you to use the latest bundler / tool /
      programming language.Tell me that when you get turned down in
      a job interview because you don't know       year>.
 
        tropshop - 2 hours ago
        Try working on your positioning so that you are not hitched
        to the . You will forever be
        competing with the low end of the market if you cannot
        market yourself.
 
          SadWebDeveloper - 2 hours ago
          Found the MBA/project-lead guy. The moment you start
          working on management, that's the moment you stopped
          being a "developer".
 
          vlunkr - 1 hours ago
          I don't think that's the only interpretation. You can
          also work on moving into different parts of development.
          This problem exists everywhere, but is currently the most
          extreme in front-end web-app dev. Move the back end, ops,
          etc..
 
          FLUX-YOU - 51 minutes ago
          Your advice basically tells them to get out of JS
          development because businesses continually hitch
          themselves to .This stuff comes
          up in interviews. Trying to avoid answering direct
          questions about a framework and answering with "Well I
          can learn it really quickly because I'm a good vanilla JS
          Dev" doesn't fly all the time. If you can't answer direct
          questions about a framework, they will pass on you if
          they get someone who can answer those questions.It has
          nothing to do with marketing yourself.
 
  desireco42 - 3 hours ago
  I share your frustration.However, this tool actually do useful
  work, based on quick glance I made. So maybe don't discount it
  just yet.But again, I share your frustration.
 
  [deleted]
 
  wppick - 3 hours ago
  This sounds good to me. Encapsulate and simplify existing tooling
  based on the communities experience with it, then extend and add
  complexity as needed. As the development environment changes, we
  will constantly have to update our  tools to make it simple for
  the basic 80% of cases.
 
  johnwheeler - 3 hours ago
  I normally share the same sentiment unless the tooling truly is
  much better than its predecessors. This looks pretty easy to use
  and fast. If it delivers on those two promises, it's worthy of
  further consideration by the community.
 
  redler - 2 hours ago
  True, but Old, Super, and Hyper together represent a deep and
  productively adversarial exploration of the problem space -- each
  trying to best its predecessor. The overall problem space
  benefits, even as each package individually ages into senescent
  complexity.
 
  pacoverdi - 3 hours ago
  I use create-react-app and make sure I don't need to eject so (I
  guess) I use webpack under the hood, which I never had to learn.
  If CRA switches to parceljs and makes the build twice as fast,
  I'm all for it!
 
conatus - 4 hours ago
Is my career as a Webpack whisperer at an end?cries tears of joy;-)
 
  jameskegel - 4 hours ago
  Go, you're free now.
 
pbreit - 5 hours ago
Didn't see any info that would give me an impression of the
possibility if this getting any traction which I think would be
even more important than any specific benefits.
 
chickenfries - 3 hours ago
I have no problem with ditching webpack for another tool if it's
faster and of similar or better quality. Is anyone using this in
production and want to share their experiences?
 
superasn - 2 hours ago
Really happy that besides being fast they made a priority to keep
the configuration simple.I love webpack to death but there are just
so many parts that I keep getting confused, esp with things like
"!" in in require, always copy-pasting the same boilerplate code
over and over to for sass, es6, etc. I know it may be more flexible
but sometimes you just want things to work and can't be bothered
with too many details. Laravel did this with elixir where it wrote
a wrapper just to do it (which lets you just get on with your work
without having to learn another tool). This too seems to be focused
on that. Great job!
 
newsbinator - 3 hours ago
I've been using http://brunch.io and enjoying it. Far less
configuration than Webpack.
 
  desireco42 - 3 hours ago
  Definitely overlooked gem. Phoenix is using it though (Elixir web
  framework)
 
pedalpete - 1 hours ago
Is anybody running a project with webpack that has a 20s rebuild
time?Or if somebody has switched from webpack to parcel, can they
give an idea of the performance improvement?We've got a moderate
sized app, and webpack rebuild (typescript, server-side react,
client side js bundle, css export) is less than 3 seconds.
 
  cygned - 1 hours ago
  We have a React app with roughly 100k LOC and a lot of SASS that
  takes about 4 minutes now to create the bundle on my MacBook Pro
  2017.
 
    joekrill - 1 hours ago
    That's probably the initial build, though, right? If you've
    already got dev-server running and it has to rebuild, it
    shouldn't have to rebuild the entire bundle again.
 
  regecks - 1 hours ago
  Is that less than 3 seconds a production bundle (npm run build)?
 
[deleted]
 
seekbeak - 2 hours ago
I had my eye on http://fuse-box.org/ for a while, and tried a few
sample projects with it. It has a lot of the same promises as
Parcel appears to have. Multicore is exciting for me, which Fusebox
doesn't have. So... many... choices...
 
spondyl - 4 hours ago
Should main.css be included in the index.html example?This just
confused me for some reason but it's more me focusing on the wrong
thing, haha
 
  BlakePetersen - 1 hours ago
  It's injected into the main.js file which is added via index.js
  to the page
 
j4ship - 4 hours ago
why are we not just using bash scripts ???-you can log output
-perfectly capable of handling your unique build style -no setup
(pretty much) -just call the command lines of other tools like
(less.c, yui-compressor.jar ... etc) for compliation taskstalk
about over engineering. The thing is that the reason we dont have 1
to rule them all now is because no one has ever objectively argued
why one is better than the other.If we could just get command line
equilvalents for things like ember-cli that didnt require npm then
we would be good. Npm is the thing holing us back , we dont need it
to do command line processing. Its a bloated middle man. Please
command line tool gods , offer your tool outside of the javascript
eco system. Build it in java and export to jar or c and allow us to
worry about the stitchingQuestion , what is the thing
npm/grunt/gulp gives us that cannot be done with bash, if all the
tools we used were command line executables?
 
  jhurliman - 4 hours ago
  I think you may be confusing npm with something else? npm is a
  package manager, and it does run as a command line tool. Similar
  to how apt-get is the command-line frontend for a package
  ecosystem. npm also includes npx, which allows you to directly
  run any command line utility in the npm ecosystem without
  installing the package first.Try running `npx ember-cli` directly
  in your terminal.
 
    j4ship - 3 hours ago
    all you say is correct but im not confused. node and npm is
    require to run many command line tools (grunt, gulp ...etc). I
    think this is an unnecessary overhead if we could get these
    tools to just be built as standalone command line tools and
    then we can just use bash. Im asking for a particular feature
    that comes from this environment that I dont have in bash? Why
    do I need this environment.I have a sense that webpack is the
    same, its a bloated environment. I dont need an all in one
    solution for a build process. Just give me the tools, ill use
    bash and call it a day. So Im just asking, is there something
    Im missing? What is the feature from these environments that I
    can directly preform by calling a script from bash? Why cant we
    just pull that script out into a command line tool and then
    devs can use it to their liking, pipe its output to a folder,
    cat that file to soemthing else, call another tool to minify
    the results, move all the contents to the dist folder.Node just
    doesnt seem to give me any more power as a dev (build wise),
    why is it so important to the space.Hats off to frontend
    engineers, the space has evolved to something respectable but I
    feel like over engineering is a pursuit of community. Its like
    they keep making new tools, to encapsulate more features and
    then post on HN and say "Look at this cool new way to do things
    that fixes that problem you really didnt have".No ones webpack
    was bottlenecking their work, im guessing you can choose what
    to build and when so you dont have to do a full build every
    time. No one is going to choose a build system because of its
    blazing speed. I would rather not have people work on these
    problems that dont really need to be solved.
 
      octalmage - 2 hours ago
      You can totally do all of this. There are projects that just
      pipe the output of Babel into uglifyjs into a file and call
      it a day. You still ?need? to use npm to install those
      packages though. npm puts command line utilities in
      node_modules/.bin to not pollute your machine. npm just
      stores packages as tar.gz files though, so if you wanted to
      you could wget them yourself.
 
      eduren - 3 hours ago
      > npm is require to run many command line tools (grunt, gulp
      ...etc)You seem to be looking for the ability to run JS
      tooling (builders, transpilers, minifiers) as common command
      line utilities. That seems to be entirely possible and I'm
      not sure why you're making the distinction. I can pipe input
      between all of them, include them in bash scripts, make
      files, whatever else you're used to.There's no meaningful
      distinction between a "standalone command line tool" and a
      command line tool that is written in node. If I added webpack
      (for example) to an ubuntu package repository, you could do
      `apt-get install webpack`, and have a "standalone" command
      line utility without ever downloading it from npm. It would
      have to pull other ubuntu packages as dependencies, but
      that's standard practice for installing something these
      days.Unless you're wondering about packaging it into linux.
      In which case I'm just as confused as you are.
 
      orf - 44 minutes ago
      > Why cant we just pull that script out into a command line
      tool and then devs can use it to their liking, pipe its
      output to a folder, cat that file to soemthing else, call
      another tool to minify the results, move all the contents to
      the dist folder.I guess because everyone needs to do those
      steps, so why not have a single command that does it for you.
      Sure, you could write your own and have everyone maintain
      thousands of different random shell scripts all eventually
      doing the same thing, but why?
 
      manigandham - 3 hours ago
      Node is a runtime, npm is a package manager. Together they
      let you download code (js or otherwise) and run it.This is
      the same as Java (JVM), .NET (CLR), and plenty of other
      languages. You can compile to a native assembly if you like
      (similar to C++ or Go) but it's not necessary when you have
      fast runtimes and JIT compilation.Everything you listed for
      functionality is possible today - while also letting people
      write and ship code to multiple platforms quickly.
 
pier25 - 3 hours ago
I think it's super cool.I've been configuring Webpack projects for
almost 2 years now and I'd rather use Parcel tbh. My only problem
is the lack of plugins such as loading .vue files.
 
  hanley - 2 hours ago
  +1 for Vue support
 
TY - 2 hours ago
Came here to puff about "yet another bundler".Then read all of the
docs in 15 minutes and realized that I might like this.Then I used
it and I know that I'll keep using it, unless there are any
showstoppers.Great job, Devon!
 
[deleted]
 
segphault - 3 hours ago
With transitive dependencies, the total install footprint for this
is 689 packages weighing in at 77MB.This isn't reducing complexity,
it's just taking all the junk you'd normally have in your bloated
boilerplate and putting it directly into the build tool. I'm not
convinced that's a good idea.
 
  Semiapies - 2 hours ago
  I don't know about you, but that's where and what by i want
  tedious, error-prone work handled - out of my way and by the
  computer.If you have some simpler, better alternative to html,
  css, and JavaScript for websites, more power to you.  Over here
  in the real world, though, we've got stuff to do.
 
  krzkaczor - 2 hours ago
  What kind of argument is this? This won't be part of your bundle
  ? it won't increase the size of your prod build but can save your
  precious time.
 
  lojack - 2 hours ago
  Sure, its shifting complexity around, but its hard to argue that
  the API for this is more complex than the bloated boilerplate
  you're talking about. For some people the simplified API is worth
  the 77 extra MB.
 
    [deleted]
 
  hinkley - 2 hours ago
  One of the things I like about OSS and things like Stack Overflow
  is that in the old days, if I solved a hard problem, I solved it
  for a couple dozen people I worked with and maybe some folks at
  my next job.  In some cases it made it hard to justify the work
  because I saved everybody 10 minutes a month and spent a week
  working on it.  Which may be bad math for another reason: if I
  saved you the most aggravating ten minutes of your month, it may
  be worth many multiples of that ten minutes to you.If I put the
  answer on the internet, then thousands of people benefit.  If my
  work only save you five minutes one time, it still may be worth
  the bother in the grand scheme of things.Which is a long way
  around to my point: this group is curating a bunch of build
  related modules which means I don't have to pay as much
  attention.  That's not automatically a win (especially if they do
  a poor job of keeping up, which happens a lot in this space), but
  it has potential at least to be pretty useful.
 
  Klonoar - 1 hours ago
  Mmmm, so... sub 100MB for a bundler + compiler + etc?  - Xcode,
  for iOS/Mac Development, is usually around 5GB (and    no, even
  if you remove every single simulator, it's still over 100-200MB).
  - Android Studio is roughly the same deal as Xcode.      - I've
  not used Windows so I can't say for sure, but I'd be surprised if
  the various tech there doesn't follow this pattern.  77MB is
  nothing, and if you care about this, you're caring about the
  wrong things.
 
    segphault - 43 minutes ago
    689 packages is enormous surface area for a leftpad-like (or
    worse) failure. Given that nobody is auditing those packages
    and many of the people who maintain them aren't adhering to
    best security practices[1], I don't think taking nearly 700
    dependencies that you are going to treat like a black box is a
    safe or responsible choice.Xcode and the Android SDK each come
    from a single vendor who provides an integrated development
    stack and presumably vets the contents. Does anybody do that
    with these npm packages?It seems like every time I run the du
    command in my node_modules folder, I find some crap that
    shouldn't be there. Earlier this year, I submitted a PR that
    reduced the size of the babel react preset install footprint by
    about a third, just by removing a totally unused dependency
    that nobody noticed. I don't think the contents of npm packages
    get nearly enough scrutiny and it scares the hell out of me.[1]
    https://www.bleepingcomputer.com/news/security/52-percent-of...
 
      liamfd - 13 minutes ago
      Would you mind linking to your PR? Would love to take a look.
 
    cnp - 1 hours ago
    Exactly
 
  nine_k - 2 hours ago
  See it as a silly but efficient cache.Well, npm may implement
  some kind of content-addressable storage to transparently
  deduplicate the dependencies tree on disk. It's not quite easy to
  do well.As long as your bundle size is small, and the build times
  are fast, it's a clear improvement, at the expense of spending
  like 0.15% of even the cheapest 60GB SSD.