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.

I used to think disabled JavaScript went hand in hand with visitors explicitly blocking it. I came to the conclusion that I don't necessarily need to cater to that crowd, because the degraded user experience was by choice. After reading through this chart, I realized how wrong I was.

Sometimes your JavaScript just won’t work. Be prepared.

Read the flowchart on kryogenix.org.

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.

One of the best things about Vue templates is the special v-model prop. v-model allows you two quickly map prop getters and setters without breaking unidirectional data flow. Props down, events up.

Read more

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

In my most recent project at work, I'm experimenting with JSX templates in Vue. Vue offers first-party support for JSX with near-zero configuration, but it doesn't seem to be commonly used in the ecosystem.

Read more

Code splitting is bundler feature—if you're using Laravel Mix, you're bundling your assets with Webpack—that allows you to split application scripts in multiple files. These can then conditionally be loaded at a later stage.

Read more

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 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

Last month I travelled up north to my first JavaScript conference: Nordic.js. The entire conference was a great experience: the speakers, the location, the food (kanelbullar!), ... Here's a quick recap of my favorite talks.

Read more

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.

A lot has been going in in JavaScript the past few years. One of my favorite things has been the usage of babel, which allows us to write future JavaScript syntax today. The babel ecosystem has tons of plugins and configuration options, I'd like to elaborate on our usage at Spatie.

Read more

Today I was writing a form component that needed an optional back button. Since the form component is generic, the back button could point to anything.

Read more

Vue 2.0 introduced it's own virtual DOM implementation. At first sight, this doesn't seem to have a large effect on the way you write templates.

Read more

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