akdetrick

The average worker is 5x more productive than they were 30 years ago, but wages have been basically flat.

In the last 10 years, the federal minimum wage has not risen, effectively reducing the minimum wage by about $1 due to inflation.

The richest 500 people in the world grew their wealth by $1.2 trillion in 2019, a 25% increase over a period of one year.

The minority build their wealth on the labor and taxes of the majority, but sure, adjusting the tax code is "stealing".

and the word "Brutalism" originally referred to the material, béton brut (poured concrete), not a philosophy of being brutal.

To help clarify why this is a big deal, I'd like to share why I've been so excited about this project...

[tl;dr] - This is the first tool I'm aware of that actually allows you to generate both API docs and design tools from the same source.

Static documentation is a lie waiting to happen. Once docs are even slightly out of date, people lose trust and eventually abandon them.

On the engineering side of the dev/design process, this is easy to work around. We generate documentation from code and structured comments, which allows us to trust our docs as an up-to-date point of truth.

If you're building a design system that both engineers and designers will work with, there's no real solution to keeping sketch symbols and React components in sync. You're essentially stuck maintaining "static documentation" for designers in the form of a sketch file.

More often than not, things get busy, or someone forgets to commit a change to the sketch file, and the sketch symbols fall behind the code used in production.

Developers start to receive mocks that don't match the "standard" components they're using. Designers start to wonder why fidelity is lost by the time features make it to production. The design system falls apart.

`sketch-reactapp` will help us deal with the static documentation problem the same way we deal with it on the engineering side of things: generate from source.

This is the first tool I'm aware of that actually allows you to generate both API docs and design tools from the same source.

Congratulations on the launch!

I've also had the experience of getting "suspicious looks" while walking in suburbia.

I was once stopped and questioned by a police cruiser because I was walking on a well lit street at night in my Ohio hometown. The officer was reluctant to accept that anyone would walk for the sake of walking - and yes, I've read "The Pedestrian" by Ray Bradbury [1]. Truth can be as strange as fiction.

After living in NYC for 10 years, walking has become such a natural part of life that I completely forgot how unusual it was in suburban Ohio.

I can't help but think that the lack of walking goes beyond negative health effects; I feel like it erodes civil society to a certain degree. When you drive door to door, you rarely interact with strangers. Given my experience, I don't think "paranoia" is too harsh of a word to describe what car-focused settlement patterns can do to people.

[1] - http://en.wikipedia.org/wiki/The_Pedestrian

EDIT: not sure if "The Pedestrian" is in the public domain, so linking to wikipedia instead of directly to a PDF

Comic Sans does serve one good purpose; it's a dyslexia-friendly typeface. It's nice that Comic Neue preserves some of the letter "hints" (ie. the "b" and "d" glyphs have slightly different bottom terminals).

Although if you're trying to optimize specifically for dyslexia, you'd be better off with something like OpenDyslexic [1].

[1] - http://opendyslexic.org/about/

Amazing. Under "other states", I noticed a few minor engagements in "CA". I wondered if I had read that right - California?

This ended up bringing me to an article[1] about California's involvement in the Civil War, a state that I had previously written off as uninvolved in the conflict. Not only was there a significant union fort in what is now Los Angeles, but they had camels(!?) for desert operations.

1. http://www.nytimes.com/2013/03/21/arts/artsspecial/heralding...

melt equal parts syntactic sugar and water...

While very well executed, the basic idea of delivering a document that doesn't make sense without javascript just seems wrong to me.

I've always thought the real promise of responsive design is "mobile first", delivering a basic document that works on its own, then enhancing layout/resolution for larger viewports and browser capabilities using CSS. This approach basically does the opposite.

I've seen these blimps in NYC, Boston, and Chicago to name a few places that are notably far from Akron and Miami. I've always wondered - I'd love to know if the blimps are flown from their base locations to other cities, or if they're somehow trucked in and inflated on location.

The fact that they're considering zeppelins leads me to believe that the normal procedure is to fly them to events, which seems crazy given how slow they appear to be...

I agree that it's a bad tool in many ways, but even if the language (and environments) were beautiful, the problem at hand is often the way that people use it.

In this case, a poor craftsman uses his tools to do the things that the browser already does for you.

I've seen some JS that reinvents lots of what the browser rendering engine should handle (recalculating & reflowing heights of elements every time something was added or subtracted from the DOM, for example). Expand this kind of thinking to an entire project, and you start to find yourself in the kind of mess described in the slides.

If/when Dart replaces JS, some of the enforced structure may help prevent badly organized or buggy code, but it won't fix poor assumptions of what concerns scripting should and should not handle.

I usually agree with this, usually because we often see things like "icons/logos drawn in pure css", which implies someone maybe thought it was a good idea to actually use in a project.

This demo, however, seems to me to be just for fun. It does serve a purpose though; it's nice to get such an impressive view into what's possible with CSS now, and these demos can also be used for performance testing. It's pretty interesting to take something so rendering-heavy, open a profiler and see what happens when you start transforming, animating, and modifying it (one article comes to mind that uses the "pure css macbook" to demostrate the performance of translate vs. position[1]).

[1] http://www.paulirish.com/2012/why-moving-elements-with-trans...

This is what I believe is the single biggest advantage TX holds over NYC. It's hard to underestimate the power the Historic Districts Council and Municipal Art Society have over the future of the city. Despite the fact that no one elected organizations like these to govern, they have a huge impact on what gets built and what does not. The Municipal Arts Council, for example, is railing against a proposal to upzone Midtown East because it might change the look of the skyline [1].

NYC is already feeling the pinch of a housing shortage, and is so behind in building that the 2030 population projections had to be revised to account for the serious lack of housing [2].

Texas on the other hand, as bad as urban sprawl can be, keeps building. People move there, housing gets built, and supply meets demand much better than it does in NYC.

[1] http://mas.org/urbanplanning/east-midtown/ [2] http://www.capitalnewyork.com/article/politics/2013/04/85286...

I agree, but the caveat for any city/town where you can get by without a car is "affordable".

full disclosure: I've lived in NYC without a car for 10 years, but grew up in Ohio completely car-dependent.

Edit: There are in fact many places that do meet the requirements of affordable and walkable, but a new concern in an age of urbanization is keeping them affordable. The desire for such neighborhoods is growing, but the supply is too low as of 2013.

I wouldn't call it pragmatic, but alienating is definitely the right word.

There are few (affordable) places in America right now that you can live without complete car dependence. The poor, elderly, young, and disabled are in fact alienated.

It's easy to understand why this pattern of settlement began when you consider the novelty, freedom, individuality (which can not be understated as something Americans valued), and convenience that came with the availability of automobiles.

Somehow though, we've moved forward through almost a century of such development, placing the car above all else. I'm reminded of Raquel Nelson, charged with (but thankfully not convicted) manslaughter because a hit an run driver killed her child while she was allegedly jaywalking [1].

[1] http://www.forbes.com/sites/erikkain/2011/07/18/woman-convic...

Edit: clarity

This article is missing an image of an old map with red lines connecting Italy, Guam, Hawaii, and Chicago.

Every regex seems like a clever trick.

The looks like a joy to write, and a nightmare to maintain. I may be old fashioned, but I still see content, style, and behavior as best expressed as separate concerns in source.

"Praise Publicly, Criticize Privately"

This point got me thinking. Public criticism of specific individuals is not something I ever to publicly, but I have been all too quick to compose tweets about things like "wishing that Internet Explorer had a face so I could punch it", or how terrible healthcare is in the US, etc.

It seems obvious in hindsight, but refraining from putting too much negativity in my public streams of information lately has probably not only improved the impression others have of me, but more importantly, made me feel a lot less grumpy myself.

In my efforts to focus on the positive and/or interesting things in my public speech, I find that I'm looking at these things more often in my private time as well. It's a rewarding exercise.

You can either repeat yourself by using "@extend %mypattern" in Sass using this methodology, or repeat yourself in the DOM with ".mypattern" in the OOCSS approach.

Both are elegant ways of handling the same task, but I don't think one is much more DRY than the other.

I'd argue that it's more correct to describe a class once and apply it to many elements (OOCSS) than it is to describe it many times over and apply it to each element individually (Sass @extend).

People keep having few (if any) alternatives for fast, reliable service providers.

"Choosing a typeface is not typography" I really appreciated this point.

Too often people confuse knowledge of fonts with typographic knowledge or skill. Understanding how to set type is far more important; correctly choosing a good measure (line length), margins, leading (line-spacing), and a meaningful hierarchy of font sizes (among other things) all have a huge effect on readability.

For anyone interested in learning more about typesetting, I recommend "The Elements of Typographic Style" by Robert Bringhurst.

This looks like absolutely positioned bits of text with unicode glyphs inside divs with a box shadow and border radius. Am I missing something?

Not that the execution or idea are bad, but I don't understand why this is on the front of HN today.

With that said, I do think that the use of unicode characters is a much better move than using some crazy css tricks to draw the suit symbols.

It's not just an argument of preference when programmers suggest not using tables for layout - it's about using a best practice and a standard instead of an old hack that is a habit many are lazy to break in an age when most browsers have excellent CSS support.

This is what a screen reader emulator tells me the front page of HN sounds like:

"Page has one hundred thirty links Hacker News dash Internet Explorer Table with one column and ninety-eight rows Table with three columns and one row Link Graphic slash yeighteen .gifLink Hacker NewsLink new vertical bar Link comments vertical bar Link ask vertical bar Link jobs vertical bar Link submitLink login Table end Table with three columns and ninety-two rows"

Of course, anyone actually using HN with a real screen reader will probably only get the links list from their reader, knowing how useless the supporting markup is (aside from the table layout, HN doesn't use meaningful heading tags).

There are many more reasons not to use tables for layout, but accessibility should be enough of a reason alone to stay away from layout tables.

I'm not sure why refactoring a table layout (an old html layout hack) into something more semantically correct and accessible is considered an "attack".

This is a great idea; an idea good enough to invest the time to create your own design and CSS instead of using bootstrap out of the box. One step at a time, I guess.

With that said, I hope this takes off and evolves into something big!

While I don't agree at all with the idea of abandoning classes for clever ancestry-driven selectors, the author is absolutely right about the advantages of the HTML5 content model and the portability of semantic markup.

I wish more people would advocate for a middle ground between this content driven approach and an OOCSS approach. They work so nicely together.

Who ever said that you should stop caring about using semantically correct tags when using portable classes for styling?

I once saw someone try to describe a hypothetical selector that did this using this syntax:

p < span.fast { color: red; }

Although that made perfect sense to me at the time, using some sort of subject signifier ("-hitch-has" or "$") makes much more sense.

It's off-putting to me too, and I fall into a category of overrepresented people in the industry (straight, white, male).

The pointlessness of this "perk" is what bugs me the most. It's an API hackathon - how is it relevant to include a statement that basically says: "nothing better than hawt women bringing you beer, amirite?"

That sort of copy has the target demographic of potential Hooters customers, not programmers.

I'm afraid of the same thing, but not because it will drive away designers, but because CSS is meant to be, and is most powerful as a declarative language.

What CSS really needs is an actual layout module in the specification (instead of the hacks we still use to this day to execute the most simple of layouts).

With all that said, I do think variables are a great idea.

I'm no less disturbed by this than anyone else, but you do not truly own your Facebook account in the way that you would own a PO box.

Your data belongs to Facebook, not to you. Sad, but true.

Edit: (submitted too soon) I'm sure there's something legally dubious about requesting private keys in this way, but the PO box example was a clear reminder to me about how we wrongly think of our data on private services as "ours".