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.