React for Vue developers

| 14 min read

For the past three years, I've been using both React and Vue in different projects, ranging from smaller websites to large scale apps.

Last month I wrote a post about why I prefer React over Vue. Shortly after I joined Adam Wathan on Full Stack Radio to talk about React from a Vue developer's perspective.

We covered a lot of ground on the podcast, but most things we talked about could benefit from some code snippets to illustrate their similaraties and differences.

This post is a succinct rundown of most Vue features, and how I would write them with React in 2019 with hooks.

Read more


Full Stack Radio 114: React for Vue developers

I had the honor to be a guest on Full Stack Radio with Adam Wathan.

We talked about why I prefer React over Vue — which I wrote about two weeks ago — and how to implement some patterns that Vue provides out of the box but aren't explicitly available in React. Examples include computed properties, events and slots.

Adam's quote:

In this episode, Adam talks to Sebastian De Deyne about learning React from the perspective of a Vue developer, and how to translate all of the Vue features you're already comfortable with to React code.

Tune in on fullstackradio.com or on your favorite podcatcher!


14 KB

| 1 min read

When you visit a website, your browser connects to a server via TCP. With TCP, the first roundtrip can be up to 14 KB large.

In other words, the first 14 KB sent to the client will always be the quickest to render in the browser. The rest of the response is streamed afterwards.

This website's homepage is about 9.7 KB at the time of writing. Articles are roughly 4-10 KB, depending on their lengths. All CSS is inlined, so besides fonts and images everything is loaded withing the first roundtrip, making page loads fast and snappy.

Not all sites can be contained within 14 KB — most probably can't. But keep the number in mind, and try to optimize the first 14 KB instead.


Understand React hooks internals with a 28-line React clone

Shawn Wang (@swyx) wrote about how React hooks work internally. The article is a deep dive into JavaScript closures, and builds up to a 28-line React clone with support for the useEffect and useState hooks.

In this article, we reintroduce closures by building a tiny clone of React Hooks. This will serve two purposes – to demonstrate the effective use of closures, and to show how you can build a Hooks clone in just 29 lines of readable JS. Finally, we arrive at how Custom Hooks naturally arise.

Understanding how React deals with hooks internally isn't a required to use them, but it's interesting material nonetheless!

You can read the full article on the Netlify blog.


Running PHP CS Fixer on every commit with husky and lint-staged

| 2 min read

Last month, I wrote a post about automatically running prettier before every commit. This ensures that all JavaScript and CSS are formatted correctly before they're stored in the project's repository.

Husky and lint-staged have been working hard keeping our front-end assets clean as Spatie, so we decided to expand their responsibilities to keep our PHP files clean too. This is a modified version of my previous post using PHP CS Fixer instead of prettier. There's also an example of a conmbined configuration to run prettier and PHP CS Fixer simultaneously at the end of the post.

Read more




Don’t forget to be selfish every now and then

| 1 min read

The other day, I stumbled upon an older article by DHH. “Work on what you use and share the rest”.

My core philosophy about open source is that we should all be working on the things that we personally use and care about. Working for other people is just too hard and the quality of the work will reflect that. But if we all work on the things we care about and then share those solutions between us, the world gets richer much faster.

I’ve been keeping this in the back of my mind the past few months.

I was always adding features because I’d expect other people to expect them. It’s a trap! You’re not making people happier by guessing what they might need. You’re not doing anyone a disservice by building things for yourself.

Building things for yourself makes it easier to ship something you feel happy about. It makes it easier to ship something at all.

Don’t forget to be selfish as an open source maintainer every now and then. It’s a good investment in the long run.

I used to fall in the trap of thinking I needed to add features because other people might expect them to be a part of my code, not because I need them myself.



The great divide

Chris Coyier consolidated an array of opinions about what it means to be a frontend developer today.

On one side, an army of developers whose interests, responsibilities, and skill sets are heavily revolved around JavaScript.

On the other, an army of developers whose interests, responsibilities, and skill sets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.

It's that other side that seems to really be feeling this divide. A quote from Mandy Michael:

What I don’t understand is why it’s okay if you can “just write JS”, but somehow you’re not good enough if you “just write HTML and CSS”.

When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.

A lot of these excerpts really hit home. I'm looking forward to the conversation this might spark.

Read the full piece on css-tricks.com.