Web truths that cause infinite loops

Every few months there is a drama happening in the blogging and social media scene. We seem to need that to keep ourselves occupied. It allows us to get distracted from the feeling that the people who pay us have no idea what we do. And keep praising us for things we are not proud of, cementing our impostor syndrome.

For an upcoming talk, I analysed the recurring themes that we get fired up about. I will post one on each of these over the next few weeks.

  • CSS is not real programming and broken
  • JavaScript can’t be trusted
  • We need granular control over web APIs, not abstractions
  • The web is better than any other platform as it is backwards compatible and fault tolerant
  • The web is broken and backwards compatibility is holding us back
  • Publishing on the web using web standards is easy and amazing
  • The web is world-wide and needs to be more inclusive
  • Mobile is the present and future

Each of these topics can spark thousands of reactions, dozens of blog posts. Many will get you a speaking slot at an event. They are all true, but they are also all not necessarily yielding the amazing insight we expect them to. I’ll try to explain why they are endless loops and what we could do to get past discussing these over and over again. Maybe it is a good time to concentrate on solving other, new, problems instead. And recognise that a new generation of makers and developers may not be as excited about them as we are.

Yes, these will be my opinions and they may spark some discourse. That’s fine. You can disagree with me, and I promise to keep this to the point and civil. I’ve done this for a very long time, I’ve heard many people talk and discuss these. Hopefully my insights will hit a mark with some of you and make us reconsider rehashing the same old discussions over and over again.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Web truths: CSS is not real programming

This is part of the web truths series of posts.

Every few months there is an article claiming that CSS is not real programming. That CSS is too hard and broken. The language used in these can get creative:

There is truth to the fact that working with CSS is not traditional programming. There is also truth that CSS has its language faults and that some things are much harder than they should be. That is the case with any standardised language, though. CSS is a way to describe what an interface should be like. It is not the implementation of said interface in a programmatic fashion, like, for example, the Canvas API. That CSS is not like a traditional programming language is by design.

CSS is a great idea when it comes to creating an interface for something as complex and unknown as a user on the web. I talked about the difference of CSS and JavaScript in detail at GOTO Amsterdam where I called it a decision between trust and control.

As a CSS developer, you trust the user agent (in most cases a browser) to do the right thing. You can’t control that it happens, but you also don’t need to sweat the details like performance, paint time and responsiveness. This ball is in the court of the user agent creators and the OS it runs on. And that is a great thing as it allows to fix those important things in one place – where they get applied. If you create interfaces or animations using JavaScript, you have much more granular control. But you also need to ensure everything works. Using CSS means giving up control for the sake of having more time to build a responsive interface catering to the users’ needs. Users need and can mess with your interface settings. CSS is OK with that. Pixel-perfect, defined interfaces are not.

CSS development isn’t programming in the traditional sense where you have loops, conditions and variables. CSS is going that direction to a degree and Sass paved the way. But the most needed skill in CSS is not syntax. It is to understand what interfaces you describe with it. And how to ensure that they are flexible enough that users can’t do things wrong and get locked out. You can avoid a lot of code when you understand HTML and use CSS to style it.

If you don’t consider an interface as an agreement with your users with various levels of fidelity depending on their technical platform, CSS isn’t for you. It is by design a forgiving language, that doesn’t throw any errors when something can’t get applied. Thus it is amazing for progressive enhancement. You don’t even need to worry about adding a line of unsupported code as the parser skips what it can’t apply. What causes a JavaScript parser to throw in the towel and give you an error message, the CSS parser shrugs off and moves on. That can feel odd for a developer – I for one like to know when something went wrong. But it frees you from needing to test on all possible user agents and put “if” statements around everything. Want to use a gradient on button? Define a background color, then override it with a gradient in the next line. If the user agent can’t render gradients, you get a simpler, but still working button. And you didn’t need to worry about gradient support at all.

A lot of “CSS is not real programming” arguments are a basic misunderstanding what CSS is there to achieve. If you want full control over and interface and strive for pixel perfection – don’t use it. If you want to build an interface for an inclusive and diverse web, CSS is a great tool. Writing CSS is describing interfaces and needs empathy with the users. It is not about turning a Photoshop file into a web interface. It requires a different skillset and attitude of the maintainer and initial programmer than a backend language would.

In any case, belittling people who write CSS and considering them not real developers is arrogant nonsense. Especially when you don’t even spend the time to understand what CSS tries to achieve and how amazing it has become.

On the other hand, CSS is not and should not be the solution for everything. Yes, you can create pixels with drop shadows, but you also punish the browser rendering engine with this.

CSS is an integral part of the web to me and whilst the syntax is weird for someone coming from a different programming language, it proved its worth over the years. It should and will not go away for quite some time. So if you don’t like it, pair with someone who does. If your managers demand you to do it, we don’t have a technical issue at our hands, but a project/staffing one.

Instead of having discussions if CSS is broken and needs to be replaced, it is healthier to have different discussions about CSS:

  • What CSS can do and where it isn’t enough
  • What CSS can do these days that needed other technology in the past and how to apply it
  • How to write CSS in a maintainable fashion
  • What can you do to make the life of the CSS developer easier?
  • What CSS hacks we used and why we should not use them anymore
  • What can we do to make CSS richer and better?

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Reasons to attend and/or speak at Reasons.to

I am currently on the train back to London after attending the first two days of Reasons.to in Brighton, England. I need to go to pick up my mail that accumulated in my London flat before going back to Berlin and Seattle in a day, otherwise there would be no way I’d not want to see this conference through to the end.

Reasons.to stage sign

I don’t want to go. Reasons.to is an amazing experience. Let me start by listing the reasons why you should be part of it as an attendee or as a presenter. I will write up a more detailed report on why this year was amazing for me personally later.

Why reasons.to is a great experience for attendees:

Reasons.to is a conference about creative makers that use technology as a tool. It is not a conference about hard-core technical topics or limited to creating the next app or web site. It is a celebration of creativity and being human about it. If you enjoy Beyond Tellerand, this is also very much for you. That’s not by accident – the organisers of both shows are long-term friends and help each other finding talent and getting the right people together.

As such, it demands more of both the presenters and the audience. There are no recordings of the talks, and there is no way to look up later what happened. It is all about the here and now and about everyone at the event making it a memorable experience.

Over and over the organisers remind the audience to use the time to mingle and network and not worry about asking the presenters for more details. There is no Q&A and there is ample time in breaks to ask in person instead. Don’t worry – presenters are coached that this is something to expect at this event and they all agreed.

There is no food catering – you’re asked to find people to join and go out for breaks, lunches and dinners instead. This is a great opportunity to organize yourselves and even for shy people to leave with a group and have a good excuse to get a bit out of their shell.

This is a getting to know and learning about each other event. And as such, there is no need to advertise itself as an inclusive safe space for people. It just is. You meet people from all kind of backgrounds, families arrive with children and all the people involved in putting on the show know each other.

There are no blatant sponsored talks or holy wars about “framework vs. library” or “technology x vs. technology y”. There is no grandstanding about “here is what I did and it will revolutionise our little world”. There is no “I know this doesn’t work yet, but it will be what you need to use else you’d be outdated and you do it wrong”. And most importantly there is no “this is my showreel, am I not amazing” presentations that are sadly enough often what “creative” events end up having.

The organisers are doing a thorough job finding presenters that are more than safe bets to sell tickets or cover the newest hotness. Instead they work hard to find people who have done amazing things and aren’t necessarily that known but deserve to be.

If anything, there is a very refreshing feeling of meeting people whose work you may know from advertising, on trains, TV or big billboards. And realizing that these are humans and humble about their outrageous achievements. And ready to share their experiences and techniques creating them – warts and all.

The organisers have a keen eye on spotting talent that is amazing but not quite ready to tell the world about it and then making them feel welcome and excited about sharing their story. All the presenters are incredibly successful in what they do, yet none of them are slick and perfect in telling their story. On the contrary, it is very human to see the excitement and how afraid some of these amazing people are in showing you how they work.

Reasons.to is not an event where you will leave with a lot of new and immediately applicable technical knowledge. You will leave, however, with a feeling that even the most talented people are having the same worries as you. And that there is more to you if you just stop stalling and allow yourself to be more creative. And damn the consequences.

Why reasons.to is a great idea for presenters

As a presenter, I found this conference to be incredibly relaxed. It is an entity, it is a happening that is closed in itself without being elitist.

Not having video recordings and having a very low-traffic social media backchannel might be bad for your outside visibility and makes it harder to show the impact you had to your manager. But it makes for a much less stressful environment to present in. Your job is to inspire and deal with the audience at the event, not to deliver a great, reusable video recording or deal with people on social media judging you without having seen you performing or being aware of the context in which you said something.

You have a chance to be yourself. A chance to not only deliver knowledge but share how you came by it and what you did wrong without having to worry about disappointing an audience eager for hard facts. You can be much more vulnerable and human here than at other – more competitive – events.

You need to be ready to be available though. And to spend some extra time in getting to know the other presenters, share tips and details with the audience and to not be a performer that drops in, does the show and moves on. This event is a great opportunity not only to show what you did and want people to try, but it is also a great event to stay at and take in every other talk. Not to compare, but to just learn about people like you but with vastly different backgrounds and approaches.

There is no place for ego at this event. That’s a great thing as it also means that you don’t need to be the perfect presenter. Instead you’re expected to share your excitement and be ready to show mistakes you made. As you would with a group of friends. This is refreshing and a great opportunity for people who have something to show and share but aren’t quite sure if the stage is theirs to command.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

All You Need to Know about Metatags

This guest post was created by Helen Miller (Marketing Manager at Template Monster). Many thanks to Helen for making this available to our readers.

Not all the content of an HTML page is visible to end users. Metadata that reside in the webpage’s header is visible to search engine crawlers (and others who view the source code). Nevertheless, it’s still important for you as a part of the on-page SEO (Search Engine Optimization). In this article I give a brief characteristic of the most frequently used metatags and determine their role in on-page SEO in 2017.

All You Need to Know about Metatags

What is Metatag?

Metatag is an HTML tag that is situated in the webpage’s header and provides crawlers with the information about the information, presented on the page. Metadata is meant to specify post description, author, date of publication and other relevant information that’s useful for crawlers.

Notwithstanding the fact that all modern browsers, such as Google Chrome, Mozilla Firefox, Opera and IE, support metatags, not all the metatags are actually attended to by the search engines. The reason for this is that Internet space has evolved over time, and some metatags that were abused by spammers in the past, are now ignored by crawlers, and do not affect your page’s ranking.

What are Most Used Keywords and How to Optimize for Them?

In this article, we’ll speak about the three most important metatags, such as Title, Description and Keywords metatags. Let’s look into them one by one and determine their optimal length, examine their examples and go for tips on how to optimize for them to maximally boost your on-page SEO.

Make Your Statement: Title Tag

Title tag is not metadata per se, although it’s specified in the website’s header. Title tag is visible not only to crawlers, but to website users as well, which makes it double important. First of all, people searching for a certain keyword see what’s specified in your title tag on the SERP (Search Engine Results Page). For this reason, your title used in the title tag is also referred to as a SEO title. Secondly, SEO title appears in your browser window’s header on the tab that stands for opened page. Lastly, it gets displayed in social networks when your post gets shared.

SEO title is very important in decision-making process of potential website guests. It’s the boldest text displayed in your SERP entry. Moreover, crawlers do attend to it and will display your website’s page based on the keywords that your SEO title contains. The closer the keyword to the beginning of the title, the more likely it’s to be displayed.

How Does It Look from Inside?

Title tag is added to the head part of an HTML page and typically looks like shown in the following example:

HTML Source Code with focus on title tag

CMS engines tend to make your life simpler (which is not always desired) and form the SEO title automatically based on the provided page title. This is often not what you desire. To get the desired, optimized SEO title, you’ll have to resort to one of the useful (in many ways) SEO plugins, e.g. Yoast SEO plugin for WordPress.

With this plugin you get an opportunity to point a SEO title that’s optimized for certain keywords and boost your on page SEO by this.

Example of Yoast plugin snippet

How to Optimize Your Title Tag?

The main tips that concern your title tag optimization are the following:

  • Length: the optimal length of a title tag is 50 – 60 characters (including spaces). Do not exceed this limit as your title will be cut off by search engines. Do not be too concise: use your chance to use your limit of 50 – 60 characters to the fullest.
  • Placement of a keyword: your focus keyword should be shifted to the beginning of the title; then come the least important words.
  • Use unique title tag: your title tag should be unique for every page on your website. Do not duplicate your title tags for max SEO impact.
  • Mind relevance: watch out you title tag’s relevance. If Google or other search engine would deem your title tag irrelevant, they’ll replace it with an automatically generated one that would hardly be as good as your coined one.
  • Avoid keyword stuffing: if your repeat your keyword over and over or stuff your title with multiple keywords, search engines would penalize you for such a practice, so avoid it.
  • Make your article title different from SEO title: this is your extra chance to rank for different keywords with one post.

Let’s now review an example of how these tips can be used in practice:

In our case the focus keyword is ‘best burgers in London’. The SEO title of an article was optimized in the following way:

Title tag example presenting best burgers in London

This is a very well-optimized title as it starts with the focal keyword that is then followed by a very appealing headline that uses ‘buns’ instead of ‘burgers’ to avoid repetition. The SEO title fits into the maximum length of the title tag, so the title is not cut off on the SERP.

To learn more about how to optimize meta tags in WordPress themes, check out the following video-tutorial by TemplateMonster, one of the leading template providers on the market:

What Your Article Is About: Description Metatag

Description metatag is used to provide a brief description of your page’s/post’s content to crawlers, so that they know what your page/post is about. A well-written description is often displayed by search engines on the SERP, so users may read it and make a decision whether to open your website based on it. If a search engine finds your meta-description not good enough, it will replace it with text snippets from your article on the SERP.

Description metatag highlighted

Google has recently stated that it does not rank pages for keywords used in the meta-description. However, it’s still important for your on page SEO as it does tell the search engines what your content is about (and helps them make a decision whether to crawl the page further), and, if displayed, influences user’s decision making process on SERP, thus, influencing your click-through rates.

How Does It Look in HTML?

Description metatag has the following look in HTML:

Description metatag in HTML

How to Optimize Description Metatag?

Follow the tips below to get a concise and informative meta-description:

  • Length: limit your meta description to no more than 155 characters. Search engines can display only a limited number of words on the SERP. If your meta-description is longer than this, it will be cut off in the middle of what you have to say. I bet this is not a desired result.
  • Include a CTA: if you want your description to work better for you on the SERP, add a short CTA (Call To Action) to it. ‘Read more’ or ‘Find out more’ would suffice.
  • Use a unique description: go for a description that has not been already used, otherwise you may run into serious duplicate content issues and your content will be ignored by search engines.
  • Include keywords anyway: although Google doesn’t rank for keywords in meta-description, they are highlighted in bold on the SERP. This means that users will pay more attention to your SERP entry if you include a keyword to your article. See an example below:

Call to action highlighted in metatag

They Are Still There: Keywords Metatag

I may say that currently Keywords metatag is passé and is completely ignored by search engines (except for Bing that looks on them just with the purpose of penalizing spammy websites). How did this happen?

As keywords are the core of search on the net, Keywords metatag became an easy abuse target. In the past, website owners, eager to boost their SEO rank and traffic, ‘stuffed’ absolutely unrelated (but popular on the net) keywords for their article. For instance, they inserted ‘Rihanna’ as a keyword to a page about spare parts and fooled search engines by this.

At present, search engines got wiser, and completely abandoned Keywords metatag to avoid all sorts of ‘keyword stuffing’.

How Does This Metatag Look in HTML?

Keywords metatag has the following appearance in an HTML document:

View of HTML with keywords in metatag

How to Optimize for Keywords Metatag?

There is no need to care for this metatag any more. Some SEO experts say it’s totally OK to leave it out completely, others advice to still go for a couple of keywords, ‘just in case’. It’s up to you whether to provide keywords in this metatag or not, but don’t ponder over this question too long.


To boost your on page SEO, its important to pay careful attention to such page head elements as title tag and meta-description. Make sure you use your focal keyword in these elements and keep close to the max length limit for the elements, but do not exceed it. Regarding Keywords metatag, it’s kind of passé, so the need for its even minimal optimization is dubious.

If you want to learn more about SEO optiomization of a website, get hold of the following insightful free e-book:

 Free ebook


Are there any topic-related questions that I’ve missed? Let me know in the comment section below and I’ll be happy to get back with you.

Happy optimizing!

Thanks again to Helen Miller (Template Monster) for providing this post.

The post All You Need to Know about Metatags appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

DevRelSummit was well worth it

Last week I was in Seattle to attend a few meetings and I was lucky to attend DevRelSummit in the Galvanize space. I was invited to cover an “Ask me anything” slot about Developer Outreach in Microsoft and help out Charles Morris of the Edge team who gave a presentation a similar matter.

It feels weird to have a conference that is pretty meta about the subject of Developer relations (and there is even a ConfConf for conference organisers), but I can wholeheartedly recommend DevRelSummit for people who already work in this field and those who want to.

The line-up and presentations were full of people who know their job and shared real information from the trenches instead of advertising products to help you. This is a very common worry when a new field in our job market gains traction. Anyone who runs events or outreach programs drowns in daily offers of “the turn-key solution to devrel success” or similar snake oil.

In short, the presentations were:

  • Bear Douglas of Slack (formerly Twitter and Facebook) sharing wins and fails of developer outreach
  • Charles Morris of Microsoft showing how he scaled from 3 people on the Edge team to a whole group, aligning engineering and outreach
  • Kyle Paul showing how to grow a community in spaces that are not technical cool spots and how to measure DevFest success
  • AJ Glasser of Unity explaining how to deal with and harvest feedback you get showing some traps to avoid
  • Damon Hernandez of Samsung talking about building community around hackathons
  • Linda Xie of Sourcegraph showing the product and growth cycle of a new software product
  • Robert Nyman of Google showing how he got into DevRel and what can be done to stay safe and sound on the road
  • Angel Banks and Beth Laing sharing the road to and the way to deliver an inclusive conference with their “We Rise” event as the example
  • Jessica Tremblay and Sam Richard showing how IBM scaled their developer community

In between the presentations there were breakout discussions, lightning talks and general space and time to network and share information.

As expected, the huge topics of the event were increasing diversity, running events smoothly, scaling developer outreach and measuring devrel success. Also, as expected, there were dozens of ways and ideas how to do these things with consensus and agreeable discourse.

All in all, DevRelSummit was a very well executed event and a superb networking opportunity without any commercial overhead. There was a significant lack of grandstanding and it was exciting to have a clear and open information exchange amongst people who should be in competition but know that when it comes to building communities, this is not helpful. There is a finite amount of people we want to reach doing Developer Relations. There is no point in trying to subdivide this group even further.

I want to thank everyone involved about the flawless execution and the willingness to share. Having a invite-only slack group with pre-set channels for each talk and session was incredibly helpful and means the conversations are going on right now.

Slack Channel of the event

DevRelSummit showed that when you get a dedicated group of people together who know their jobs and are willing to share that you can get an event to be highly educational without any of the drama that plights other events. We have a lot of problems to solve and many of them are very human issues. A common consensus of the event was that we have to deal with humans and relate to them. Numbers and products are good and useful, but not burning out or burning bridges even with the best of intentions are even more important.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Taking a break – and so should you

TL;DR: I am going on holiday for a week and don’t take any computer with me. When I’m back I will cut down on my travels, social media and conference participation and focus more on coaching others, writing and developing with a real production focus.

Sleeping dog
Larry shows how it is done

You won’t hear much from me in the next week or so as I am taking a well-deserved vacation. I’m off to take my partner to the Cayman Islands to visit friends who have a house with a spare room as hotels started to feel like work for me. I’m also making the conscious decision to not take any computer with me as I will be tempted to do work whilst I am there. Which would be silly.

Having just been in a lot of meetings with other DevRel people and a great event about it I found a pattern: we all have no idea how to measure our success and feel oddly unsatisfied if not worried about this. And we are all worried about keeping up to do date in a daily changing market.

I’m doing OK on both of these, but I also suffer from the same worries. Furthermore, I am disturbed about the gap between what we talk about at events and workshops and what gets released in the market afterwards.

The huge gap between publication and application

We have all the information what not to do to create engaging, fast and reliable solutions. We have all the information how to even automate some of these to not disrupt fast development processes. And yet I feel a massive lack of longevity or maintainability in all the products I see and use. I even see a really disturbing re-emergence of “this only needs to work on browser $x and platform $y” thinking. As if the last decade hadn’t happened. Business decisions dictate what goes into production, less so what we get excited about.

Even more worrying is security. We use a lot of third party code, give it full access to machines and fail to keep it up-to-date. We also happily use new and untested code in production even when the original developers state categorically that it shouldn’t be used in that manner.

When it comes to following the tech news I see us tumbling in loops. Where in the past there was a monthly cadence of interesting things to come out, more readily available publication channels and a “stream of news” mentality makes it a full-time job just to keep up with what’s happening.

Many thoughtpieces show up in several newsletters and get repurposed even if the original authors admitted in commentary that they were wrong. A lot is about being new and fast, not about being right.

There is also a weird premature productisation happening. When JavaScript, Browsers and the web weren’t as ubiquitous as they are now, we showed and explained coding tricks and workarounds in blog posts. Now we find a solution, wrap it in a package or a library and release it for people to use. This is a natural progression in any software, but I miss the re-use and mulling around of the original thought. And I am also pretty sure that the usage numbers and stars on GitHub are pretty inflated.

My new (old) work modus

Instead of speaking at a high amount of conferences, I will be much pickier with where I go. My time is more limited now, and I want to use my talents to have a more direct impact. This is due to a few reasons:

  • I want to be able to measure more directly what I do – it is a good feeling to be told that you were inspiring and great. But it fails to stay a good feeling when you don’t directly see something coming out of it. That’s why instead of going from event to event I will spend more time developing tools and working directly with people who build products.
  • I joined a new team that is much more data driven – our job is to ensure people can build great apps and help them by fixing our platform and help them apply best practices instead of just hearing about them. This is exciting – I will be able to see just how applicable what we talk about really is and collect data of its impact. Just like any good trainer should ensure that the course attendees really learned what you talked about this is a full feedback loop for cool technologies like ServiceWorker and Push Nofifications.
  • We just hired a truckload of talented people to coach – and I do want to see other people on stage than the usual suspects. It is great to see people grow with help you can give.
  • I just had a cancer growth removed from my face – it was benign but it is kind of a wake-up call to take more care about myself and have my body looked after better on an ongoing basis
  • I am moving to Berlin to exclusively live there with my partner and our dog – I’ve lived out of suitcases for years now and while this is great it is fun to have a proper home with people you care about to look after. I will very much miss London, but I am done with the politics there and I don’t want to maintain two places any longer.
  • I will spend more time coding – I am taking over some of the work on PWAbuilder and other helper tools and try them out directly with partners. Working in the open is great, but there is a huge difference between what Twitter wants and what people really need
  • I will write more – both articles and blog posts. I will also have a massive stab at refreshing the Developer Evangelism Handbook
  • I will work more with my employer and its partners – there is a huge group of gifted, but very busy developers out there that would love to use more state-of-the-art technology but have no time to try it out or to go to conferences.

Anke, Larry and Chris
Greetings from Berlin

What this means for events and meetups


  • I will attend less – instead I will connect conferences and meetups with other people who are not as in demand but great at what they do. I am also helping and mentoring people inside and outside the company to be invited instead of me. A lot of times a recommendation is all that is needed. And a helping hand in getting over the fear of “not being good enough”.
  • I will stay shorter – I want to still give keynotes and will consider more workshops. But I won’t be booking conferences back-to-back and will not take part in a lot of the social activities. Unless my partner is also coming along. Even better when the dog is allowed, too.
  • I am offering to help others – to review their work to get picked and help conference organisers to pick new, more diverse, talent.

I have a lot of friends who do events and I will keep supporting those I know have their full heart in them. I will also try to be supportive for others that need a boost for their new event. But I think it is a good time to help others step up. As my colleague Charles Morris just said at DevRelConf, “not all conferences need a Chris Heilmann”. It is easy to get overly excited about the demand you create. But it is as important to not let it take over your life.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

How can we make more people watch conference videos?

It is incredible how far we’ve come in the coverage of events. In the past, I recorded my own talks as audio as not many conferences offered video recordings (and wrote about this as a good idea in the developer evangelism handbook). These days I find myself having not having to do this as most conferences and even meetups record talks. Faster upload speeds and simple, free hosting on YouTube and others made that possible.

And yet it is expensive and a lot of work to record and publish videos of your conference. And if you don’t make any money with them it is a bit of advertising for your event with a lot of overhead. That’s why it is a shame to see just how low the viewing numbers of some great conference videos are. When talking to conference organisers, I heard some astonishingly low numbers. The only thing to boost them seems to be to deliver them one after the other with dedicated social media promotion. Which, again, is a lot of extra effort.

In order to see what would make people watch more conference talks, I took a quick Twitter poll:

Here are the quick results of 344 votes:

  • 29% chose shorter videos without Q&A
  • 37% would like transcripts with timestamps
  • 22% would like to have videos offline
  • 12% wanted captions.

I love watching conference talk videos. I watch them offline, on an iPod in the gym or on planes and trains. Basically when I am not able to do anything else, they are a great way to spend your time and learn something. There are a few things to consider to make this worth my while though:

  • The talk needs to make sense to watch on a small screen. Lots of live code in a terminal with a 12px font isn’t. That is not to say these aren’t good talks. They are just not working as a video.
  • The talk needs to be available offline (I use YouTube DL to download YouTube videos, some publishers on Vimeo offer downloads, Channel 9 always has the videos to download)
  • The talk needs to be contained in itself – it is frustrating to hear references to things I should know or bits that happened at the same event I wasn’t part of. It is even more annoying to see a Q&A session where you wait for the mic to arrive for ages or the presenter answering without me knowing what the question is.

I’ve written about the Q&A part of videos in detail before and I strongly believe that cutting a standard Q&A will result in more viewers and happier presenters. For starters, the videos will be shorter and it feels like less of an effort to watch the talk when it is 25 minutes instead of 45-50.

At technical events I am OK with some of these annoyances. After all, it is more important to entertain the audience at the event. And it is amazing when presenters take the time and effort to see other talks and reference them. However, there is a lot of benefit to consider the quality and consumption of a recording, too.

Having recordings of conference talks is an amazing gift to the community. People who can’t afford to go to events or even can’t afford to travel can still stay up-to-date and learn about topics to deep dive into by watching videos. Easy to consume, short and to the point videos can be a great way to increase the diversity of our market.

“You are here to talk to the online audience”

When I spoke at some TEDx events, this was the advice of the speaking coaches and organisers. TED is a known brand to have high quality online content. And it is almost unaffordable to go to the main TED events. Which makes this advice kind of odd, but their success online shows that there are on to something.

TED talks are much shorter than the average conference talk. They are more performance than presentation. And they come with transcripts and are downloadable.

Now, we can’t have only these kind of talks at events. But maybe it is a good plan to do some editing on the recordings and turn them into more of an experience than a record of what happened on stage that gets delivered as soon as possible. This means extra work and is some overhead, for sure. But I wonder how much of it could be automated already.

In addition to the poll results there were some other good points in the comments on Twitter and Facebook.

Less of the speaker upper body and more of the slides. Or slides to download. Also, speakers who pace themselves to sound good at 1.5x speed.

It seems to be pretty common by people who spend time watching talks to speed them up. This is an interesting concept. Good editing between slides and presenter was a wish a lot of people had. It shouldn’t be hard to publish the slides along with the video, and something presenters should consider doing more.

Not on the list but “editing” plus a solid couple of paragraphs of what the talk covers and why I should or shouldn’t watch it.

This is another easy thing for presenters to do. We’re always asked to offer a description and title of the talk that should zing and get people excited. Providing a second one that is more descriptive to use with the video isn’t that much overhead.

For English spokers, most of the conferences, no problem. But for non English spokers, massive failure. Reading is really more easy trying to listen and understand. Some guys speaks really fast. So I can’t understand talks.

This is a common problem and a presenter skill to work on. Being understandable by non-native speakers is a huge opportunity. So, some pacing and avoiding slang references are always a good idea.

The possibility to download the videos on tablets, smartphones and laptops so I can see them during commuting time

Offering videos to download should be not too hard. If you’re not planning to sell them anyways, why not?

Also offline availabilty with chapter marks/timestamps. I’ll vote for transcripts for skim reading to get to the gold nuggets. But sometimes a good speaker is an enjoyable 50min experience. I’d rather read transcripts. I never get blocks of quiet. Links to slides to follow along, or (even better) closed captions so I can play them muted If they were shorter and had a PowerPoint with main points to download after

This, of course, is the big one. A lot of people asked for transcripts, chapters and time stamps. Either for accessibility reasons or just because it is easier to skim and jump to what is important to you. This costs time and effort.

And here we have a Catch-22: if not many people watch the recordings of an event, conference organisers and companies don’t want to spend that time and effort. Manual transcription, editing and captioning isn’t cheap.

The good news is that automated transcription has gone leaps and bounds in the last years. With the need to have voice commands on mobiles and home appliances a lot of companies concentrated on getting this much better than it used to be.

YouTube has automated captions with editing functionality for free. Most cloud providers offer video insights.

One service that blew me away is VideoIndexer.

Video Indexer Interface

(Yes, this is by the company I work for, but it came as a surprise to me that this offer brings together many machine learning APIs in a simple interface.)

Using VideoIndexer, you not only generate an editable time-stamped transcript, but you also get emotion recognition, image to text conversion of video content, speaker recognition and keyword extraction. That way you to offer an interface that allows people to jump where they want to without having to scrub through the video. I’d love to see more offers like these and I am sure there are quite a few out there already in use by big TV companies and sports broadcasters.


All in all I am grateful to have the opportunity to watch talks of events I couldn’t be at and I’m making an effort to be a better online citizen by providing better descriptions and be more aware of how what I am saying can be consumed as a video afterwards.

My favourite quote in the comments was from Tessa Mero:

Would be fun watching it with someone so we can discuss the content during/after the video. Need social engagement to make learning more fun.

Videos of talks are a great opportunity to learn something and have fun with your colleagues in the office. Pick a room, set up a machine connected to the beamer, get some snacks in, watch the talk and discuss how it applies to your work afterwards. Conference organisers spend a lot of effort to record talks, presenters put a lot in to make the talk exciting and educational. And you can benefit from all of that for free.

Also published on Medium

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Debugging JavaScript – console.loggerheads?

The last two days I ran a poll on Twitter asking people what they use to debug JavaScript.

  • console.log() which means you debug in your editor and add and remove debugging steps there
  • watches which means you instruct the (browser) developer tools to log automatically when changes happen
  • debugger; which means you debug in your editor but jump into the (browser) developer tools
  • breakpoints which means you debug in your (browser) developer tools

The reason was that having worked with editors and developer tools in browsers, I was curious how much either are used. I also wanted to challenge my own impression of being a terrible developer for not using the great tools we have to the fullest. Frankly, I feel overwhelmed with the offerings and choices we have and I felt that I am pretty much set in my ways of developing.

Developer tools for the web have been going leaps and bounds in the last years and a lot of effort of browser makers goes into them. They are seen as a sign of how important the browser is. The overall impression is that when you get the inner circle of technically savvy people excited about your product, the others will follow. Furthermore, making it easier to build for your browser and giving developers insights as to what is going on should lead to better products running in your browser.

I love the offerings we have in browser developer tools these days, but I don’t quite find myself using all the functionality. Turns out, I am not alone:

The results of 3970 votes in my survey where overwhelmingly in favour of console.log() as a debugging mechanism.

Twitter poll
Poll results: 67% console, 2% watches, 15% debugger and 16% breakpoints.

Both the Twitter poll and its correlating Facebook post had some interesting reactions.

  • As with any too simple poll about programming, a lot of them argued with the questioning and rightfully pointed out that people use a combination of all of them.
  • There was also a lot of questioning why alert() wasn’t an option as this is even easier than console().
  • There was quite some confusion about debugger; – seems it isn’t that common
  • There was only a small amount of trolling – thanks.
  • There was also quite a few mentions of how tests and test driven development makes debugging unimportant.

There is no doubt that TDD and tests make for less surprises and are good development practice, but this wasn’t quite the question here. I also happily discard the numerous mentions of “I don’t make mistakes”. I was pretty happy to have had only one mention of document.write() although you do still see it a lot in JavaScript introduction courses.

What this shows me is a few things I’ve encountered myself doing:

  • Developers who’ve been developing in a browser world have largely been conditioned to use simple editors, not IDEs. We’ve been conditioned to use a simple alert() or console.log() in our code to find out that something went wrong. In a lot of cases, this is “good enough”
  • With browser developer tools becoming more sophisticated, we use breakpoints and step-by-step debugging when there are more baffling things to figure out. After all, console.log() doesn’t scale when you need to track various changes. It is, however, not our first go-to. This is still adding something in our code, rather than moving away from the editor to the debugger
  • I sincerely hope that most of the demands for alert() were in a joking fashion. Alert had its merits, as it halted the execution of JavaScript in a browser. But all it gives you is a string and a display of [object object] is not the most helpful.

Why aren’t we using breakpoint debugging?

There should not be any question that breakpoint debugging in vastly superior to simply writing values into the console from our code:

  • You get proper inspection of the whole state and environment instead of one value
  • You get all the other insights proper debuggers give you like memory consumption, performance and so on
  • It is a cleaner way of development. All that goes in your code is what is needed for execution. You don’t mix debugging and functionality. A stray console.log() can give out information that could be used as an attack vector. A forgotten alert() is a terrible experience for our end users. A forgotten “debugger;” or breakpoint is a lot less likely to happen as it does pause execution of our code. I also remember that in the past, console.log() in loops had quite a performance impact of our code.

Developers who are used to an IDE to create their work are much more likely to know their way around breakpoint debugging and use it instead of extra code. I’ve been encountering a lot of people in my job that would never touch a console.log() or an alert() since I started working in Microsoft. As one response of the poll rightfully pointed out it is simpler:

So, why do we then keep using console logging in our code rather than the much more superior way of debugging code that our browser tooling gives us?

I think it boils down to a few things:

  • Convenience and conditioning – we’ve been doing this for years, and it is easy. We don’t need to change and we feel familiar with this kind of back and forth between editor and browser
  • Staying in one context – we write our code in our editors, and we spent a lot of time customising and understanding that one. We don’t want to spend the same amount of work on learning debuggers when logging is good enough
  • Inconvenience of differences in implementation – whilst most debuggers work the same there are differences in their interfaces. It feels taxing to start finding your way around these.
  • Simplicity and low barrier of entry – the web became the big success it is by being independent of platform and development environment. It is simple to show a person how to use a text editor and debug by putting console.log() statements in your JavaScript. We don’t want to overwhelm new developers by overloading them with debugger information or tell them that they need a certain debugging environment to start developing for the web.

The latter is the big one that stops people embracing the concept of more sophisticated debugging workflows. Developers who are used to start with IDEs are much more used to breakpoint debugging. The reason is that it is built into their development tools rather than requiring a switch of context. The downsides of IDEs is that they have a high barrier to entry. They are much more complex tools than text editors, many are expensive and above all they are huge. It is not fun to download a few Gigabyte for each update and frankly for some developers it is not even possible.

How I started embracing breakpoint debugging

One thing that made it much easier for me to embrace breakpoint debugging is switching to Visual Studio Code as my main editor. It is still a light-weight editor and not a full IDE (Visual Studio, Android Studio and XCode are also on my machine, but I dread using them as my main development tool) but it has in-built breakpoint debugging. That way I have the convenience of staying in my editor and I get the insights right where I code.

For a node.js environment, you can see this in action in this video:

Are hackable editors, linters and headless browsers the answer?

I get the feeling that this is the future and it is great that we have tools like Electron that allow us to write light-weight, hackable and extensible editors in TypeScript or just plain JavaScript. Whilst in the past the editor you use was black arts for web developers we can now actively take part in adding features to them.

I’m even more a fan of linters in editors. I like that Word tells me I wrote terrible grammar by showing me squiggly green or red underlines. I like that an editor flags up problems with your code whilst you code it. It seems a better way to teach than having people make mistakes, load the results in a browser and then see what went wrong in the browser tools. It is true that it is a good way to get accustomed to using those and – let’s be honest – our work is much more debugging than coding. But by teaching new developers about environments that tell them things are wrong before they even save them we might turn this ratio around.

I’m looking forward to more movement in the editor space and I love that we are able to run code in a browser and get results back without having to switch the user context to that browser. There’s a lot of good things happening and I want to embrace them more.

We build more complex products these days – for good or for worse. It may be time to reconsider our development practices and – more importantly – how we condition newcomers when we tell them to work like we learned it.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Any web site can become a PWA – but we need to do better

Over on his blog, I just go a ding from Jeremy.

Literally any website can—and should—be a progressive web app. Don’t let anyone tell you otherwise. I was at an event last year where I heard Chris Heilmann say that you shouldn’t make your blog into a progressive web app. I couldn’t believe what I was hearing. He repeats that message in this video chat: “When somebody, for example, turns their blog into a PWA, I don’t see the point. I don’t want to have that icon on my homepage. This doesn’t make any sense to me” Excuse me!? Just because you don’t want to have someone’s icon on your home screen, that person shouldn’t be using state-of-the-art technologies!? Excuse my French, but Fuck. That. Shit!
Our imaginations have become so limited by what native mobile apps currently do that we can’t see past merely imitating the status quo like a sad cargo cult.
I don’t want the web to equal native; I want the web to surpass it. I, for one, would prefer a reality where my home screen isn’t filled with the icons of startups and companies that have fulfilled the criteria of the gatekeepers. But a home screen filled with the faces of people who didn’t have to ask anyone’s permission to publish? That’s what I want!

Suffice to say, I am not telling anyone not to use great, modern technologies to the benefit of their end users and their own publishing convenience. And the stack that make up PWA are great to make either more successful than it is now.

PWA presentation at JSPoland
Me, literally telling the world that a PWA can be anything

I want us to do more. I want modern web technologies not to be a personal thing to use. I want it to be what we do at work, not to bring to work or point to at some amazing web person’s web presence or a showcase of a large web company.

All power to us for using whatever great technology in the environment we control, but we need to aim higher. We need to go where mistakes happen and bring the convenience and sensible upgrades to hacky old solutions. I don’t have the power to tell anyone not to use something on their blog. But I also don’t want to have a lot of things out there touted as “PWAs” that are a terrible experience. We’ve done that over and over with all kind of packaging formats. We need to get it right this time as our tools have never been better.

I publicly spoke out over and over again against stores in the current form as they are a barrier to access. A barrier that seems artificial, when we have the web, right?

Maybe. Fact is that a whole new generation of people know apps. Not the web. They know the web as something riddled with ads and malware you need blockers for. In some places where the web is not as conveniently available as it is where we are people even consider Facebook the web. As it is made available to people easier than the bloated web.

When I say that I don’t see the point of turning a blog into a PWA it hits exactly the confusion point of the “app” part. To me, an app is a “do” thing, not a “read” thing. I see no point in having the Wired, the Guardian, The Rolling Stone, The Times etc… app. Icons on a crammed desktop don’t scale. I use a news reader to read news items. I use an RSS aggregator to read blogs. I use an ebook reader to read books (or a browser). I use Spotify or iTunes to listen to music. I don’t have an app for each band or movie.

I’ve been publishing for donkey’s years on the web. And I choose to use a blog as I have no idea how you consume it. And I like that. I don’t think there should be a “Chris Heilmann” icon on your desktop. It should be in the contacts, it should maybe show up as a post or a bookmark. You can’t do anything on this blog except for reading it. Use what makes you most happy to do that.

I very much agree with Jeremy:

I don’t want the web to equal native; I want the web to surpass it.

And that’s exactly what I mean when I don’t want a blog as an app – no matter what format of app. I want people to create PWAs that are more than bookmarks – even offline working ones that give me a notification when new content is available.

Does this mean I say that you shouldn’t use a manifest and service worker to improve web pages or your blog? Hell, no. Go wild – do the right thing. Especially do the one thing that PWAs require: stop publishing over HTTP and secure your servers. Man in the middle attacks need to stop, especially with various governments happily being that man in the middle.

I want the web to succeed where it matters. I want native apps to go away. I don’t want to download an app to get tickets to the subway in Berlin. I don’t want an app for each airport I go to. I very much don’t want an app for each event I attend. I don’t want an app for each restaurant I frequent. I don’t need those relationships and having to give them a part of the limited space on my phone. Or on my desktop/launch bar.

We need the web to beat native where it is terrible: distribution and convenience. I want people to do things without having to go to a store, download and install an app and run it. I want people to get access to free content without a credit card. You need a credit card to access free stuff on app stores – this is a huge barrier. I want people to find the next train, book restaurants, get a doctor and find things regardless of connection and device. I want people to take pictures and sharing them. I don’t want people to use insecure, outdated versions of their apps as it is too much to get 50MB updates every day. I don’t want people to use what comes on the phone and use the browser as the last resort. And for this, we need great PWAs of known entities and great new players.

Try before you buy
PWA is try before you buy

I want people to understand that they are in control. As I said last week in Poland, PWA is proper try before you buy. You go to a URL, you like what you see. With later visits you promote it to get more access, work offline and even give you notifications.

A PWA has to earn that right. And this is where we need kick-ass examples. I have no native Twitter any more, Twitter Lite does the trick and saves me a lot of data and space. I go around showing this to people and I see them kick out native Twitter. That’s what we need.

Every time we promote the web as the cool thing it is we repeat the same points.

  • It is easy to publish
  • it is available for everyone
  • it is not beholden to anyone
  • It is independent of platform, form factor and generally inviting.

When you see the web that millions of people use every day the story is very different.

It is that bad that every browser maker has a department of cross-browser compliance. We all approach big companies pointing out how their products break and what can be done to fix them. We even offer developer resources to not rely on that webkit prefix. In almost all cases we get asked what the business benefit of that is.

Sure, we have a lot of small victories, but it is grim to show someone the web these days. In our bubble, things are great and amazing.

How did that happen? We have the technology. We have the knowledge. We have the information out there in hundreds of talks, books and posts. Who do we reach is the question. Who builds this horrible web? Or who builds great stuff at home and gets mostly frustrated at work because things are beyond repair?

When I say that I don’t want a blog as an app I am not saying that you shouldn’t supercharge your blog. I am not forbidding anyone to publish and use technology.

But, I don’t think that is enough. We need commercial successes. We need to beat the marketing of native apps. We need to debunk myths of native convenience by building better, web based, solutions.

We’ve proven the web works well for self-publishing. Now we need to go where people build an iOS and Android app to have an online presence for their company with higher functionality. We need these people to understand that the web is a great way to publish and get users that do things with your product. We think this is common sense, but it isn’t. We have to remind people again about how great the web is. And how much easier it is using web technology.

For this, we need first and foremost find out how to make money on the web on a huge scale. We need to find a way that people pay for content instead of publishers showing a lot of ads as the simpler way. We need to show numbers and successes of commercial, existing products. Google is spending a lot of money on that with PWA roadshows. Every big web company does. I also all work directly with partners to fix their web products across browsers and turn them into PWAs. And there are some great first case studies available. We need more of those.

I want developers not to have to use their spare time and learn new web technologies on their personal projects. I want companies to understand the value of PWA and – most importantly – fix the broken nonsense they have on the web and keep in maintenance mode.

If you think these and other PWA case studies are by chance and because people involved just love the web – think again. A lot of effort goes into convincing companies to do the “very obvious” thing. A lot of cost of time and money is involved. A lot of internal developers put their career on the line to tell their superiors that there is another way instead of delivering what’s wanted. We want this to work, and we need to remind people that quality means effort. Not adding a manifest and a service worker to an existing product that has been in maintenance hell for years.

Jeremy wants a certain world:

I, for one, would prefer a reality where my home screen isn’t filled with the icons of startups and companies that have fulfilled the criteria of the gatekeepers. But a home screen filled with the faces of people who didn’t have to ask anyone’s permission to publish? That’s what I want!

I want more. I want the commercial world and the marketing hype of “online” not to be about native apps and closed stores. I don’t want people to think it is OK to demand an iPhone to access their content. I don’t want companies to waste money trying to show up in an app store when they could easily be found on the web. I think we already have the world Jeremy describes. And – to repeat – I don’t want anyone not to embrace this if they want to or they think it is a good idea.

Nothing necessary to turn your current web product into a PWA is a waste. All steps are beneficial to the health and quality of your product. That is the great part. But it does mean certain quality goals should be met to avoid users with an “app” expectation not getting what they want. We have to discuss these quality goals and right now quite a few companies roll out their ideas. This doesn’t mean we censor the web or lock out people (there are other people working on that outside of companies). It means we don’t want another “HTML5 Apps are a bad experience” on our hands.

I’ve been running this blog for ages. I learned a lot. That’s great. But I don’t want the web to be a thing for people already believing in it. I want everyone to use it instead of silos like app stores – especially commercial companies. We’ve been shirking away from the responsibility of making the enterprise and products people use day to day embrace the web for too long. The current demise of the native/app store model is a great opportunity to do this. I want everyone with the interest and knowledge to be part of this.

I can’t see myself ever having a phone full with the faces of people. This is what the address book is for. The same way my ebook reader (which is my browser) is what I use to read books. I don’t have an app for each author.

I like the concept of having a feed reader to check in bulk what people that inspire me are up to. I like reading aggregators that do the searching for me. And if I want to talk to the people behind those publications I contact them and talk to them. Or – even better – meet them.

An app – to me – is a thing I do something with. This blog is an app for me, but not for others. You can’t edit. I even turned off comments as I spent more time moderating than answering. That’s why it isn’t a PWA. I could turn it into one, but then I would feel that I should publish a lot more once you promoted me to be on your home screen.

So when I talk about personal blogs not being PWAs to me, this is what I mean. Apps to me are things to do things with. If I can’t do anything with it except for reading and sharing I don’t stop you from publishing it as a PWA. But I am not likely to install it. The same way I don’t download the Kim Kardashian app or apps of bands.

This is not about your right to publish. It is about earning the space in the limited environment that is our user’s home screens, docks and desktops. If you’re happy to have that full of friend’s blogs or people you like – great. I’d rather soon see phones in shops that out-of-the-box come with PWAs for people to do things. Not native apps that need a 200MB update the first time you connect and won’t get that upgrade and become a security risk. I want web access to be front and centre on new devices. And to do that, we need to aim higher and do better.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

CSS vs. JavaScript: Trust vs. Control

When GotoConf Amsterdam asked me to speak, I thought it’d be another machine learning or Progressive Web Apps talk. Instead the organisers asked me to cover CSS. An under-represented language in their “programming languages” track. Now, I’ve been a fan of CSS from the very beginning. I assumed that people in a hard-core development conference won’t be as excited. They’d have not looked at CSS in detail. Instead, my assumption was that it is more of a necessary annoyance to them. So I wrote a talk about what using CSS means and how we don’t use it to its strengths.

Here are the notes of my talk.

A boring fight

Captain America vs. Iron Man

The other day I watched “Captain America: Civil War “again. And once again it bored me and I didn’t quite get the concept of it. The idea of super heroes forced to be responsible for their collateral damage is not new. Asking for control over them is not new either. “The Incredibles” did a great job with that.

I was more bored about the premise of all these cool super heroes fighting against each other. We know their powers. We know that they are deep down friends who saved each other’s lives on countless occasions. We know that their powers match. There is no violence, no real drive, no anger in these encounters. It feels like Marvel introduced too many cool characters and now tries to find a way to let people take sides. Sell more toys, create artificial drama.

I get the same impression when we talk about using CSS or JavaScript for layout. Both have their merits, both have their powers. Both have fanbases ready to dig up the most detailed information to advocate for one over the other. But I find this boring. Both used together is what brought the web forward. And it is holding us back that there are two massive camps. One end sees CSS as a thing of the past and in our module driven world we should do all in a scripting space. The other sees CSS and its preprocessors and build scripts as more than enough to do everything. Remember DHTML days when we did everything with JavaScript? Remember the “CSS only solutions” backlash? When we (ab)used checkboxes for complex interactivity to avoid using any JavaScript?

Giana Blantin put it nicely:

Can these two groups:
“CSS is so easy, it isn’t even coding”
“CSS is so hard, we need to replace it with JS!”
please talk to each other?

A lot of the misconceptions of CSS is because developers don’t understand how it differs from programming. Instead, we fiddle with it and change things around. After breaking something, we conclude that it is not good enough and we need to replace it.

I know Open GL - I can do gradients

Often this is overshooting the mark. Much like using OpenGL for simple gradient creation we don’t need to bring out the big guns all the time. CSS has a few tricks up its sleeve that we can’t match with client-side scripting. And it has nothing to do with syntax or language features. It is about sharing responsibility.

Who is at fault and who should be tolerant?

CSS, much like HTML is fault tolerant. This can be confusing. What it means is that end users should not suffer from the mistakes of the developer. Products built with CSS still show up when the developer made a mistake. They don’t look perfect, but they work. When a CSS parser encounters a property it doesn’t understand – it skips it. When it encounters a value it can’t deal with or the property doesn’t support – it skips it. That way we stay backwards compatible.

A button that has a background colour and a gradient will show the colour on older environments. It also shows it in environments that don’t support gradients because of performance issues. Faster, more hi-fi and supporting environments will show a gradient.

You don’t need to know the environment and you don’t need to make that decision. The OS, the browser and the proxies involved make these decisions for you.

JavaScript is not fault tolerant. This can be disastrous. You are much more in control when using JavaScript. But you are also much more responsible.

JavaScript on the client can break for dozens of causes. The browser can be non-supportive, the connection can be flaky. The mobile provider your end users have may see it as their job to minify and pack scripts going down the wire. When JavaScript encounters something it doesn’t understand – it breaks. It packs in and doesn’t show anything, thus punishing the user of your product for your errors. Or those errors introduced by the other people and scripts involved delivering your code to the end users.

In other words:

  • CSS – You apply your styles and you hope it worked.
  • JavaScript – You control the styling and you can and should verify that it worked

CSS means embracing the “squishiness” of the web, as Brad Frost put it. The web isn’t a fixed canvas you can set pixels on. A lot of things on it are beyond your control:

  • The browsers of your users
  • The resolution, pixel density and colour settings of their devices
  • Their connection reliability and speed
  • Their connection restrictiveness – resource blocking is a thing
  • Their font size and zoom needs
  • The availability of resources on their machines for your product (is the CPU already burning?)
  • The amount of text content and image sizes in your product – CMS anyone?

This can be daunting and often we want to control the environment our products run in – if only to keep our sanity. This means though that we block out a lot of potential users.

In this unknown environment we have to decide who takes on the job to deal with its performance problems:

  • CSS – It is the job of the browser to perform well, use GPU resources and skip functionality.
  • JavaScript – It’s your job to test for support. And to ensure rendering, painting and reflow is fast. And to keep animation in sync.

CSS is damn good at that and browser makers put a lot of effort into tweaking the interface performance.

So why do we under-estimate CSS and over-value the benefits of JavaScript? I guess one thing to blame is a classic – Internet Explorer.

CSS and its bumpy history

CSS had to grow up fast and didn’t get the support from browsers that it needed to be a reliable tool.

CSS was very limited at first and meant as a replacement for visual HTML and attributes. Begone all those font, bgcolor, align, center, HR and friends. Patchy browser support and very odd errors without debugging options didn’t help it. We knew things were wrong but we couldn’t do anything about it. We even couldn’t ask anyone as browser makers weren’t available for feedback.

When the iPhone came out CSS had its day in the limelight. The “HTML5 is the future” story needed a lot of extra functionality. With Apple calling the shots there and standardisation taking too long a lot was “Webkit only”. T

his meant prefixes in CSS and once again forking for different rendering engines. Browser makers innovated and showed dominance over others with prefixed functionality. As developers this meant repetition and having to pick a support plan for each of them. And of course one to support older, outdated browsers. These new browser wars around prefixes caused a lot of arguments and confusion.

And last but not least there was until recently no layout model in CSS. Instead we hacked using positioning and floating. Positioning, especially absolute positioning in pixels isn’t sensible on the web. People can resize the font and contents will overlap. Positioning with floating needs clearing elements.

It is not what you call a reliable base line or one that was simple to understand if you’re not “web native”

We needed to make CSS work regardless of browser support

Our solution was to patch with JavaScript. We can read out conditions and react to them creating HTML and applying styling. As JavaScript is a programming language we have full control over what is happening. We have conditions, loops, comparisons – all the things a programmer misses in CSS. This, to a degree is a misunderstanding of CSS as a concept. A selector that matches several elements is – in essence – a loop. We can even use :nth-child() to target an element in a collection.

In general CSS has been going leaps and bounds since we had to use JavaScript to patch it. Especially disappointing browser support is a much smaller problem.

  • Evergreen browsers are a thing – all browsers are on a constant upgrade path. We even learn from browser makers what’s coming down the line.
  • Browser tooling gives detailed insights into what CSS applies to what. We even get visual tools like animation editors and colour pickers.
    Bezier editor in Firefox Devtools
    Firefox Developer tools have a visual editor for bezier animations
  • CSS support across browsers is well documented: caniuse.com is an incredible resource. It not only shows which browser and which environment supports what. It also explains bugs in the implementations, offers links to the specs and the bug reports. It even has an API to embed this information into documentation and developer tools.
    Can I use information in Visual Studio Code's editor footer
    Using the “Can I use” extension for Visual Studio Code you can display browser support information directly in your editor. You learn who you lock out while you code!
  • We have support channels and bug tracking for almost all browsers. Some even allow you to file a bug using Twitter. The teams of browser makers are active on social media and reachable.
  • Pre-processors like Sass and Less have turned up the heat to innovate the CSS spec faster. Much like jQuery inspired JavaScript of today, these lead to functionality people want.
  • The community spends a lot of time making CSS more maintainable. Approaches like Object Oriented CSS by Nicole Sullivan and Atomic Design by Brad Frost have been around for ages and should help reduce complexity.

What CSS can do for you

Here are some amazing things CSS can do now and you should consider using.

Calculated CSS values

One thing that always seemed to be missing in CSS was a way to calculate values. The classic example is an absolutely positioned element that is 100% wide but needs padding. In the olden days we needed to do that by nesting another element and apply the padding to that one. For quite some time though we could use CSS calc() for that and apply a width of calc(100% – 1em).

Calculations are very well supported across browsers. There shouldn’t be any qualms about using them.

Media Queries

CSS Media Queries allow you to react to changes of the viewport of the document. In essence they mean that you apply part of your style sheet when the viewport meets a certain criteria. This could be a viewport that is at least a certain width or at most a certain height. You can also check for portrait or landscape orientation of the screen or if the document is a printout.
CSS Media Queries also have a JavaScript equal in matchMedia. This allows you to load content on demand. One Media Queries problem is that browsers load images in blocks regardless of the match.

Generated content

Using the ::before and ::after pseudo selectors in CSS allows you to create content that is purely visual. This is a great way to make sure that things that are for cosmetic reasons don’t need an own, empty DIV, SPAN, B or I element. It is a way to keep everything visual maintained in the style sheet instead of scripts or the HTML document. You can pair this with drop shadows, gradients and other CSS features that create visuals.. An impressive showcase of that is “A Single DIV“. This web site shows dozens of visuals created from a single DIV element.

Sully of Monsters, inc. as a single DIV
This graphic is a single DIV created with generated content

Animations and transitions

Animations and transitions in CSS were the big breakthrough when the iPhone came out. Transitions allow you to create a smooth change from one state to another. You don’t need to know what changes should happen. All you tell the browser is how long to transition and what easing function to use. Animations give you more granular control. You define keyframes and what should animate how. Both Animations and transitions fire events before, during and after. This allows you to interact with JavaScript in a predictable manner. The benefit of using CSS for this is that the browser ensures the performance of the animation. This happens by running them on the GPU and throttling the frame rate should the need occur. This is an important step to ensuring a good battery life of your users’ phones. If you animate in JavaScript, this can easily go wrong.

Viewport Units

Media Queries make sense when you want to define experiences in detail. Instead, you can also use viewport units to size elements according to the available space. Viewport Width (vw) is a percentage of the full viewport width. So on a 480px wide screen 10vw is 10% or 48px. This differs from the % unit, which is the percentage of the parent element and not the viewport. Nested percentages will get smaller, vw will not. Viewport Height (vh) is a percentage of the full viewport height. You can also make yourself independent of orientation my using vmin and vmax. These either take the smaller or the larger of vw and vh. The only niggle in support of viewport units is that to date Edge doesn’t support vmin and vmax.

CSS Tricks has a great article on how powerful viewport units can be. From resolution independent embeds to viewport dependent typography you can use viewport units to create highly flexible interfaces.


Flexbox is a way to create layout of elements in CSS. In essence is it everything people who claimed layout tables were easier missed in CSS – and much more. You can align child elements of an element to be on the right, left, top or bottom. You can define them to fill up the available space, with each using either the same amount or more than the others. You can also define them to use the available space between each other or around each of them. It is as flexible as it says on the tin. If you want to have a visual editor to see what that means, Build With React has a great flexbox editor to play with.

Playing with the different settings of Flexbox

There is also a game called Flexbox Froggy. It teaches the concepts in an enjoyable and accessible manner and is great for kids to start with CSS.

Flexbox Froggie

A great talk about Flexbox is the one Zoe Gillenwater gave at various events. What I like most about the talk is how Zoe shows how they used Flexbox in production. The examples are from booking.com and show fallbacks for browsers that don’t support it.

CSS Grid

If Flexbox is the answer to layout elements in a row or a column, CSS Grid is taking it to the next level. Using it you can lay out elements in a defined grid in two dimensions, both rows and columns. Grid has been cooking for a while and now is finally supported across the board.

A simple grid example
A few settings turn a series of elements into a flexible grid

Grid can be daunting to look at as its flexibility means there are a lot of options to choose from. By far the simplest way to get started is Rachel Andrew’s “Grid by Example” resource. This one has copy+paste examples of grid layouts. Many of them come with fallbacks for unsupported browsers. Training videos explaining the ins and outs of them make it an amazing resource.

If you learn better with challenges, you can grasp CSS Grid by playing the CSS Grid Garden.

CSS Grid Garden
Learn to water carrots with CSS Grid Garden

There are some “must see” talks about CSS grids online. The first one is “CSS Grid Layout“, again by Rachel Andrew.

Jen Simmons is taking a different approach. In her “Real Art Direction on the Web” talk she shows how Grid’s versatility can help us to break out of our “box layout” thinking.

There is no problem with mixing and matching Grid and Flexbox. It can and should use Flexbox in its cells. Together, these tools allow you to create flexible layouts. Layouts that allow for variable content and change to fit the available space. Web layouts.

CSS Custom properties (variables)

One of the most demanded features of CSS that preprocessors like Sass and Less had for a long time is variables. Now we have CSS Custom Properties which are the thing that gets me most excited about CSS. You can define re-usable settings once in your document and apply them throughout. The most common use case for that is custom colours and sizes. But you can go further and define fonts and other typography. You can also use them to nest calculations in CSS. This wasn’t possible before. An amazing feature is that Custom Properties can also be set dynamically with JavaScript.

Example of reading and setting CSS Custom properties in JavaScript
How to read and write custom CSS properties with JavaScript – (excerpt from Lea Verou’s talk)

If you want to learn all about the amazing power of CSS Custom Properties there is a talk you shouldn’t miss. Lea Verou’s “CSS Variables: var(—subtitle)” is a treasure trove of information.

CSS Feature Queries

Another very welcome addition to CSS was Feature Queries. These work much like Media Queries. By using @supports you check if the current user agent supports a certain feature. You then define a block of CSS that only gets applied when there is feature support. This might feel odd as the fault tolerant nature of CSS should already take care of that. What it does though is give you much more granular control. It also allows you to define a fallback when there is no support for a certain feature using the “not” keyword.

CSS and JavaScript?

CSS and JavaScript working together is powerful and the right thing to do. As far as CSS has come, it still can’t do everything. There are scenarios where the very nature of CSS stands in contrast with what we want to achieve.

As Cristiano Rastelli explains in his “Let there be peace on CSS” talk, the cherished feature of “Separation of Concerns” doesn’t apply in a module world.

Separation of Concerns in a component world

When CSS became a thing we moved all the look and feel and behaviour out of HTML into CSS and JavaScript. We define either on a document or even project wide level. We celebrate the fact that CSS does inherit from parent elements. When we build components that can be consistenly re-used we don’t want that. We want them to carry their look, feel and behaviour without bleeding out either to adjacent ones or inherit from their parents.

CSS and JavaScript working together in a non-component world

When building document-based solutions there is no excuse not to dig into the power of CSS. You can and should use JavaScript to bring information CSS can’t read into CSS. It is prudent though to do so in the least intrusive way possible.

The hierarchy of making CSS and JS work with another in this scenariois the following:

  • Use CSS when you can – using the things you saw here
  • If you need to communicate with CSS, consider changing Custom Properties
  • If that’s not an option apply classes to parent elements using classList.
  • As a very last resort, you can alter the style directly

Example of getting the mouse position into your CSS
An excellent example showing how to read the mouse position in JavaScript and store it in CSS Custom Properties – (excerpt from Lea Verou’s talk)

Whenever you change styles dynamically, remember that you are working against the browser. Every style change has consequences in reflow, rendering and painting. Paul Lewis and Das Surma maintain a handy guide called CSSTriggers. This one describes in detail which CSS changes result in what punishment to the browser.

CSS Triggers
CSS Triggers gives you information of the effects of different style changes

In Summary

CSS is much more reliable than it used to be and there is not much left that should be different to what it is. The main thing to remember is that CSS isn’t meant to do the same things JavaScript does. Even layout languages don’t work the way CSS does and cover the same need. It has a pretty tough job to do and it does it well. When you use CSS, the browser helps you meet the needs of your end users regardless of their setup. This is a core principle of the web and defined in the W3C HTML Design Principles:

Users over authors over implementors over specifiers over theoretical purity

Our users deserve interfaces that are smooth, reliable and don’t kill their batteries. So, consider CSS a bit more. You can be lazy and build on the work of the community.

Inspiring and active CSS people to follow

When researching this talk I kept going back to resources written and maintained by fabulous people on the web. Here is a short list in no particular order of people you should follow if you want to be up to scratch with your CSS knowledge. I have to thank each of them. They’re making the web easier for all of us.

  • Ire Aderinokun (@ireaderinokun) writes a lot of easy to grasp and to the point CSS information bits on her blog, bitsofco.de.
  • Ana Tudor (@anatudor) is a developer who creates ridiculously complex and beautiful animations in CSS. Her Codepen is one of the most frequented ones and what she does to the CSS engines is a great help for browser makers to test their performance
  • Jen Simmons (@jensimmons) is a CSS layout and design expert working for Mozilla
  • Rachel Andrew (@rachelandrew) to me is the #1 CSS grids expert
  • Chris Coyier (@chriscoyier) is the founder of the amazing CSS resource CSS Tricks and the interactive development playground Codepen
  • Sarah Drasner (@sarah_edo) is an animation and design expert focused on building maintainable products
  • Zoe M. Gillenwater (@zomigi) is a lead developer using bleeding edge CSS in production
  • Brad Frost (@brad_frost) is the author of Atomic Design, a scalable way to use and re-use CSS in large projects
  • Rachel Nabors (@rachelnabors) is a comic artist and animation expert writing about web animations and merits of different technologies
  • Una Kravets (@una) is a developer specialising in CSS and its new features. She also is a podcaster and has her finger very much on the pulse of CSS and other visual technologies
  • Lea Verou (@leaverou) is the author of the excellent CSS secrets book, a researcher at MIT and invited expert by the CSS working group of the W3C. She is meticulous in her research and ruthless in her delivery of lots of great information in a short amount of time.
  • Sara Soueidan (@sarasoueidan) is a developer who is an expert on responsive designs and pragmatic approaches to using newest technologies.

I keep getting inspired by these people (amongs others) daily, and hope you will start to get the same experience.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)