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.
I personally find Webpack (and the documentation) to be a little maddening once you want to go beyond standard presets. Why doesn't this file have sourcemaps? Why do some Webpack plugins output the name of the entry point while others output the name of the source file? Why is this file being emitted in the wrong place? There are definitely benefits to using Webpack, but it's a lot harder to debug than a bunch of Makefiles and UNIX pipes.
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.
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.
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.
Can you explain that experience more? Are you not using any sort of module system?
If you're simply concatenating files together, Webpack is decidedly the wrong tool. The magic that Webpack does is understand what you're require()ing and automagically just make a bundle for you. Point it at your project root, and you get a bundle.
I didn't find it all that difficult to get started with webpack after a few tutorials and samples
Neither did I until one day I tried to do something slightly outside those tutorials and the whole thing kind of stopped working for reasons I could never fully understand.
That being said I'm still using webpack, but it's not really an enjoyable experience.
And this is why I have stuck to using grunt like a neanderthal. Grunt is primitive and slow but I understand everything that it does and I am able to extend it to do my bidding. Webpack etc. are probably more efficient but also limiting.
This was my biggest complaint with the Angular 2 cli generated app. I had to dig to even find out they were using webpack behind the scenes. And I know they just want to utilize it without troubling newbies, but I wish they had some means of customizing it. I think it's on their roadmap, or just being requested a lot on github. There's so much you can do with webpack that it's a shame it's hidden.
The inability to customize webpack was sometimes a pain point for me. There were a few things I wanted to do that would have been much easier if I could just play around with it. Fortunately, they've added the ability to get yourself a webpack config!
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.
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.
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.
The latest Xcode to support the latest iOS version is 17gb, it might take more than a few seconds to get it running properly, and you need to set up a developer license key and have all the certificates up-to-date just to run on the device, iOS tooling is more complex hands down
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.
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).
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".
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!
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.
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.
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.
You can use an environment variable to point to a CDN host and use it as a prefix in your code. But you also need to make sure the CDN assets get expired. One approach is to use the stats plugin for Webpack, parse the manifest, and write a helper so that the right files get included in the HTML.
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.
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.
Personally, I'm looking forward to five more of these projects springing up, after which someone can great a meta boilerplate framework for abstracting all the boilerplate frameworks. It can have its own meta preset format that translates into the six other preset formats so you, the lucky developer, can pick your open boilerplate generator and rely on this boilerplate generator generator to hide everything behind a common, leaky interface!
We'll call it Hadron, since Hadron decay can result in the production of Neutrinos...
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.
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?
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.
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), 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.
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.
I am able to bring the React patterns on the web and use the same patterns and code to make native iOS and android apps. Until there is a solution that can work cross-platform like this, I don't feel React and JSX is unnecessary
I did frontend for around 5 years. Started with Angular before it was cool and went through all the node/npm hype. I'm getting out of frontend now because of the ridiculous state of frameworks and libraries. In the mean time for my side projects I now do almost everything in pure JS and use only specific functions from libraries if there is no way around.
The irony with all these frameworks, in many cases especially for small projetcs, it will be more efficient to code it from scratch than dealing with the whole stack thing. So much for not reinventing the wheel ...
I did recently for a very simple Cordova app used by sales reps for marketing purposes. A framework or external libraries was overkill to the extreme, so by sticking with just vanilla I kept the app size to a minimum.
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 :)
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.
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.