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.

Not all code is the same

As a short follow-up to Everyone has JavaScript, right?, there's more to JavaScript than availability, there are also the performance implications.

I don’t think most people are saying, “don’t use JavaScript.” That would be absurd.

But use less, use it wisely, and don’t depend on a giant framework for simple stuff. Use as little JS as possible to get the experience you want. You can do that and still have a great, immersive app.

I believe we're reaching for JavaScript more often because of its ecosystem, not because it's the better solution. The JavaScript ecosystem simply has incredible tools to build interfaces, and I hope server side solutions will still be able to compete.

I don't have a conclusion ready, I'm just interested in the topic. To be explored in 2019. Meanwhile, read Chris Ferdinandi's thoughts on the matter.

Distraction-less user interfaces: Delayed transient states

I have a specific pet peeve with user interfaces: things that draw my attention when they don't need to. In any graphical interface, movement is distraction. Our eyes are naturally drawn to anything in motion.

Motion is a powerful tool. We can abuse this distraction to attract our users to a certain place: a notification, an added list item after a background refresh, etc. Let's look into the movement behind a form submission. Below are three dummy forms, each with a different server response time.

Read more

Design Details: Incremental Correctness with Guillermo Rauch

In a recent Design Details podcast, Guillermo Rauch (@rauchg) shares his thoughts on the web, design, the value of code, type systems, cryptocurrencies and much much more.

I have a lot of respect for Guillermo's philosophies, and what he's building with Zeit. An early quote from the interview (paraphrased):

I've always had this passion for the hyperlink. My whole thesis is everything that has not yet been hyperlinked, will be hyperlinked. If we step back and take that thesis a little further—you look at GitHub and they but a hyperlink on everything. They put a hyperlink on every per-character diff of your codebase. Every line of code. Every changeset. Everything.

Listen to the full podcast on Spec.fm.

Server side rendering JavaScript from PHP

Server side rendering is a hot topic when it comes to client side applications. Unfortunately, it's not an easy thing to do, especially if you're not building things in a Node.js environment.

I published two libraries to enable server side rendering JavaScript from PHP: spatie/server-side-rendering and spatie/laravel-server-side-rendering for Laravel apps.

Let's review some server side rendering concepts, benefits and tradeoffs, and build a server renderer in PHP from first principles.

Read more

Diving into requestAnimationFrame with Benjamin De Cock

I love this post! requestAnimationFrame is a primitive browser API that doesn’t sound too interesting at first, but once you've grasped some basic concepts, it becomes an extremely powerful tool for dealing with animations in JavaScript.

At its core, requestAnimationFrame doesn’t do much: it’s basically just a method that executes a callback. In fact, there are very few differences between doing requestAnimationFrame(doSomething) and doSomething(). So, what’s so special about it? I’m glad you asked! In short:

  • requestAnimationFrame schedules the callback call on the next repaint
  • requestAnimationFrame passes the callback the current time

There are a few other distinctions, but these are the main benefits. Now, requestAnimationFrame doesn’t create an animation on its own, it’s the sequence of successive callbacks that will make things move on the screen.

My favorite part: since a large part of animating with requestAnimationFrame consists of composing small mathematical expressions, you can apply all sorts of functional programming tricks to your code.

Learn all about it on Benjamin De Cock’s blog.

Adventure Time with Webpack

Over the past few weeks I've been migrating our asset pipeline at Spatie from Laravel Elixir (a gulp wrapper) to webpack. Between having endless possibilities, the occasional incomplete section in the docs, and the fact that everyone has slightly different needs for their asset pipeline (which makes examples hard), it has surely been an adventure. I'm going to do a quick summary of my goals, and how I achieved them with webpack. Hopefully there will be some useful snippets in here for when you're setting up your own webpack configuration.

I'm not going to explain any basic concepts. If you're new to webpack, I'd recommend you to go through Webpack Your Bags on madewithlove's blog first. On the other hand, if you just want a tl;dr in the form of a webpack config file, our base configuration is hosted on Github.

Read more