paulojreis

Much like IanDrake said, this is super cool but kind of "primes" the user into thinking that he'll be able to play around with the code while paused. It'd be great if you supported that, e.g. by doing a "fork" into local storage.

Anyway, the project is really great and impressive! :)

Sure, you're right. I just meant that the real challenge is how to skew (and keep) the balance in the direction you want, in a sustainable, significant and achievable fashion.

"1. Calories in, calories out is the golden rule."

Yes, but I'd argue it's not a very helpful rule. As it has been said before, it's pretty much like saying that the golden rule to get rich is "money in vs. money out". Correct, but not very helpful.

Had some experience with it in BigCorp™. I don't love it, but it works. It's just a plugin that will install node (and npm), run `npm instal` and then run the specified gulp task.

The good part is that it's not that bad to fit within the company infrastructure, particularly if it's a BigCorp kind of thing. It's interesting because it allows you to play well with CI processes and quality rules - I'm thinking about tests here. With this kind of setup, you can make the front-end build fail if e.g. code coverage drops below a given threshold, using the same setup you use for other components.

The boring part is that it's yet another place to put config info. A particularly ugly one which reeks of over-engineering IMHO. Also it's XML; XML isn't quite the song of the front-end people, at least config-wise. :)

> AirBnB's marketshare is coming out of someone.

In Portugal, it seems to be coming from the rental market. In the sense that there's been an increase in tourism and the increased demand for short-term accommodation is being fulfilled with properties which were previously for longer rentals.

If using the :target approach, I actually think it's an appropriate use of CSS and HTML. It's not a stretch to consider a tab as a fragment of the document, which can be accessed using the fragment identifier of the URI. After this, hiding the other fragments while showing the target one can also be considered a style choice which is, adequately, achieved via CSS.

Probably people will end up using JS for this, and that's OK, but I really think this approach actually fits the way standards "define" HTML and CSS.

Decriminalized. It's still illegal to consume, but not a crime - people aren't sent to jail or fined. Selling, of course, is illegal and a crime.

In Portugal, we have some "theoretically" restrictive labor laws, supposedly very protective towards the employee. Still, everyday you'll hear about someone being told that he/she should feel lucky to even have a job, let alone a salary (because, yes, unpaid stuff is also common).

My point being: labor laws are fundamental, but they don't trump a) on one hand, a bad economical situation; and b) on the other hand, a die-hard culture of constantly finding ways around the law.

Personally, I thinks it's way, way past any acceptable measure to improve positive thinking and engagement. It's closer to a shock tactic than to any new-age/*spiritual "put life into perspective" thing.

Really, it's just too deliberately traumatic.

Don't want to sound ungrateful, really, but sharing a little more info about the book "before" asking for my e-mail would be nice. A table of contents in the book download page, maybe a small summary.

Adding elements just because (and, above it all, just for styling purposes) is wrong, of course. But having - or forcing - a tight coupling between structure (DOM) and layout/styling (CSS) is also wrong. IMHO, standards should try to move in the direction of decoupling; they did the opposite with Flexbox.

Anyway, the most present case for me is really Angular, where DOM elements are usually added because they are needed (and actually beneficial, if you like a component-based architecture and DRYness). Angular 1.x deprecated the `replace` option for element directives a few months ago (i.e. your <my-directive> will be in the DOM). Also, AFAIK, it never supported the `replace` behaviour in components (which are always elements). This means that, currently, Angular and Flexbox don't play very well together...

> Seriously, HN is a gigantic delicious timesink that has probably cost all of us collectively millions.

It's possible, but what you get back from HN is also enormous; from jobs to interactions with very smart people. I mean, Alan Kay was involved in discussions here, just yesterday!