Comment: Webpack and blocks.js

[fresheneesz]

I read the blog post at http://tjholowaychuk.tumblr.com/post/27984551477/components and its an interesting analysis. I've been very interested in the solution to many of those problems myself, and I definitely agree with agnostic modules over framework-specific plugins and the need to use non-javascript files.

I wanted to mention that Webpack is an amazing bundler that does far more than just javascript. User can create "loaders" (really they're transformers) which allow webpack to package any type of file they want - and there are already a solid set of loaders written to do things like package images and css into the bundle so that even those things can be used in a modular way.

Also, I'm currently in the process of open sourcing blocks.js https://github.com/Tixit/blocks.js , which is a unique system for building web applications and has similar goals with the "web components" movement. The feature that's relevant to what was written in the blog post is that it replaces css stylesheets with style objects, providing a way to make styles modular and isolated from other styles. Thought you might be interested.

[timaschew]

maybe you want to send a pull request here: https://github.com/wilmoore/frontend-packagers

[fresheneesz]

@timaschew Not sure I understand

[timaschew]

the repo I posted is maybe a better place than here at component.

or another question:

Thought you might be interested.

what do you mean exactly with that and which user do you want to address?

[fresheneesz]

I guess I meant to address the writer of that blog post. I'm also wondering if component.js solves the same problems in a better way than webpack and blocks, or if it solves different problems? I thought someone here might be interested because of the similar goals expressed in that blog post

[timaschew]

the writer of the blog post is @tj, he left nodejs land but the guys created a new tool, where he worked/is working, it's duo

At the same time @jonathanong did a rewrite of component, but then he left component as well and started with https://normalize.github.io

Now some guys and me are still maintaining component.

I guess I meant to address the writer of that blog post.

Because of the huge movement this repo is the wrong place to address him, you can try it at the duo repo maybe.

I'm also wondering if component.js solves the same problems in a better way than webpack and blocks, or if it solves different problems?

IMO there is no better or worse way to do it. But component solves the same problems, just in a different way. I think webpack is a great tool, I didn't try it out yet, just checked out some docs and examples. But I don't like two things: 1. how to handle remote dependencies, across different repos (externals?) and 2. that require is not compatible with the standard.

With component you can also transform your modules per property which you define in the component.json. If you're using a non built-in transformer like coffee or jade, you need to use the API instead of the CLI.

Components ultra feature for me is that it have this concept of locals. Every local module doesn't know where its dependencies (local or remote) are located. I didn't see this concept solved in this clear and self-contained way by any other tool.

In comparison to webpack, you can also define and install your dependencies with component. So it's not just a build tool, it's also a package manager.

The general problem with CSS which you solve with your blocks.js library is a really issue. And there exist different types of solutions, everyone has it's own advantages and drawbacks. For instance if you use just CSS you can combine it with every other library and tool. If you're using a JS abstraction, you get a opinionated dependency and complexity layer. If you provide less, scss or styl instead of CSS it's not so opinionated anymore, but also not universal.

I thought someone here might be interested because of the similar goals expressed in that blog post

The blog post is really old, it's from 2012, almost 3 years ago. At this time there weren't so much solutions, but now there exist so many tools and every tool has it's own kind of opinionative flavour. That's the reason why I tried to redirect you to the https://github.com/wilmoore/frontend-packagers where you have a nice and maybe independent overview for all these tools.

[fresheneesz]

how to handle remote dependencies

I think the standard way to handle remote dependencies is to either pull them local or load them side by side. What's a case you're not sure webpack can handle?

require is not compatible with the standard

What do you mean by this? Do you mean require.js? Webpack can definitely output umd modules, which are compatible with require.js. It also supports requiring require.js modules.

concept of locals

So this is basically like a mapping between a name and a location, where that mapping is stored in the component.json file? Webpack can do this with its alias option.

If you're using a JS abstraction, you get a opinionated dependency and complexity layer

You're definitely correct there, but I think its worth it since CSS just sucks so much. We need something that's not css, so in my opinion there is no reason to make new solutions compatible with old ones (tho, at least for blocks.js, old css is still compatible with blocks.js, but blocks.js styling is not compatible with traditional styling techniques - you just have to use a regular stylesheet side-by-side if you need that).

[timaschew]

I think the standard way to handle remote dependencies is to either pull them local or load them side by side.

I think I didn't get it how to handle remotes.

require is not compatible with the standard

What do you mean by this? Do you mean require.js?

this is not a valid syntax: require("coffee!./cup.coffee");

So this is basically like a mapping between a name and a location, where that mapping is stored in the component.json file?

it's not just a mapping, it's a way to define self-contained modules, and all module doesn't know where its dependencies are located, only the root module define a lookup path

You're definitely correct there, but I think its worth it since CSS just sucks so much. We need something that's not css, so in my opinion there is no reason to make new solutions compatible with old ones (tho, at least for blocks.js, old css is still compatible with blocks.js, but blocks.js styling is not compatible with traditional styling techniques - you just have to use a regular stylesheet side-by-side if you need that).

Yes, but you can solve it also by providing the styles mixins/functions written in stylus, less or sass. Some frameworks like twitter bootstrap or zurb foundation are providing multiple versions of styles (both css and less for instance). This sound like a good solution for me.

[fresheneesz]

this is not a valid syntax: require("coffee!./cup.coffee");

True, but you don't need to use its extended require "loaders". The standard is compatible with webpack.

you can solve it also by providing the styles mixins/functions

This solves one problem only - how to express symmetry between styles by composing styles together. It does not solve the problem of modularity, as it still uses css's inheritance and cascading system. Meaning that two nodes with class "X" will be styled by any selector that matches ".X", even if they're completely unrelated. There is no way to get around namespace collisions with less or sass.