Over on Jonathan Snook’s blog we have a pretty good debate about a controversial tweet by Tom Dale:

Can we agree that, in 2018, human-readable "View Source" is a constraint the web can discard? I benefitted from "View Source" too, but today we have an embarrassment of resources and open source examples I would have killed for as a kid.

— Tom Dale (@tomdale) February 19, 2018

In essence, Jonathan points out that whilst web development has become much more complex, that isn’t a reason to disregard a human readable source:

The increasing complexity of tools doesn’t negate the need for those earlier, simpler tools, though.

In other words, horses for courses. A simple web site doesn’t need complex tools and benefits from view-source. Other, more complex web products are not as interesting to look at as a simple HTML display.

Tom also points out that he doesn’t mean that you shouldn’t be able to peek under the hood of a site, but that a simple view-source isn’t the correct tool.

Just to clarify: I'm not suggesting removing the ability to inspect what's happening in a web app at runtime. I just mean that it's reasonable to have the assets served to the browser require some sort of post-processing to be understandable.

— Tom Dale (@tomdale) February 20, 2018

And you know what? I tend to agree. There is no doubt that view-source was what made the web great. It drove business owners crazy that all their code was readily visible and copy-able in the browser. For developers it was great, though. Almost all learned by looking at what other people do. And by copying and pasting. And this is where it breaks apart.

I want to emphasise this: it used to be great to hit cmd+u and look at a web site in “text mode”. It was even better when the “view-source:” pseudo protocol became a thing. Browsers added colour coding and later on Firefox even highlighted syntax errors in your markup as bold and red.

For a simple web site with everything in one document or a few linked scripts and stylesheets, that was enough.

I don’t think it is any longer though. Even navigating simple source code of a web site is much more fun in developer tools rather than a huge text block. We can right-click on an element these days and go directly to it. We see how the cascade works when looking at its CSS and we even can see attached events and hover states.

Sure, developer tools are harder to learn than looking at a document, but you also learn so much more from them. The beauty of view-source was that it came for free with a browser. This made it a tool of choice for anyone becoming a web developer. There was no need to download and learn an IDE - your development environment was the consumption environment.

Well, that’s exactly what developer tools are these days. They are free, they come with the browser, and they are not impossible to understand. If anything, I like the fact that they give you more insights into what the code does rather than what it is.

The big proponents of view-source tout its usefulness and simplicity. But we can also start thinking about the problems it has:

• Except for a few purist web sites out there, what you see in your current device isn’t the code of the web site. We shouldn’t ship the same code down the wire for a low-end mobile device than for a retina screen, fast connectivity device. View source is thus giving us a false impression.
• Code sent to the web is often minimised and bundled. Developer tools give you options to pretty-print those and thus make them much more understandable.
• Of course it is great that there is no barrier to entry if you want to know how something works. But the forgiving nature of HTML and CSS can also lead to problems. When we released Edge, we found that thousands of web sites defined a text encoding of utf8 instead of utf-8. We needed to fix this in the browser. Clearly people copied and pasted without thinking or validating. And that’s where unexplained code like in a view-source environment fails.

A lot of the fight for view-source stems from a nostalgic view of the internet and how people build for it. Our excitement of learning the web this way is still lingering and we don’t want the next generation to miss out.

But maybe it is time to move on and understand that by sticking to old methods we deprive new developers. When we started, view-source was all we had and resources about what these things mean were scarce. Even worse, they were tinted with corporate needs, rather than following a standard. You learned the Microsoft web from Microsoft, the Netscape web from Netscape and standards when you had the time or listened to those Opera freaks.

I wrote about this back in 2011 in my Lynx would not be impressed – on semantics and HTML post. And now, seven years later, I still think it should be up to the current generation of developers to choose what makes most sense for them. Our nostalgia might actually be hurting the cause.

Snook’s right: we have no right to dismiss or actively block view-source as a means to access code and learn from it. But I don’t think that in today’s development world this is enough and it makes so much more sense to delve deeper into the tool stack we have.

Just consider the amazing tools we have at our disposal for new developers to learn about web development rather than looking at other people’s code in the browser:

• The MDN Web Docs are an editable resource of everything web, maintained by all the browser makers and with help from many of the large web companies
• Can I Use gives you detailed information about what works in what browser, links to the standards and explains implementation quirks
• GitHub is the home of the source-code of many web projects with a whole history of commit messages and explanations how the code works and where and why people added hacks you shouldn’t copy
• JSBin , Codepen, Glitch and many other interactive development environments help you get started coding things without the pain of setting up all your preprocessors. Something that proponents of a simpler web always bring up as a huge barrier to entry to the web.
• Browser developer tools aren’t just “look at code” any more. They are fully fledged development environments that give you amazing insight into what’s going on and how things work. They even audit your code and tell you where things go wrong.

All in all I love view source and what it has done to the web. But I also think that in order to build great products these days we should find ways for newcomers to learn about becoming a developer. Not someone who copies and pastes. Learning about code editors, learning about version control, and learning where and how to ask for help are much more important skills.

I believe deeply that free, open source tooling and systems like GitHub and the abovementioned editors are a much better way to teach people to get started with the web than view-source is in 2018. We already live in a more complex world, and we have tools to make that easier.

This is the main topic of my Skillshare class about JavaScript and how to deal with the changes it went through. It is not only about JavaScript, but about the resources I talked about and what tools to use to make your live easier.

I wrote this to make myself more content and happy in this demanding world, and I hope it helps you, too. Old-school developers will find things to try out and new developers should get a sensible way to enter the JavaScript world. Beyond View-Source but without having to be a Webpack expert before you write your first line of HTML.

Back in March, the coding after work podcast interviewed me at the Techdays in Finland.

Today they released the podcast

In about 45 minutes I cover Progressive Web Apps, Microsoft and Open Source and the rise of AI as a technology for us to care about. Hope you enjoy it as much as I did recording it. Thank you to Jimmy and Jessica Engstrom for having me!

This is part of a series of posts about the life as a DevRel person and how not all is unicorns and roses. You can read the introduction and the other parts of the series here.

So, today, let’s talk about giving workshops.

Giving a workshop is very different to presenting and needs a different skillset. Whilst preparing a great talk already takes a lot of time, workshops are a different beast. As a rule of thumb, a good trainer spends eight hours research and preparation for each hour of a workshop.

Workshops are where you can’t fake anything. It is not enough to know the subject matter inside-out. You also need to deal with the attendees. Their requests, different speeds and knowledge levels. You need to lead the group and guide it. And you can’t do that if you don’t feel confident about the material or know much about the group you will teach.

Workshops are much less forgiving than presentations. Only a few people will complain about a bad presenter at a conference. It doesn’t feel like a waste of money to get the conference ticket when there was one dud. Workshops are much more expensive and more personal, that’s why criticism is harsher.

Conference organisers like having workshop days as they are much more profitable. Most of the ticket money of events needs to get into venue, catering, speaker fees and travel. Workshop ticket sales get shared with the teacher with a higher profit margin. Venues are often sponsored by companies. For freelance speakers this is great, as it means more money.

For a DevRel person it is trickier, as you represent a company and you have a different agenda. You need not to get people excited about your knowledge but also about the things you represent. That’s why it is also tougher to sell and fill a workshop as a DevRel person. Your workshops are seen as something that should be free and it is OK to put not as much effort in as an attendee. That doesn’t mean though that they are easier to create and run. At all.

With this increased pressure, it is tough to feel great about your workshops as a DevRel person. Your company will most likely want you to create a generic course. One that shows off the benefits of your products.

This makes sense, as it is an upfront investment of time and money. A lot of the products I worked with benefitted from workshops. You find gaps in the documentation, you see where people get lost, and what technical difficulties come up. All great opportunities to improve your product.

The great thing about generic courses is that they are reusable and measurable. The bad thing about them is that they make for disappointing workshops. You might as well have them online as a course with offline participation instead.

I feel a lot of worry about delivering workshops as they are important. Teaching is a tough job and a bad teacher can utterly mess up a subject. Remember school? All the topics taught by a great teacher are things I still love. All the topics run by a lackluster by-the-book teacher I had to re-learn later in life.

A workshop is much higher stress for you. Your passion, your excitement, your fearlessness to play make the course. It is uncommon to have “bad attendees” as they have a much bigger stake in the workshop than listening to a talk.

Your mistakes, your lack of passion, your sloppiness multiplies with the attendees. That’s why you need to be on your toes for the whole duration of the workshop.

The fun bit about teaching is to find out how people tick and what they need to understand something. It is not about telling them a lot of information and hope things stick. Humans keep information they found out on their own much more than those they had to memorise.

That’s why I want a workshop to be a real workshop. I want to know who will come, what their levels of knowledge are and have them set up their computers in advance. I might as well want X-Ray vision, as the sad fact is that often you need to face the following issues:

• People who hired you expect you to give a five hour presentation showing a lot of technical demos for people to maybe take part in
• You have no idea how many people and who will show up to your workshop
• You face a room full of 50 people – no way you can help them individually or even pair them up to help each other
• Half the people don’t come back after a break as their boss called them out to do “something important”
• A large part of the group didn’t bring a computer or didn’t expect having to do anything
• You end up being helpdesk for faulty computer configurations of the attendees’ computers
• You end up being offline when most of your materials need a connection or are a download to start with

To run a successful workshop you need to prepare for these. That’s why it is much more important to be clear and demanding in your communication. People who invite you to give a workshop often want a detailed outline of it. Make sure that this also contains detailed information about the needs you have. Setup of the room, the machines of the attendees, detailed timing and attendance demands. It may feel bad to be such a stickler for details, but anything you leave to interpretation will come back to haunt you and cost time. Time you can’t use to help attendees reach the goal of the workshop. Time you need to work with individuals whilst you lose the group.

Don’t be the bad teacher that messed up a subject for you. Workshops have detailed outcomes and you need to measure at the end of them if people learned something. This might be hard to swallow when it didn’t work, but it really helps being excited about your job when it does.

Presenting at conferences is a lot of work, but it kind of pales in comparison to organizing conferences. For years, conference organisers thanked me for making their lives easier by having all my presenter information in one place, a “presenter cheatsheet”.

Today I spend some time to convert this to a markdown document on GitHub, so you can fork it and change it to your needs.

I covered all the basics:

• Presenter information, bio and headshots
• What kind of presentations you want to cover
• What topics you can cover
• Show stoppers (when you will not present)
• Your deliveries
• Your setup
• Your expectations
• Money matters
• What when things go wrong.

So go to https://github.com/codepo8/presenter-terms and change what you need. Conference organisers will thank you.

JavaScript used to be easy. Misunderstood, but easy. All you had to do was take a text editor and add some code to an HTML document in a SCRIPT element to enhance it. After a few years of confusion, we standardised the DOM. JavaScript became more predictable. AJAX was the next hype and it wasn’t quite as defined as we’d like it to be. Then we had jQuery because the DOM was too convoluted. Then we got dozens of other libraries and frameworks to make things “easier”. When Node came to be we moved server side with JavaScript. And these days we replaced the DOM with a virtual one. JavaScript has types, classes and convenience methods.

JavaScript is everywhere and it is the hottest topic. This can be confusing and overwhelming for new and old developers. “JavaScript fatigue” is a common term for that and it can make us feel bad about our knowledge. Am I outdated? Am I too slow to keep up? Which one of the dozens of things JavaScript can do is my job? What if I don’t understand them or have no fun doing them?

It is easy to be the grumpy old developer that discards everything new and shiny as unreliable. And it is far too often that we keep talking about the good old days. I wanted to find a way to get excited about what’s happening. I see how happy new, unencumbered developers are playing with hot new tech. I remembered that I was like that.

That’s why I recorded a Skillshare class about JavaScript and how to deal with the changes it went through.

In about an hour of videos you learn what JavaScript is these days, how to deal with the hype and – more importantly – what great advances happened to the language and the ecosystem.

Here’s me explaining what we’ll cover:

The videos are the following. We deliberately kept them short. A huge benefit of this course is to discover your own best way of working whilst watching them. It is a “try things out while you watch” kind of scenario:

• Introduction (01:46) – introducing you to the course, explaining what we will cover and who it is for.
• JavaScript today (08:41) – JavaScript isn’t writing a few lines of code to make websites snazzier any longer. It became a huge platform for all kinds of development.
• Uses for JavaScript (06:25) – a more detailed view on what JavaScript does these days. And how the different uses come with different best practices and tooling.
• Finding JavaScript Zen (04:15) – how can you stay calm in this new JavaScript world where everything is “amazing”? How can you find out what makes sense to you and what is hype?
• Evolved Development Environments (10:22) – all you need to write JavaScript is a text editor and all to run it a browser. But that’s also limiting you more than you think.
• Benefits of Good Editors (12:34) – by using a good editor, people who know JavaScript can become much more effective. New users of JavaScript avoid making mistakes that aren’t helpful to their learning.
• Version Control (09:15) – using version control means you write understandable code. And it has never been easier to use Git.
• Debugging to Linting (06:01) – debugging has been the first thing to get right to make JavaScript a success. But why find out why something went wrong when you can avoid making the mistake?
• Keeping Current in JavaScript (05:11) – JavaScript moves fast and it can be tricky to keep up with that is happening. It can also be a real time-sink to fall for things that sound amazing but have no life-span.
• Finding the JavaScript Community (03:59) – it is great that you know how to write JavaScript. Becoming part of a community is a lot more rewarding though.
• Asking for Help (05:47) – gone are the days of writing posts explaining what your coding problem is. By using interactive tools you can give and get help much faster.
• Final Thoughts (01:11) – thanks for taking the course, how may we help you further?

I wrote this to make myself more content and happy in this demanding world, and I hope it helps you, too. Old-school developers will find things to try out and new developers should get a sensible way to enter the JavaScript world.