Nice work, Elliot!

I find that I get by pretty well with Tachyons' flex helper classes, but this looks like an awesome addition to my grid setup!

"Better" is a tricky question to answer.

IMO, SublimeText is far faster/snappier/smoother than both VSCode and Atom (which comes as no surprise with the latter two being Electron apps).

It's still a little clunky from a customization standpoint (e.g., what do you mean I can't have two horizontally split panes next to a single vertical pane), and I think Atom + VSCode have better package ecosystems.

I get tremendous joy out of running $ sublime . from my terminal and seeing the editor pop open instantly. I rage pretty hard when VSCode (occasionally) leaks memory to the point where I can't write any code...

YMMV!

¯_(ツ)_/¯

Looks sharp! Glad to see they've taken a more "functional" approach with respect to alignment / spacing.

Still going to stick with Tachyons for the remainder, tho...

React teaches you how to be a good Javascript developer, Vue, like jQuery, just teaches you how to good at Vue

This is quite the blanket statement. Can you please provide some examples to back this up?

Sure, Vue affords developers syntactic sugar and a handful of abstractions over things like iteration (ex: the v-for directive). But it's a leap to suggest that such affordances "just teach you how to be good at Vue."

Hi Peter, that's a fair point! You're 100% right -- this approach certainly excludes a set of people from making use of the tool.

Please understand that my intention wasn't to "shoot myself in the foot," as much as it was a function of Developer (read: my own) happiness and expediency. Getting the Rails app off the ground with omniauth-twitter was a breeze, and meant I didn't need to manage, say, a 3rd party email service (had I gone the username/password) route. I learned that lesson the hard way with my first iteration of the app, when SendGrid wouldn't send users their email verification link

Great idea, Nattu! What kind of files do you think you'd like to upload (Just .CSS or something else?)

Thanks for the feedback! Coming in the next release :)

Thanks for the response and clarification!

By "impede our ability to have productive dialogue," I didn't mean to suggest that such a dialogue couldn't be achieved. I meant that it's far more difficult to see where exactly you're coming from and what your argument is.

Your central thesis ("It’s busy-work, it’s a way to avoid making hard decisions") is predicated on what I would argue is a flawed assumption: that product teams who embark upon up-front user research have enough data to make these kinds of decisions.

The one example that you provide in this blog post gives short shrift to generative user research, and creates a false dichotomy between it and the 4-5 day "Design Sprint." For instance, you claim:

For the most part, though, I recommend ditching the time consuming, wasteful up-front research in favour of tangible results.

In painting this dichotomy, I think you've left out a couple of important points:

• There is a time and a place for up-front, generative user research. Your decision to use this technique should be a function of the fuzziness of the problem space, and not of how much cash you're looking to get from your client.
• Not all up-front research initiatives look the way that you've described. At Pivotal Labs, for example, we gain plenty of "results" through: clarification of the problem space, a deeper understanding of users' needs, building/testing prototypes (of varying degrees of fidelity), and often a backlog full of user stories that engineers can start.
• If your conclusion is that "the useful data came from the first user tests, not the research," I encourage you to ask yourself whether that's a failing on your part to conduct the research in an effective manner (choosing the right tool for the job) or whether that's a failing of generative research as a whole.

From perusing the comments on Medium, it looks like we are in violent agreement on the matter. I worry, though, that headlines like "User Research is Overrated" create generalizations that impede our ability to have productive dialogue about our practice.

From my experience at Pivotal Labs, where Designers play an active role in writing front-end code on client software projects, style guides have been helpful in communicating the following buckets of information through the languages of HTML/CSS:

1. The foundational elements of a design system (colors, grid, typography, etc)
2. UI components that have gone through the rigor of prototyping, testing, and validation with real users.

Framed in this way, the style guide is meant to serve as a "source of truth" for the team and the UI itself. Engineers, tasked with implementing features, can simply pick code snippets from the style guide as needed. Designers, tasked with validating new design decisions, can continue their process of research/testing/implementation and ultimately add their decisions to the style guide (be that tweaking an existing component, or adding a new one altogether).

At Pivotal Labs, lots of Designers use Hologram to build such "living" style guides. To facilitate getting started, we put together a boilerplate project that helps them see how a style guide gets built and maintained over time.