Christian Heilmann

You are currently browsing the archives for the General category.

Archive for the ‘General’ Category

Decoded Chats – first edition live on the Decoded Blog

Tuesday, October 18th, 2016

Over the last few weeks I was busy recording interviews with different exciting people of the web. Now I am happy to announce that the first edition of Decoded Chats is live on the new Decoded Blog.

Decoded Chats - Chris interviewing Rob Conery

In this first edition, I’m interviewing Rob Conery about his “Imposter Handbook“. We cover the issues of teaching development, how to deal with a constantly changing work environment and how to tackle diversity and integration.

We’ve got eight more interviews ready and more lined up. Amongst the people I talked to are Sarah Drasner, Monica Dinculescu, Ada-Rose Edwards, Una Kravets and Chris Wilson. The format of Decoded Chats is pretty open: interviews ranging from 15 minutes to 50 minutes about current topics on the web, trends and ideas with the people who came up with them.

Some are recorded in a studio (when I am in Seattle), others are Skype calls and yet others are off-the-cuff recordings at conferences.

Do you know anyone you’d like me to interview? Drop me a line on Twitter @codepo8 and I see what I can do :)

crossfit.js

Tuesday, October 18th, 2016

Also on Medium, in case you want to comment.

Rey Bango telling you to do it

When I first heard about Crossfit, I thought it to be an excellent idea. I still do, to be fair:

  • Short, very focused and intense workouts instead of time consuming exercise schedules
  • No need for expensive and complex equipment; it is basically running and lifting heavy things
  • A lot of the workouts use your own body weight instead of extra equipment
  • A strong focus on good nutrition. Remove the stuff that is fattening and concentrate on what’s good for you

In essence, it sounded like the counterpoint to overly complex and expensive workouts we did before. You didn’t need expensive equipment. Some bars, ropes and tyres will do. There was also no need for a personal trainer, tailor-made outfits and queuing up for machines to be ready for you at the gym.

Fast forward a few years and you’ll see that we made Crossfit almost a running joke. You have overly loud Crossfit bros crashing weights in the gym, grunting and shouting and telling each other to “feel the burn” and “when you haven’t thrown up you haven’t worked out hard enough”. You have all kind of products branded Crossfit and even special food to aid your Crossfit workouts.

Thanks, commercialism and marketing. You made something simple and easy annoying and elitist again. There was no need for that.

One thing about Crossfit is that it can be dangerous. Without good supervision by friends it is pretty easy to seriously injure yourself. It is about moderation, not about competition.

I feel the same thing happened to JavaScript and it annoys me. JavaScript used to be an add-on to what we did on the web. It gave extra functionality and made it easier for our end users to finish the tasks they came for. It was a language to learn, not a lifestyle to subscribe to.

Nowadays JavaScript is everything. Client side use is only a small part of it. We use it to power servers, run tasks, define build processes and create fat client software. And everybody has an opinionated way to use it and is quick to tell others off for “not being professional” if they don’t subscribe to it. The brogrammer way of life rears its ugly head.

Let’s think of JavaScript like Crossfit was meant to be. Lean, healthy exercise going back to what’s good for you:

  • Use your body weight – on the client, if something can be done with HTML, let’s do it with HTML. When we create HTML with JavaScript, let’s create what makes sense, not lots of DIVs.
  • Do the heavy lifting – JavaScript is great to make complex tasks easier. Use it to create simpler interfaces with fewer reloads. Change user input that was valid but not in the right format. Use task runners to automate annoying work. However, if you realise that the task is a nice to have and not a need, remove it instead. Use worker threads to do heavy computation without clobbering the main UI.
  • Watch what you consume – keep dependencies to a minimum and make sure that what you depend on is reliable, safe to use and update-able.
  • Run a lot – performance is the most important part. Keep your solutions fast and lean.
  • Stick to simple equipment – it is not about how many “professional tools” we use. It is about keeping it easy for people to start working out.
  • Watch your calories – we have a tendency to use too much on the web. Libraries, polyfills, frameworks. Many of these make our lives easier but weigh heavy on our end users. It’s important to understand that our end users don’t have our equipment. Test your products on a cheap Android on a flaky connection, remove what isn’t needed and make it better for everyone.
  • Eat good things – browsers are evergreen and upgrade continuously these days. There are a lot of great features to use to make your products better. Visit “Can I use” early and often and play with new things that replace old cruft.
  • Don’t be a code bro – nobody is impressed with louts that constantly tell people off for not being as fit as they are. Be a code health advocate and help people get into shape instead.

JavaScript is much bigger these days than a language to learn in a day. That doesn’t mean, however, that every new developer needs to know the whole stack to be a useful contributor. Let’s keep it simple and fun.

We need JavaScript to fix the web

Friday, October 14th, 2016

TL;DR: JavaScript is too great an opportunity to build accessible, easy-to-use and flexible solutions for the web to not use it. It fills the gaps years of backwards-compatibility focus created. It helps with the problems of the now and the future that HTML and CSS alone can’t cover reliably. We shouldn’t blindly rely on it – we should own the responsibility to work around its flaky nature and reliability issues.

Patchy wiring

Right now, there is a lot of noise in our world about JavaScript, Progressive Enhancement and reliance on technology and processes. I’m in the middle of that. I have quite a few interviews with stakeholders in the pipeline and I’m working on some talks on the subject.

A lot of the chatter that’s happening right now seems to be circular:

  • Somebody makes a blanket statement about the state of the web and technologies to rely on
  • This ruffles the feathers of a few others. They point out the danger of these technologies and that it violates best practices
  • The original writer accuses the people reacting of having limited and anachronistic views
  • Stakeholders of frameworks that promise to make the life of developers a breeze chime in and point out that their way is the only true solution
  • 62 blog posts and 5212 tweets later we find consensus and all is good again

Except, it isn’t. The web is in a terrible state and the average web site is slow, punishes our computers with slow running code and has no grace in trying to keep users interacting with it. Ads spy on us, scripts inject malware and it is taxing to find content in a mess of modals and overly complex interfaces.

It is high time we, the community that survived the first browser wars and made standards-driven development our goal, start facing facts. We failed to update our message of a usable and maintainable web to be relevant to the current market and a new generation of developers.

We once fixed the web and paved the way forward

Our “best development practices” stem from a time when we had bad browsers on desktop computers. We had OK connectivity – it wasn’t fast, but it was at least reliable. We also created documents and enhanced them to become applications or get some interactivity later.

The holy trinity was and is:

  • Semantic HTML for structure
  • CSS for styling
  • JavaScript for some extra behaviour

That’s the message we like to tell. It is also largely a product of fiction. We defined these as best practices and followed them as much as we could, but a huge part of the web back then was done with WYSIWYG editors, CMS-driven or built with server-side frameworks. As such, the HTML was a mess, styles were an afterthought and JavaScript riddled with browser-sniffing or lots of document.write nasties. We pretended this wasn’t a problem and people who really care would never stoop down to creating terrible things like that.

There is no “the good old standards based web”. It was always a professional, craftsmanship view and ideal we tried to create. Fact is, we always hacked around issues with short-term solutions.

We had a clear goal and enemy – one we lost now

Browsers back then were not standards-aware and the browser wars raged. Having a different functionality than other browsers was a market advantage. This was bad for developers as we had to repeat all of our work for different browsers. The big skill was to know which browser messed up in which way. This was our clear target: to replace terrible web sites that only worked in IE6. The ones that were not maintainable unless you also had access to the CMS code or whatever language the framework was written in. We wanted to undo this mess by explaining what web standards are good for.

HTML describes a small use case

HTML describes linked documents with a few interactive elements. As quality oriented developers we started with an HTML document and we got a kick out of structuring it sensibly, adding just the right amount of CSS, adding some JavaScript to make it more interactive and release the thing. This was cool and is still very much possible. However, with the web being a main-stream medium these days, it isn’t quite how people work. We got used to things working in browsers differently, many of these patterns requiring JavaScript.

We got used to a higher level of interactivity as browser makers spend a lot of time ensuring compatibilty with another. We also have a few very obviously winning browsers and developers favouring them. Browsers are all great and open to feedback and there is no war among browser makers any longer. It is important to not block out users of older browsers, but there is no point in catering to them with extra work. Yes, you can go on the freeway with a car with broken indicators and no lights, but you are a danger to yourself and others. This is what surfing with old internet explorer is now.

The upgrade of HTML wasn’t as smooth as we make it out to be

HTML and CSS are gorgeous, beautiful in their simplicity and ensure that nobody on the web gets left out. Both technologies are very forgiving, allowing publishers of web content to make mistakes without making their readers suffer. This truth doesn’t change and – together with the beautiful simplicity that is a link – makes the web what it is. It is, however not good enough for today’s expectations of end users. It doesn’t matter if it is sturdy and can’t break it if is is boring or awkward to use.

Fact is that a lot of the amazing things of HTML aren’t as rosy when you look closer. One thing that opened my eyes was Monica Dinculescu’s talk “I love you input, but you’re letting me down”.

In it, Monica criticises the architecture and the implementation of the HTML input element. I was annoyed by that when I heard her hint at that earlier at Google IO. Surely this is wrong: INPUT is a beautiful thing. If you use input type range, end users of modern browsers get a slider, and older browsers a text box. Nobody is left out, it just gets better with better browsers. This is progressive enhancement at it’s best: built into the platform.

Except that the implementation of slider, number, URL and many of the other new input types that came with HTML5 is terrible. Monica shows some very obvious flaws in the most modern browsers that will not get fixed. Mostly, because nobody complained about them as developers use JavaScript solutions instead. So, yes, older browsers get a text box that works. But newer browsers get interfaces that disappoint or even make a simple task like entering a number impossible.

This is an inconvenient fact we need to own as something that needs to change. There is a lot of false information stating that functionality defined in the HTML5 standard can be used reliably and there is no need for JavaScript. This is simply not true, and, to a large degree, based on browser implementation. But, as Monica explains in detail, a lot of it is vaguely defined in the standard, was badly implemented in the beginning and now can’t be fixed in browsers as it would break a lot of live uses on the web. Every browser maker has to deal with this issue – we have a lot of terrible code on the web that still needs to work even if we’d love to fix the implementations.

There are other myths that keep cropping up. Adding ARIA to your HTML for example doesn’t automatically make your solutions accessible. Other than a few simple features like description any ARIA enhancement needs JavaScript to reach assistive technology.

The sturdy baseline we make HTML out to be has become much more fragile with the complexity we added when we moved with HTML5 from documents to apps. That doesn’t mean you should discard all semantic HTML and create everything with JavaScript. It does, however, neither mean that you can rely on HTML to magically solve usability and access issues for you.

The web as a platform isn’t fascinating to new developers – it’s a given

Developers who start building for the web right now never knew what being offline on a Desktop feels like. They never got stuck with a JavaScript-dependent solution blocking them out. They’ve seen a fair share of JavaScript abuse, and they do encounter broken sites. But in most cases a reload fixes that. There is hardly any “your browser isn’t good enough” happening any more.

For better or worse, the success of the web became its curse. We were the cool “new media”. However, these days, we’re not cool. We’re like plumbing. When you’re in a fairly well-off country, you turn on the tap and water comes out. You don’t care about the plumbing or where it comes from. It is just there. Much like the web.

This is what we wanted, now we need to understand that our fascination with everything web is not shared by people who never knew a world without it.

It is time to move on and let the new generation of developers deal with the problems of now instead of us waving a finger and demanding a work ethic that always was a perfect scenario and a small part of how the market worked.

The market is a rat race

Technology is the only properly growing market out there and we are part of that. This means a lot of pressure is on this market to continuously grow. It means that we need to be seen as constantly innovating. If that makes sense or if it is necessary is irrelevant. We just need to be bigger, faster and more – all the time. Yes, this isn’t sustainable, but it makes money and that is – sadly enough – still the main goal of our world.

This means that when we talk about development, people are much more likely to listen to the framework that offers “quick apps without much code”. Developers are also more likely to get excited about anything that offers to build “small, independent solutions that can be mixed and matched to build huge applications that scale”.

Building wheels from small reusable parts

Developers of the web these days aren’t asked to architect a clean, accessible and very well structured web document. If we are fair to ourselves, we were never asked to do this. We did it because we cared, and to make our lives easier. Standard driven development was there to protect us from reinventing the wheel. However, these days, this is exactly what is expected of a cool new company and developers. We live in a world of components. We are continuously asked to build something fast that others can reuse in any product. That way you can have 10 developers work on a product in parallel and you can remove and add functionality as it is needed.

This is how we got solutions like “Object Oriented CSS“. The Cascade is a beautiful part of CSS that allows you to write a few lines that get applied to thousands of documents without you needing to repeat your definitions. This is working against the concept of reusable, small components that don’t inherit any look and feel from their parent container. Our use case changed, and the standards didn’t deliver the functionality we needed.

We’re mobile, and our best practices aren’t

Our world has changed drastically. We now live in a world where Desktop is not as important. Everything points to the next users of the web being on mobiles. This doesn’t mean Desktops are irrelevant and our solutions for that form factor bad.

It means that our “best practices” don’t solve the current issues. Best practices aren’t defined. They are found by trial and error. This is how we got where we are now with crazy CSS hacks like resets, browser filters (midpass using voice CSS anyone?) and many other – now considered terrible – ideas.

We need to find solutions for bad or no connectivity on fairly capable browsers on interfaces that aren’t keyboard driven. We need solutions for small screens and interactivity ready for big fingers or voice control.

Yes, the most hard core scenarios of this world mean you can’t rely on client side scripting or a lot of storage space. Proxy browsers and battery or data saving settings of some browsers interfere with what we can do on the client. On the whole though what we deal with is a pretty capable computer (surely much better than the ones we had when we defined our best web practices) on a small screen device with dubious, non-reliable or even non-existing connectivity.

Enter the new, old hero: JavaScript

Now, JavaScript gives us a lot of great features to cater for this world. We can use ServiceWorker to offer offline functionality, we can store content in a reliable manner on the device by using IndexedDB instead of relying on a browser cache and we have the DOM and events to enhance HTML interfaces to become touch enabled without delays. More importantly, we have a way to demand functionality on the fly and test if it was successful before applying it. We have a very mighty “if” statement that allows us to react to success and failure cases. Developer tools give us full insight into what happened, including slow performance. Yes, this is a much more complex starting point than writing an HTML document and adding some CSS. But this is why we are paid as professionals. Everyone is invited to contribute to the web. Professionals who expect to be paid for creating web content need to do more.

We can create interfaces that are great to use, intuitive and accessible if we use some semantic HTML, CSS and JavaScript. Instead we keep harping on about using HTML for everything, CSS if we can and JavaScript if we must. Many “CSS only” solutions have dubious accessibility features and expect a lot of knowledge of CSS quirks from the maintainer. Enough already. Great solutions are not limited to one of the web technologies and demanding expert care. They are a mix of all of them, catered to the needs of the users.

We need to take on the responsibility of JavaScript

If we see JavaScript as a given and we constantly remind ourselves about its non-forgiving nature we have a new baseline to build amazing solutions for the current and future web. The main thing we have to understand is that it is our responsibility to make our products load fast, work smoothly, and to be accessible to those with a sensible environment. We can not rely on the sturdiness of the web of old to take that responsibility away from us. We need to own it and move the web forward.

This doesn’t mean we need to blindly use JavaScript and frameworks to deliver our products. There is space for many different solutions and approaches. It does mean, however, that we shouldn’t limit us to what made sense over a decade ago. New form factors need new thinking, and I for one trust those rebelling against the best practices of old to find good solutions much like we defined our best practices based on stalwart and short-term solutions of those before us.

JavaScript abuse is rampant. It is the main reason for security issues on the web and terrible performance of the average web site. We shove functionality and ads in the face of end users in the hope of keeping them. Instead we should use browser and hardware functionality to deliver a great experience. With JavaScript I can react to all kind of events and properties of the computer my product is consumed in. Without it, I need to hope that functionality exists. Only by owning the fact that JavaScript is a given we can start making the clogged up web better. It is time to clean up the current web instead of demanding the “good old web” that never really existed.

Photo credit: John Loo via Visual hunt / CC BY

Can we stop bad-mouthing CSS in developer talks, please?

Wednesday, October 5th, 2016

At almost every developer conference right now there will be a talk that features the following “funny GIF”:

funny CSS gif
Peter Griffin aka Family Guy trying to make some blinds close and making a total mess of it, randomly dragging the cords until he gives up and rips them off the window. With the caption CSS.

It is always a crowd pleaser, and can be a good introduction to the issues of CSS and some examples how to fix them. In most cases – and the likeliness of that increases with how “techy” the conference is – it is the start of a rant how bad CSS is, how its architecture is terrible and how inconsistent it is. And, and, and…

Here’s the thing: I am sick of this. It is not clever, it is not based in fact and it makes us appear as arrogant know-it-alls that want everything to work the way we are used to. It drives a firm divider between “developers” and “people who do web stuff”, aka “not real developers”. Which is nonsense. Arrogant, dangerous nonsense, not helping us – at all – to grow our developer community and be more exciting for a new, diverse, crowd to join.

Here’s a fact: we build incredibly complex, exciting and beautfiful things on the web. The most democratic distribution system of information and – by now – a high fidelity and exciting software platform. If you think you know every facet of this, you can do it all without relying on other experts to work with you, and in the one technology you like, you’re blinded by your own ambition. And an arrogant person I really could not be bothered to work with.

Yes, it is easy to poke fun at CSS and it’s Frankenstein-esque syntax. It is also easy to show that you can do all the things it does with other technologies. But that gives you no right – at all – to belittle and disregard the people who like CSS and took it as their weapon of choice to build great user interfaces.

In other words: if you don’t like it, don’t use it. Work with someone who does like it. It is a self-fulfilling prophecy that when you use a technology that you don’t take serious and you don’t like, the end result will be bad. It is a waste of time. When you complain about the issues you faced because you want the technology to bend to your comfort zone’s rules you really complain about your failure to use it. It doesn’t apply to those who happen to like the technology and play it to its strengths.

Another one that always crops up is the “CSS is awesome” coffee mug:

css is awesome mug

The joke here is that CSS is inadequate to fix that problem of overflowing text. Well, my question is how should that be handled? Overflow with scroll bars? That’s possible in CSS. Cutting the text off? Also possible. Shortening the text followed by an ellipsis? That’s also possible. Are either of those good solutions? No. The main thing here is that the text is too big to fit the container. And a fixed container is a mistake on the web. You can’t fix anything in an environment that by definition could be any size or form factor. So the mistake here is a “fixed container” thinking, not that CSS doesn’t magically do something to the text you can’t control. This, in interfaces, would really get you into trouble.

I challenge anyone to look at the mind-boggling things Ana Tudor does with CSS and tell me that’s not “real programming” and based on a “stupid language”.

See the Pen cube broadcast (pure CSS) by Ana Tudor (@thebabydino) on CodePen.


I challenge you not to see the benefit of flexbox and the ability it gives us to build dynamic interfaces that can adapt to different amounts of content and the needs of smaller versus bigger screens as explained by Zoe Mickley Gillenwater:


Zoe Mickley Gillenwater | Flexbox | CSS Day from Web Conferences Amsterdam on Vimeo.

I challenge you not to get excited about the opportunities of grid layouts as explained by Rachel Andrews:

I challenge you not to be baffled by the beauty of using type and shapes to build complex layouts that are not hindered by a fixed pixel thinking as explained by Jen Simmons.

I challenge you not to marvel at the power of CSS filters and blend modes and what they empower an artistic mind to do as explained by Una Kravets:


SmashingConf Freiburg 2016 – Una Kravets on Practical Blend Modes from Smashing Magazine on Vimeo.

So next time you think about using “the CSS joke”, please understand that people who care do not try to colour some text. CSS is a very expressive language to build complex interfaces that cater to a lot of varying user needs. If you can’t get your head around that – and I am admitting that I can’t anymore – have the decency to not belittle those who do. Applaud them for their efforts and work with them instead.

Quick tip: using modulo to re-start loops without the need of an if statement

Thursday, September 29th, 2016

the more you know

A few days ago Jake Archibald posted a JSBin example of five ways to center vertically in CSS to stop the meme of “CSS is too hard and useless”. What I found really interesting in this example is how he animated showing the different examples (this being a CSS demo, I’d probably would’ve done a CSS animation and delays, but he wanted to support OldIE, hence the use of className instead of classList):

var els = document.querySelectorAll('p');
var showing = 0;
setInterval(function() {
  // this is easier with classlist, but meh:
  els[showing].className = els[showing].className.replace(' active', '');
  showing = (showing + 1) % 5;
  els[showing].className += ' active';
}, 4000);

The interesting part to me here is the showing = (showing + 1) % 5; line. This means that if showing is 4 showing becomes 0, thus starting the looping demo back from the first example. This is the remainder operator of JavaScript, giving you the remaining value of dividing the first value with the second. So, in the case of 4 + 1 % 5, this is zero.

Whenever I used to write something like this, I’d do an if statement, like:

showing++;
if (showing === 5) { showing = 0; }

Using the remainder seems cleaner, especially when instead of the hard-coded 5, you’d just use the length of the element collection.

var els = document.querySelectorAll('p');
var all = els.length;
var c = 'active';
var showing = 0;
setInterval(function() {
  els[showing].classList.remove(c);
  showing = (showing + 1) % all;
  els[showing].classList.add(c);
}, 4000);

A neat little trick to keep in mind.