A couple of months ago I stumbled across Mikeal Rogers’ article I’ve seen the future, it’s full of HTML. in which he lays out his reasons why he started to dive into Web Components for the web apps he is working on right now and hinted to the workflow he uses.
His enthusiasm for Web Components is infectious and because I have a lot of respect for Mikeal and his work, his article was a strong signal for me personally that Web Components might be something to take a closer look at.
Polymer didn’t help a lot either: all I heard was Polyfills and Bower and WTF is Shady DOM?
And oh yeah everybody kept screaming “OH PRAISETH OUR NEW LORD AND SAVIOR HIS HOLINESS THE REACT”.
So I kept ignoring it.
I was like: “No tooling? Hmmm… that sounds pretty sweet.”
A few weeks ago I took some time to write a tiny application just with Web Components. I used no tooling, no compilation no polyfills, no nothing. Just Chrome, ES 2015+, ES Modules,
<template>, Custom Elements and an “actions up data down” data flow with Custom Events.
I used the CMD-R (CTRL-R on Windows) web development workflow as Alex Russel calls it.
Now that’s a developer experience 😉!
It was surprising to me how freeing it was to be able to use modern syntax, modules and a component architecture in the browser without any tooling. Not to mention the excellent debuggability since you are feeding the browser what you write directly.
Just write your app using Chrome and then make a bundle with dynamically loaded polyfills to make it work everywhere.
As it stands currently that latest versions of Google Chrome, Safari and Opera support these technologies natively, Firefox and Edge are lagging behind but working on it.
Jake Archibald on Netflix removing React from their landing page:
Netflix has shown you could start with React on the server, then activate the client side parts if you need them, when you need them, and where you need them.
I hope this starts to become state of the art.
In this episode of the German podcast Working Draft Golo Roden does a great job explaining what DDD (Domain-Driven Design), CQRS (Command Query Responsibility Segregation) and Event Sourcing is and how his new project wolkenkit can help developers applying those principles and patterns.
Just is a collection of dependency-free modules for common operations on Arrays, Collections, Strings, Objects and Functions started by @angustweets. “Do we really need something like that when we have Lodash?” you might ask.
Angus does a great job explaining why he started Just:
Just is designed for those who value easy to follow, debuggable utilities over version lotto and yak-shaving down the module tree. There’s nothing fancy or particularly clever here. You won’t find elaborate routines that optimize for trillion element arrays; just short, cohesive, readable code––the sort of helper functions we all inline in our projects every day because edge case optimizations that we’ll never need aren’t worth the overhead and the uncertainty of a sprawling dependency chain.
Since I heard it for the first time, I was struggling to understand what “Functions As A Service” like AWS Lambda really is. I heard people explaining it on podcasts and read what it said on the AWS Lambda landing page but it just didn’t click.
Last week me and Henning recorded the lastest episode of our podcast REACTIVE. On that episode Henning talks about how he uses AWS Lambda and an AWS database to build an API for their app at work. This made me finally understand what this is all about.
They built the API by writing some code that parses request parameters, retrieves some data from the database and then sends that data back as JSON in the JSON API format. That code is the function that is being provided “as a service”.
That is it.
The HTTP layer, security and scalability is all provided by AWS services. Functions As A Service also means that you only pay for computing time when the function is used. When there is no requests to the API then you don’t pay.
This is an incredibly fast and efficient way to build an API that is production ready in no time.
On the podcast we also talked about how more and more of these “solved problems” like security and scalability will be packed up into some service and how the usage of them will certainly be very widespread in the not so distant future.
@codepo8 said it best on Twitter yesterday:
Prediction: in five years most of what we call "coding" now will be done by machines. And they'll be much better at it.— Chris Heilmann (@codepo8) October 23, 2017
OK, I have no proof that this is actually true, but it is a fun thought experiment / conspiracy theory. Here me out.
I am pretty sure this change will be extremely well received by everybody using React.
It will also ensure that the majority of React users will switch to React 16 (the first version under the MIT license) because their BSD + patents license is widely mistrusted and / or disliked.
I for one like to think that this change was triggered by the shots that Matt Mullenweg fired in his post “On WordPress and React” a few days ago. I re-read his post a couple of times because I found some of the statements he made very interesting. At first glance the post reads like “OK WordPress just ditched React no big dizzle” but after re-reading it I realized that Matt just deprived React of a quantum leap in growth. Wow. Let’s go through the interesting points:
Big companies like to bury unpleasant news on Fridays
This statement is in context of Facebook’s post about sticking with the BSD + patents license after the Apache Foundation put their license on the black list.
Right in the beginning of his article he accuses Facebook of shady behavior.
I’m not judging Facebook or saying they’re wrong, it’s not my place.
This is hilarious. Translation: “I am judging Facebook and I am saying they are wrong.”
We had a many-thousand word announcement talking about how great React is and how we’re officially adopting it for WordPress, and encouraging plugins to do the same. I’ve been sitting on that post, hoping that the patent issue would be resolved in a way we were comfortable passing down to our users.
Now for the squeeze.
Squeeze even harder:
Core WordPress updates go out to over a quarter of all websites, having them all inherit the patents clause isn’t something I’m comfortable with.
Translation: “For realz Facebook?!?!? You don’t want your Framework to be used by over 25% of all websites on the internet with a snap of a finger!?!? Maybe y’allz want to think about that a little bit?”
Now for the kill:
But we have a lot of problems to tackle, and convincing the world that Facebook’s patent clause is fine isn’t ours to take on. It’s their fight.
Translation: “We don’t need all your drama. You’re on your own.”
We’ll look for something with most of the benefits of React, but without the baggage of a patents clause that’s confusing and threatening to many people.
Translation: “React is not indispensable and can easily be switched out with something similar, thank you.”
So good. He whacked them over the head in the nicest way possible.
It makes total sense to me that Matt’s post would make them rethink their licensing strategy. The Apache Foundation reject did not really mean a big impediment to their growth but loosing WordPress would deprive them of more massive adoption and may even mean a decline in React adoption going forward because Matt and WordPress as a project are just incredibly influential in the web development community.
Matt has already reacted to Facebook’s anouncement:
I am surprised and excited to see the news that Facebook is going to drop the patent clause that I wrote about last week. They’ve announced that with React 16 the license will just be regular MIT with no patent addition. I applaud Facebook for making this move, and I hope that patent clause use is re-examined across all their open source projects.
Matt is pleased about the change.
Particularly with Gutenberg there may be an approach that allows developers to write Gutenberg blocks (Gutenblocks) in the library of their choice including Preact, Polymer, or Vue, and now React could be an officially-supported option as well.
Looks like the WordPress team found out about this new-fangled compiler that Jason Miller of Preact-fame is working on which compiles, Web Components, VueJS components and Preact components into highly optimized Preact components. That’s awesome.
Meanwhile React 16 has been released and the license is indeed MIT.
My blog used to be a Medium publication with a linked domain but I ditched Medium. I was disappointed with the design directions they are taking. I was a big fan of Medium’s design before the recent change to the new serif wordmark. It feels disjointed to me now and it is apparent that they are pushing their paid services and are working hard to make an actual business out of Medium. That’s all good and fine but I don’t like the changes and that made me realize I need to have more control over my blog again.
Also I wanted to consolidate kahlil.info and kahlillechelt.com. So here we are. New blog same old me.
For now I am leaving my old blog posts over there on Medium. I will port them over eventually. Maybe. I will be cross posting my blog posts from here over at Medium as well. The readership you get over there via their network is really nice.
The initial inspiration for the design was a quick study that @magalhini posted to Twitter a while ago. I played around with it but wanted a different font pairing. After some googling I found Typewolf Google Fonts and Great Simple, two websites that suggest Google font pairings. I ended up choosing Roboto Mono as a main font and Rubik for my wordmark.
I found the pairing here and after I saw it I kept coming back to it. So I went with it. I really like using a monospace font for the body text.
I am happy with it. Keeping it simple.
As a web developer I have to use a static site generator of course. Which one you ask?
Hugo is written in Go and comes as a binary. It’s wicked fast and can easily deal with huge amounts of posts.
It has been around for a while now and is really flexible. It works very similarly to other static site generators like Jekyll or Metalsmith.
For hosting I went with Netlify, I’ve been really impressed with their user experience for hosting static pages. If your site is on Github it is incredibly easy to deploy it to Netlify:
The site gets redeployed every time you push to master (this feature can be turned off) and if I push a branch to the site’s Github repo Netlify will attempt to deploy a preview automatically. It’s truly a joy to use.
If you are interested in the code for this site you can find it on Github.