Build system and code revamp

[alkhe]

I love the design and concept behind Inferno -- it fascinates me and I'm just raring to switch from React. But before we get there, there are a few things Inferno needs to address. I'm a bit busy right now, so I'll just outline my main concerns:

• Grunt is outdated. Gulp is a much better and faster build system.
• Same with Closure. UglifyJS is a much more capable and supported utility.
• Since you're using babel, it would be nice to use the new syntax. (let, import, etc.)
• Inferno should be more modularized. Unless a library is really small, a single module is usually a bad sign.
• Babel, Uglify, and more all come with webpack, which is what most new libraries (especially React era!) are using to build nowadays. With webpack, you can also get rid of bootstrap.js which nobody should be writing these days.

These changes should eventually reflect in t7, as well (modularizing; people would also love if the t7-precompiler were written as a babel plugin).

I'd be more than happy to submit a PR in a bit that works out all of these issues; you'll love the end result.

[trueadm]

Hi @edge,

• I agree, I plan to switch to Gulp, I simply re-used an old project template (that used Grunt) when starting with Inferno.
• It currently does use Uglify rather than Closure, although I've noticed noticeable performance benefits from using Closure's ADVANCED_OPIMISATIONS setting.
• I've intentionally avoided using ES6 features where they introduce more work for the compiler. Babel is great but it invokes an unnecessary performance penalty transpilling such features (minus ES6 classes, which are required for similarity with React ES6 components).
• I do like Webpack but again, I've noticed some small performance problems and higher memory usage when using Webpack over Browserify when building another project.

I'd love to some help on these features though, especially with the t7-precompiler. So any PRs would be great and thank you for the good feedback :)

[alkhe]

@trueadm I love that you are so concerned about performance and memory usage -- it's what made me fall in love with this library in the first place. But the ADVANCED_OPTIMISATIONS setting is notorious for breaking code, and that deters people from contributing. It's something that a lot of people don't trust.

Webpack has some really advanced optimization functionality, and it truly shines when combined with Uglify. You should check out its list of optimization plugins.

While performance is a huge priority, I think that sacrificing a superior build system to some micro-optimizations isn't the best idea. In the end, it's mostly the fundamental design and implementation (aggressive caching, anticipation, t7 compilation, etc.) that determines how well it performs, so I worry that some of your current optimization concerns may be hindering progress on the development of the library. I say this because it perplexes me that such a library, which should have been much more popular by this point, is still largely unnoticed.

I'd be happy to do some build system work and submit PRs.

[trueadm]

@edge Inferno shouldn't be popular. I've not attempted to spread word of it and I intentionally didn't want to do so just yet. The only place people find Inferno is from the vdom benchmark (it's only been on there a month). I hope it does become popular once I get it to a position where I am happy with it (which isn't where it is now).

I plan to get test coverage, build pipeline and all the other niceties out of the way, but any help and I'd very much welcome that help :). I agree with Closure, it does break your code in 95% of cases, thus why I dropped it :)

[trueadm]

I switched over to Gulp and Webpack in the latest proto branch commit.

[johnpittman]

Stick to your path my man. Core framework development and documentation > the build system etc. Sounds like they're using a light-green cube but you're making a dark green circle and wants you to cater to his business without actually helping (a todo list is not help). He sure does plug webpack a lot, why not jspm? Don't care and not an issue because we're here for something lightweight, bug free, fast, and easy to use. This is what I've been doing the whole time using random frameworks (loved where famous was headed until their team exploded) because it makes since to only diff values that matter. Almost jumped on mithril but it feels like another all-in-one and not quite natural enough. I'm transitioning back to basic stuff like this now using GSAP for animation until WebGL is a given so my next project will be inferno and I can dig in more. Great job on getting your idea out there for the community. Tell your baby to get to typing, ha!

[trueadm]

@JohnPittman thanks for the feedback and comments :)

We're now a team of three working on this project, happy for additional help if you're up for contributing to Inferno and have passion to make the fastest JS framework out there :)

[alkhe]

@JohnPittman

Sounds like they're using a light-green cube but you're making a dark green circle and wants you to cater to his business without actually helping (a todo list is not help).

It'd be a business if only I weren't 16. :) I'm just an open source dev.

JSPM is a no-go because currently the tooling is a bit awkward. And it's also better as a dependency manager, not as a library build system. webpack has a lot of advanced optimization, and it has the smallest output size of pretty much anything out there.

Since we're currently using webpack and ES6+ in the new-build branch, I'll close this.

[johnpittman]

@trueadm That's awesome my friend. Thanks so much for the consideration and I am completely in on this but there's a "but." Officially signing a bunch of docs next week because I've now embarked on going all-in on a business and I'm the only one out of a lawyer, digital marketer/business analyst, and super hero hybrid nerd (me) that's able to build out the back-end cloud platform we need so it's going to be a few weeks before I get back to dominating the front-end which is my favorite part. There's a ton of ideas I can't wait to go HAM on back on the front-end, but right now in order to portray how I feel at the moment I shall leave you with this:

https://www.youtube.com/watch?v=M1vfXoUNDYA

If anything I'll at at least contribute to some rock solid documentation for the site because there's nothing more annoying than having to rip hair out trying to figure out how to actually use things that are awesome. See you guys in a few weeks.