
Using Neutrino to jump-start modern JavaScript development - nachtigall
https://hacks.mozilla.org/2017/02/using-neutrino-for-modern-javascript-development/
======
caseymarquis
Maybe it's just me, but I didn't find it all that difficult to get started
with webpack after a few tutorials and samples. This seems like it hides away
something that people should probably understand, which isn't all that
difficult to get started with. Also when you start combining different
packages in webpack (or encounter an error (or want to make some decisions in
the config script)), the standard copy/paste boiler plate becomes less and
less useful.

This looks neat, I just don't think it's likely to do away with configuration
completely unless you've got a very standard setup.

That aside, it sort of sounds like the goal here is "a sort of package manager
which also handles boilerplate"? Definitely sounds useful when you want to
quickly try something new.

~~~
tjholowaychuk
We all do basically the same thing in every app ever, it's the fragmentation
that is such a huge pain with JavaScript. Most apps don't have to be unique
snowflakes, we make them that way with hacky css-in-js and so on.

Webpack is great for what it is, but I strongly disagree that people should
have to understand the config boilerplate aspect to get something functioning.
All it does is prevent you from doing real work, not to mention if you're
working on dozens of apps, this quickly becomes a hellish thing to deal with.

~~~
hashkb
I have great respect for you but this seems a bit mean spirited. Why shouldn't
devs want to be as many things as possible?

Is css-in-js is more ridiculous than regular CSS? I've left regular CSS behind
and gained a lot of sanity.

~~~
tjholowaychuk
It's just my opinion of course :) but I think css-in-js is a step backwards in
the majority of cases. I do like CSS modules in terms of scoping / modularity,
but I don't want to replace CSS with (what I consider to be) really gross JS
implementations.

I don't want to discourage people trying new things, but I also don't want
people to waste thousands of collective hours dealing with crazy
configuration.

I think toying around with those things are fun for people who get paid by
startups etc, but for those of us who simply want to get things done, the
ecosystem is not enjoyable.

~~~
fuzionmonkey
I think you are conflating multiple things. There's several JS styling
libraries have literally zero configuration (and don't involve build tooling,
etc). They "just work" out of the box.

------
ryanbrunner
I think this is a cool tool, but it's somewhere between funny and depressing
that the article brags about how they were able to get a 'Hello, world!'
program up in _less than 5 minutes_.

~~~
mikewhy
A Hello World GUI app, which is a fairly important distinction. Also one that
runs on any machine with a web browser.

~~~
sdegutis
But creating and running a Hello World GUI app for iOS only takes a few
seconds, even when running it on your live device.

~~~
RubenSandwich
Not really an apt comparison as iOS is a complete ecosystem controlled by one
party, so choices are made for you. I'd say comparing it to a Hello World GUI
app in C++ would be, as C++ also has a proliferation of build tools and
graphics libraries that you have to choice before you can make a Hello World
GUI app.

~~~
sdegutis
Good point. Although I guess my broader point is that the decentralized nature
of web development is actually kind of a huge disadvantage in pretty much
every way except "flexibility", and that the cons very much outweigh the pros.

------
moron4hire
I've been doing something like this for a while. I have my entire build
process as a project on NPM itself. I just have to import it into my projects
and write a small gulp project setup. It's very declarative and if I spent a
little more effort could probably mostly eliminate. It has most of my
preferred tools in it, including dev server setup, statically generated Pug
templates, Babel, Rollup with tree shaking, and documentation generation. I've
found it's also great for keeping my project setup clean. Most of my project
dependencies end up being dev dependencies for build process, and there are a
lot of them. This simplifies down to one.

~~~
anaganisk
is it open? Would be interesting to use it.

~~~
moron4hire
It is, but I haven't documented it at all
[https://github.com/capnmidnight/notiontheory-basic-
build](https://github.com/capnmidnight/notiontheory-basic-build)

Here is an example of usage
[https://github.com/NotionTheory/Primrose/blob/master/gulpfil...](https://github.com/NotionTheory/Primrose/blob/master/gulpfile.js)

The name is lame, I hadn't considered sharing it and I misremembered that the
dev server and doc gen are not yet a default part of the build project (though
I could add them easily).

------
sthatipamala
How composable are these presets? I like to use Typescript and ideally that is
only additional one preset rather than a combinatorial explosion of things
like "neutrino-react-electron-typescript".

------
tjholowaychuk
Works great, I like this approach much better than the variants that I've
seen, this is exactly what I was hoping to see. It's simple, concise, imposes
nothing on you, ships with good presets (from what I've seen so far), still
extensible. Nice work!

------
mhd
What do I have to change with the "hello world" setup to get any kind of error
reporting? If I introduce syntax errors in the index.js, I don't even get a
good stacktrace on the CLI, never mind a neat compiler message in the browser
itself (like create-react-app does).

Is this out of the scope for the basic example or an oversight? Anyway, if
this is targeted at beginners, that's a bit of an issue.

------
amk_
One thing that seems to be missing from these SPA app utilities is an
automatic way of pointing your root HTML file at an expirable root JS file. In
development it's ok to point at `application.js` but in production
NGINX/S3/Apache/Cloudfront should be serving something like md5-digest-of-app-
bundle.js such that when the bundle content changes you invalidate the cache.
If you're using a CDN you'll also need to have a prefix step to change the
root url for assets.

~~~
cobralibre
Webpack supports the former if you use _[hash]_ (or _[chunkhash]_ ) in the
output filename. [1] This is what create-react-app uses. [2]

[1] [https://webpack.js.org/configuration/output/#output-
filename](https://webpack.js.org/configuration/output/#output-filename)

[2] [https://github.com/facebookincubator/create-react-
app/blob/m...](https://github.com/facebookincubator/create-react-
app/blob/master/packages/react-scripts/config/webpack.config.prod.js#L78)

~~~
amk_
Yep, the tricky part is just rewriting your __HTML __so that it includes the
right file. However, it looks look my comment was incorrect and most
frameworks have considered that issue. Neutrino and create-react-app use html-
webpack-plugin.

[https://github.com/facebookincubator/create-react-
app/blob/m...](https://github.com/facebookincubator/create-react-
app/blob/master/packages/react-
scripts/config/webpack.config.prod.js#L232-L248)

------
tobltobs
Javascript Boilerplate Fatigue

~~~
philmander
After just reading the title, I assumed the same thing, but actually this is
exactly what web development needs.

create-react-app is a great example of a project that abstracts away all the
complexities of a JavaScript build process and dev environment, but
customization inevitably requires you to 'eject' and reintroduce that
complexity to your project.

This tool goes one step further and supports customization without this eject
step.

This is finally where web builds need to be to provide a simple foundation for
modern web development so devs can focus more on making apps and less on
tooling.

I look forward to trying it out.

~~~
omouse
What complexities of build processes?!

Building Javascript files with modules and deps is a solved problem. We've
built all sorts of other file types and compiled them and linked them before
with tools like Make, SCons and other tools. It's ridiculous to think that
JavaScript is a unique language that needs its own build tools. It does not.

We went down the wrong path years ago when we decided that whenever we use a
language we also need to use tools written in that language. Grunt, gulp,
webpack and the rest should go away.

~~~
philmander
I hear you. Node.js made my Ant tasks for running jshint and qunit totally
redundant :(

------
talkingtab
Is there a simple example of how to add something like react-router, redux and
bootstrap as to presets to neutrino. My problem with CRA is that while very
helpful(!) I am often faced with having to add those kinds of components.

~~~
Touche
I'm not part of the React ecosystem so please excuse my ignorance, but why
would adding a library require changing a build? Wouldn't you just npm/yarn
install those things and use them?

~~~
thangngoc89
Yes you are right. Redux or react router have nothing to do with build config.
They are parts of the app

------
gens
Does _anybody_ just write plain JS ?

~~~
madhadron
Yes, actually. As soon as you recognize that the DOM API is rich and fast and
you understand how MVC works, you actually get much cleaner code by not mixing
HTML and JavaScript. My original explorations of doing this are at
[https://github.com/madhadron/mvc_for_the_web](https://github.com/madhadron/mvc_for_the_web).

When you understand this, React's shadow DOM and JSX are completely
unnecessary.

Combine it with the fact that grid layout is expected to be in the stable
releases of Chrome and Firefox in the next month, and, if you have no legacy
browser requirements as I happen not to, web application development becomes
somewhat reasonable for the first time since I began doing it in the '90's.

Admittedly, when I started trying to build a library out of this
([https://github.com/madhadron/allorryll](https://github.com/madhadron/allorryll)),
I put it in TypeScript, but I'm also the guy who did serial port and Firewire
camera control in Haskell.

Obviously this doesn't apply to writing documents on the web, where JavaScript
should only be added as part of a structure that will gracefully degrade.

~~~
olavgg
Nice to hear! I also use a MVC framework (Grails) with plain old Javascript
for DOM manipulations. I have no need for complex bloated frameworks like
Angular and React. I do more complex UI with canvas too(where zooming and
panning is required).

I agree that web development has never been more fun that it is today, except
for Safari with buggy flex implementation and iOS that set position: fixed to
absolute and refuse to properly scale the "document" when you want to type
some text. Every time I get a bug report these days it is Safari or iOS that
doesnt follow the standard. Chrome, Firefox, Edge works great most of the
time.

------
foundry27
Am I the only one who thought that the post title was referring to QNX
Neutrino and did a double-take when it went on to talk about Javascript?

------
xmattx
Reminds me of a framework-agnostic vue-cli. Though that simply builds a
configuration/tooling-setup which you can then tweak to your liking. Not sure
what I think of using a neutrino-specific config in the package.json for
overrides, feels bloated compared to just editing the webpack config directly,
and doesn't make it any easier. But to each his own, I guess.

That name though, I guess particles are en vogue :)

------
ziikutv
Great! More tooling

------
iomind
Why not just use Yeoman? Moz really like reinventing the wheel.

~~~
tjholowaychuk
Yeoman is boilerplate, this is code which directly avoids boilerplate, since
it's an abstraction instead. Yeoman IMO encourages the wrong things, most true
boilerplate (files) can just be a sample repo that you clone.

