JavaScript is everywhere and it is the hottest thing to have on your CV. For now. Python is gaining and Deep Learning is to blame, but I digress. With JavaScript’s hype we also talk a lot about JavaScript fatigue. People feel overwhelmed by the sheer volume of things you can do with it. Or — even more to the point — the amount of work you have to put into setting up your JavaScript environment. And the tools you “need to use to be professional”.

I’m not suffering from JavaScript fatigue. The reason is that I didn’t come in that late. I was lucky enough to see JavaScript grow to what it is now. To me, JavaScript is still that cool rebel of the programming languages world. I remember being laughed at by Java and Perl developers for wasting my time on that toy language that didn’t even come with a package manager. I’m not a purist that says all these things are stupid or unnecessary. Far from it. It is amazing how far we have come in our tooling. But- maybe — we could achieve more with new developers starting out if we started them with Vanilla JavaScript rather than throwing the kitchen sink of tooling at them.

What people hate about JavaScript is the thing I love about it. It is a mess. It is not ready yet and there is still so much it can do.

I feel a kind of neoteny attachment to JavaScript.

neotenyniːˈɒt(ə)ni/noun – the retention of juvenile features in the adult animal

In other words, instead of showing people the current form of JavaScript as a matured, highly domesticated and fierce animal, we should get people to know it as a puppy. That’s how I got to know it. Instead of wondering what packages to install and how to set up my server to run it, I wanted to grab it, cuddle it, play with it and — above all — protect it and its surroundings from harm.

My relationship with JavaScript began very early. So early, that it didn’t do much and we couldn’t do much wrong. That didn’t stop us though from doing wild things. As a web developer, JavaScript itself wasn’t quite as interesting as what it can do in browsers. The years of document.write, framesets and popup windows came first. I had quite some “fun” trying to make things work across browsers. DHTML was the next hype where it was most important to create cool effects — no matter the cost. Considering standard compliance or what technical debt we accumulate was less exciting.

We all knew that JavaScript wasn’t a “real programming language” and that was what made it interesting. You didn’t need to use an IDE, you didn’t need to compile your code or set up an environment for it. You took any editor, wrote your code and the browser did the rest.
Until it didn’t any longer. Around the same time of the bursting of the first dotcom bubble IE stopped reigning supreme. Other browsers started to matter and clients complained about things breaking. JavaScript got less fashionable again. Instead, everybody started betting on Flash. It promised to eradicate cross-browser differences and give you full control.

In the JavaScript world, we sobered up a bit. We realised how brittle the things we built were and started to advocate for a more sensible use of JS. We also had a good reason, as the DOM finally got standardised and things were much more predictable than in the first browser wars.
In 2004, I wrote the self-training course on Unobtrusive JavaScript explaining how you can use JavaScript without relying on it. As an enhancement, it works wonders. As something to rely on, lots of things work against you.

When DOM-1 was available, I followed up with From DHTML to DOM Scripting with detailed advice to not make the same mistakes again.

Things got more solidified with the WASP DOM Scripting Task Force that started in a pub after a conference in London. The most visible influence there was probably Jeremy Keith’s DOM Scripting book.

JavaScript itself didn’t move much though. The language was still what Brendan Eich and others created in a 10 day sprint to have a client-side language. And when things get that frantic, shortcuts happen.

05 December, 1995: AP writes on Microsoft, Netscape, Java, and the forthcoming "JavaScript". pic.twitter.com/NCjh8MOgB3

— Sampson (@jonathansampson) July 25, 2018

Over the years, we tried to make the language itself better and more predictable. We couldn’t change it as that would break backwards compatibility. So we found clever ways to work around issues.

One of the big consumers of these were JavaScript and AJAX frameworks and libraries. YUI, Dojo, jQuery and others were a great test-bed to make JavaScript work for developers but also to fix some of the issues of the language itself.
The immediately-invoked function expression was a clever way to work around the global variables issue. Douglas Crockford’s Module pattern ensured encapsulation (until eval() also got a scope parameter). I’ve found the Module Pattern annoying to write, so I came up with the “Revealing Module Pattern” later on.

Many other patterns and best practices followed. Libraries like mootools and prototype made JavaScript a “proper” object oriented language. At the cost of overriding in-built objects which came back to haunt us now. Other attempts at “fixing” JavaScript were meta languages like Coffeescript and many forgotten ones.

Learning from these fixes and libraries the maintainers and creators of JavaScript, the TC39, release JavaScript much more often these days. And with ES5, we finally have a standard that deals with most issues the first editions had and gives us enough syntactic sugar to be effective.

JavaScript these days has matured a lot and will become even better. It can not, though, when we hide its inner workings away from the next generation of developers.
You don’t need to be a JavaScript language expert to use it. But it may be a good idea to tell the story how we got to where we are rather than asking people to blindly use what’s on offer right now. It is easy to get disappointed, discouraged and overwhelmed by something new when you use it without understanding it. You also don’t dare to say you don’t get it when your peers all stroke their chins pretending to know everything.

Let’s keep introducing JavaScript to people for what it is — a language that is pretty messy but highly accessible as there is no barrier to using it. Once they played a bit and see what it can or can not do, we can move on and show that a lot of what we did by hand these days is better served as a pre-built solution. But let’s keep people playing.

If you want to know more, and get a gentle introduction check out my 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.

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

When I worked for the Red Cross with elderly people one thing became pretty obvious to me. People who traveled in their lives were not only more interesting, but also aged much better. They had more energy, showed more excitement about new things and generally felt more alive.

Traveling as a DevRel person isn’t like that. It can easily be the exact opposite.

Coming from a low-end working class family traveling around the world always was a dream for me. Each holiday was cramming the family in a car and driving 14 hours to Italy to go camping. To the same place every year. And yet, I made the best of it. I loved going to highway stops seeing cars and trucks from all kind of countries. I deliberately chose to work on the web as it meant I can connect to people from all over. Getting to know them, finding out our differences and maybe – if I every get really lucky – visit them in real life.

From this point of view my job right now seems a dream come true. It seems that I get paid to travel the world. I have Gold status with one airline affiliate group for three years running. I have Silver and Gold status with a few hotel chains. My travel history is pretty impressive:

Here’s the thing though: travel for work is not at all like being on a holiday. It is taxing. It takes a toll on your health, it takes a heavy toll on your relationships and it is very easy to overdo it. You need to be happy with being on your own and being the only person to rely on. You also need to ensure that all your creature comforts get covered. This is often at odds with the budget of conferences or your company’s expense policies.

Faux Jet-Set

There is a strange disconnect in business travel. You are part of the jet set but you almost never have time to enjoy it. On paper it feels great to have travelled to all these cool destinations. In reality all you see is the airport, some means of transport, your hotel room and the event venues. This can be depressing. You constantly have this carrot of world traveler excitement in front of you. To experience it you would need to sacrifice free time. The days before and after an event are crucial for our jobs and it is hard to tack on a few in each direction.

A constant “do I deserve this” feeling

Lonely meals and nondescript rooms are much less fun when you didn’t hang out with people you know. And you don’t want to add yourself to other groups or ask people to dine with you as that would be work. And you need to ensure you have some time off to re-charge. Interestingly enough, the fancier the accommodation is the worse I feel. When I am in a really cool hotel and have no time to use the facilities other than crashing for a few hours I feel weird. I spend other people’s money without reaping the rewards. Trying the hotel out for a holiday later is not as common as they tend to be costly or optimised for business travel.

It is important to be on the road. A two minute face-to-face conversation is often worth weeks of emails, chats or calls. Meeting people where they are can open great opportunities for you and your company. So, here are a few tips that helped me on the way and still make it much easier for me.

Find an airline alliance to collect points and status with.

That means things that don’t sound much but will add a lot to your well-being.

• You do not have to worry about luggage restrictions.
• You get priority boarding, which means you can book a cheaper seat and still get on the plane first. You can store your hand luggage above instead of having to keep it at your feet.
• It is imperative that sooner or later you get lounge access. This turns a layover caused by a missed plane from a nightmare to an opportunity to get some work out of the way. Then you can sleep or relax on the plane.
• You are also more likely to get upgrades if you have status with an airline. Conferences or your company can book you an economy ticket and yet you travel in comfort.

All hotel loyalty systems are pants

Hotel loyalty systems only give you proper benefits when you book on their web sites or in their apps. With your own, personal credit card. If, like me, you have a corporate card, the most you get is a free bottle of water on check-in (yay?) and late check-outs. There is not much point to be loyal in this case. Something else is much more important when it comes to hotels.

Your hotel matters

Your hotel on a company trip can either be a place to crash at night or your base of operations. I try to make sure I can do the latter. That means the most important part is that it is close to where I need to be. You don’t want to spend a lot of time in transit between hotel and event, carrying a lot of swag and hardware with you. If that means you stay in a cheaper, but closer, hotel, this is a good thing. If it means the conference or your company needs to pay more, so be it. Most trips I do are short which means I will spend most of my time at the event. Having a fancy hotel isn’t useful when you have no time to enjoy it. The most important bits are that the place is clean, has fast connectivity in your room, and is easy to reach.

Stay active – or your health will suffer

If you can, try to find a hotel with a gym – no matter how basic. It is the best thing to fight jetlag and to clear your head. It is also important. When you travel, you sit a lot and you don’t move on a plane. That’s bad for you. You also consume a lot of food and drink on planes and you don’t give your body a challenge to burn it. I found that going to the gym before and after events allowed me to be much more energetic. Look after yourself – nobody else does.

If you’re tired or sick, your work will suffer

Jetlag is a pain and will turn you into a liability. You can not be in a stressful environment when you are not awake and relaxed. You will make mistakes, you will say things you can regret online later and you won’t be able to take in as much as you need. So look after yourself and get sleep when you can. You don’t need to be part of every social activity of an event and should sneak out for a kip whenever you can. Try to get enough time to deal with jetlag and look at what you eat and drink. You can not get sick. And believe me, this is a full-time job. Time differences, over-zealous air conditioning, pressurised aircraft and unknown food all mess with your body. Everyone I know working in DevRel carries a bag of medication. Acid reflux, indigestion, unwanted bowel movements and sore throats and runny noses. All commonplace enough to prepare for them.

Adding to that is that being on the road and constantly having to adapt does things to you. In Pattern Recognition William Gibson describes jetlag as “your soul trying to catch up with you” and that is pretty accurate. Being more emotional without planning to is common on planes. There is a lot of research into Why people cry on planes and I also find myself doing that.

Take care of yourself, please.

Point-to-point annoyances

One thing I am adamant about is that a conference or office makes it as easy as possible for me to get from the airport to where I need to go. I don’t want to deal with pushy unlicensed cabbies. It is also not fun to try to use public transport in a place you don’t know after 30 hours in the air. This may sound whiny and “first world problem”-ish but any minute wasted on the road isn’t doing you any favours. At least demand a good explanation what to do to get there from the people who invited you.

Expenses sound fun, but aren’t

Living on expenses sounds great, right? It is, to a degree, and it would be much harder – and silly – to spend your own money to do your job. But it also means that you need to be diligent about keeping receipts, and note down who you ate with, what and when. You often also have a company card unknown or unsafe to use in a certain place. Then you need to get money out. And you need to explain your company why you didn’t pay by card, suffering twice from the lack of support. It is important to do your expenses on the spot after your trip. Otherwise you end up delayed and get fined. It has become much easier to file expenses digitally now. I remember typing in all receipts, staple them to a piece of paper and mailing them to a different office. Yet, often you wait for weeks for things to get sorted out even now.

Summary: DevRel travel is lost time

When you travel as a DevRel, travel is not a gift any longer. It is a necessary part of your job. Where it is OK to rough it for a holiday, you shouldn’t sell yourself short when it comes to travel for work. It adds to the stress of your job. It takes up a lot of time you could be doing things to diminish the workload you already have. Whilst you can work in a lounge and on a plane I find it not that fruitful. Often I am tired, or euphoric about a certain topic and write a lot of things that sound lucid but are a write-off later on. One exception is going through emails on a plane. Being offline is a great opportunity to take time answering them without distractions. Traveling as a Developer Relations person is a lot of time a matter of good negotiation. Don’t try to be nice by allowing people to put you on a cheap flight and the wrong hotel. You don’t do them any favours as they would get a grumpy, non-effective you rather than the person they invited.

Back in March I was at We are Developers in Vienna, Austria, gave a two hour workshop on using AI on the web, a talk about code not being the answer to everything and MCed on the main stage on the third day. Another fun thing to do was this panel discussion on the Pitfalls of Machine Learning talking about the ethics and the false definitions of AI we have to battle.

I want to thank all people involved:

Moderator:
Jan Mendling ( @janmendling ), Full Professor at Vienna University of Economics and Business

Panelists:
Charlotte Han ( @sunsiren ) , Deep Learning Marketing Manager at NVIDIA
Tuomas Syrjänen ( @TuomasSyrjanen ), CEO of Futurice
Christian Heilmann, Sr. Program Manager at Microsoft
Rainer Steffl, CIO at Mondi Group

If you want to hear more about this topic and learn how to deal with it, I have a Skillshare course out there :

“Introduction to Machine Learning: Using Artificial Intelligence” is about an hour of materials to get you familiar with the topic of AI.

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!