I published an Intermediate Typescript and React Handbook a few weeks ago.

It received numerous views and I got several emails. Most were “thank you” emails, but then there were others like:

“… I am new to programming, what is Typescript?”

“Thanks for this free ebook, but how do I learn Typescript as a beginner?”

I had clearly stated that the handbook was for intermediate developers who already knew some Typescript — but when did that ever stop anyone from downloading a free resource! :)

In this guide, I’ve decided to answer the queries in those emails with the article I wish I had when I learned Typescript.

Now, if you’re still reading, I’ll assume you’re a Typescript beginner.

Strap up. You’re in for a fun ride.

Explaining Typescript to a 5-year-Old

My approach to teaching has always remained the same.

If you can’t explain it to a 5-year-old, you may not know the subject well enough.

Instead of swarming you with a lot of technical jargon, let’s try something different.

Let’s use an analogy you’ll never forget.

When was the last time you visited the grocery store?

Consider TypeMart:

TypeMart is your typical big grocery store.

Do you want a variety of grocery items picked up after work? They’ve got you covered.

On the other hand, here’s JMart:

JMart is a smaller grocery store for quick purchases.

In Berlin, where I live, we call these Spätis. These are essentially small convenience shops.

I’m sure you’re not here for a German lesson.

What’s important to us here is how the grocery stores, JMart and TypeMart work.

How JMart and TypeMart work

With JMart, you go into the shop, find the grocery item you need and take it to the cashier.

At this point, you’re not quite sure how much the grocery item you’ve picked costs.

Well, that’s why you go to the cashier!

The cashier takes your item, scans it and tells you how much it cost.

If they’re “better” at their job, they’ll tell you how much the item cost off the top of their head (or some manual catalogue they keep in the drawer)

The process seems brittle, but boy does it work!

These cashiers are smart as hell. No items are off-limits.

They know what every item costs.

One beautiful Tuesday, you decide to try out TypeMart.

You soon realise that things are different in TypeMart.

’Those pesky big stores,’ you may say.

Unlike JMart, they’ve got a price tag for every damn thing.

They rob you of the thrill and the look on the cashier’s face as they compute your bill.

On the other hand, what they give you is some sort of assurance.

There are no surprises!

You know exactly how much every item you’ve picked up costs.

That is beneficial on days when your wallet is slim.

Every pence matter.

Why does this analogy matter?

Your intuition was correct.

In the analogy, JMart represents Javascript and TypeMart, Typescript.

When you go to a supermarket, there’s an unwritten contract.

They promise to have what you need at a fair price.

You promise to pay for what you buy (except you’re shoplifting. Don’t do this.)

The same is true for code.

It’s an unwritten contract, but a clear and brutal one.

Your contract is with the user of your application.

You promise that your application works.

Consider an example with a conference call application like Google meet.

The promise with Google meet is you’ll always be able to make video calls. They also promise you can mute the button while you chat with your partner or watch a quick TikTok.

Good thing they can’t hear you!

Or, so you think?

Imagine if the mute button didn’t do what it promised.

There goes your secret.

And with it goes your trust in Google meet.

The same is true for the applications you write.

You promise a working application, and your users trust that’s the case — assuming you’ve earned their trust.

Let’s now bring this home.

In JMart and TypeMart, the goods are money. With software, the goods are data.

Assume you had a basic counter application.

Your user sees a fancy UI, but under the hood what’s really making magic is the counter variable you increase or decrease.

With JMart (analogous to Javascript), the goods are not labelled (price tagged). You don’t know how much anything costs. You go to the cashier to meet your fate.

This is similar to how Javascript works.

You define and manipulate all sorts of variables, but there’s no explicit label for what the variables are.

You trust what you’ve written and pass it on to the Javascript compiler to meet your fate.

Consider the following trivial Javascript code:

In a standard Javascript application, you may go-ahead to write the following:

Even though cars does not exist on the JMArt object, there’s no explicit label that defines that.

So, as you write your code, you may not know this line of code is faulty …

Until you go to the cashier to meet your fate.

The cashier here is the Javascript interpreter.

Typically, this happens when you run the code in a browser.

If you do, you then get an error that reads can't read price of undefined

If you shipped this code (mistakenly) to production, your uses will be met with this ugly error as well.

You’ve just compromised their trust in your application.

With Typescript, things are different.

Every data is “labelled” just like in TypeMart.

Before you go to the cashier aka the browser to run the code, you can tell if your application is working as it should!

The Typescript compiler will throw an error letting you know you’ve made a mistake accessing a wrong value.

This happens within your code editor before you open the application in a browser.

Like picking up a grocery item you can’t afford at TypeMart, you see the price label.

You know what’s in your wallet. It’s fair to say you’ve been warned.

This right here is the major initial definition of Typescript you should know.

TypeScript is JavaScript with syntax for types.

Where types are labels dangling around your grocery item (data), telling you exactly what each data represents.

Consider the following trivial Javascript example:

In Typescript, this code could look like this:

Note how this looks identical to the Javascript code.

However, it’s got a major difference: the data a and b are 'labelled'.

This code specifically states that a and b expected in myFunction are strings.

With this information (called type annotation), Typescript can now show you errors as you write your code.

These errors will usually be seen in the form of red squiggly lines. Similar to errors in applications like Microsoft Word.

You may then hover over these lines to view the details of the error.

In this simple example, the crux of the error is that the multiplication operation should not be run on strings.

Non-exception errors

If you’re a more experienced Javascript developer, you can already notice that the code example earlier examined doesn’t throw an error in standard Javascript.

If you computed “1” * "6" in Javascript, you’ll get 6.

Internally, Javascript coerces the strings to numbers and performs the multiplication operation.

These sorts of errors that don’t fail in Javascript, but error out in Typescript, are called non-exception errors.

These are supposed to help you prevent nasty bugs in your application.

You shouldn’t necessarily worry about this at this stage of your learning Typescript journey, but it’s worth mentioning.

As you can see, Typescript goes far and beyond to help you catch unwanted behaviours in your code.

A simple way to fix this would be to type the parameters explicitly, i.e., a and b as numbers:

And away goes the error!

Don’t despite Typescript for bringing these non-exception errors to your attention.

They are potential sources of bugs in your application.

Typescript to the rescue 💪🏽

Conclusion

Ask yourself, do I now know what Typescript is?

Yes, you do. Conceptually.

Typescript is to Javascript what TypeMart is to JMart.

An organised way to label the data within your application to prevent unknown errors.

These errors will be caught and brought to your attention before you go to the cashier, i.e., before you run your application.

Take a moment to digest this information. It’ll be crucial as you learn more about Typescript.

Give yourself a pat on the back, and go write your first Typescript application.

Further Resources

• Intermediate TypeScript and React Handbook: Learn intermediate Typescript with React by building a strongly typed Polymorphic component.

• Fancy a quick Typescript exercise? Spot and fix the error in the earlier described example. Use the official online editor called the Typescript playground here: [https://shrtm.nu/FlC0]

Since the inception of online advertising, users have always complained about the design and relevancy of ads. With the nature of business being to aim for maximum visibility, there is always a dissonance between attention and readability of a website’s content.

As we all know, contrary to print media, there are virtually no technical limitations on the web when it comes to the visual appearance of an ad. Display units in specific have reached a state where some are so extremely annoying that certain committees are even discussing standards for acceptable ads.

Native Ads to the Rescue

Our generation has mastered the art of ignoring such content and the industry has largely caught up on that. Native ads is one of the least invasive measures that fit a publisher’s web experience.

The idea is stunningly simple: Instead of marketing out differently styled content on your website (with overlays and blinking banners probably being the most annoying manifestation of their species), you get to decide what an ad unit looks like. It is then up to the advertiser to provide a copy, among other creatives. Not only is it visually less disturbing — by sharing your app’s look and feel, but a native ad is also very likely to exhibit a better click-through rate.

Native Ads: A Quick Example

To give a quick peek on what Omio’s ad product looks like, have a look at the screenshot below. The ad is distinguishable from the rest of the content both by bearing the “sponsored” label and less functionality compared to the remainder of the result cells.

But it shares the same style and is built using the same frontend components as the rest of the page.

The native ad is intuitive and blends with the entire user experience of the product. If the “sponsored” text wasn’t present, you’d never recognise that result as an ad.

5 Reasons the Status Quo wasn’t enough for us.

Generally speaking, serving ads is implemented by following a pretty standard procedure. If you’re running a website, adding a small piece of javascript code is more than enough to get you up and running. If you want to spice things up a little you can use an ad manager to enjoy sophisticated targeting rules.

Initially, this was pretty much the path we chose to go down as well. Our baseline setup contained an ad slot in our React frontend which was remotely managed by Google AdManager. With as little as some HTML & CSS and some targeting rules based on the user’s search terms, our team was able to run ads on page.

Even though this worked for our first iteration, it just didn’t feel right for a number of reasons.

1.Crafting Pixel Perfect Designs

Building pixel-perfect designs isn’t a superfluity or after-thought. It is to serve the user.

This core value is etched deeply into every product we develop — and the implementation of native ads by mixing some basic HTML and CSS in a confined editor seemed to be doing an injustice to our design philosophy.

Our design team has spent countless hours running user research and building a design system that serves as a common language for all teams in the company. This keeps the entire organization (with a diverse group of teams) on the same page. By leveraging our design system, teams can move faster, communicate better and ultimately increase the speed at which products are released without compromising pixel-perfect designs.

For engineers, a big part of a design system is a library of frontend components. It is more challenging to create perfectly designed native ads without taking advantage of an already established library of components built to reflect a consistent representation of our brand message. A component library not just provides us with pixel-perfect designs, but greatly increases the speed at which we ship ads without having to reinvent the wheel.

More so, when everyone speaks the same language, things get done faster. As a company, a component library lets us speak the same language. Yes, with gruesome engineering hours, we might end up re-creating near-perfect Ads with a WYSIWYG editor, but by completely neglecting our component library, we would be disconnected from speaking the same language as everyone else in the entire company.

To sum up our thoughts on creating pixel-perfect designs, our goal here was to build ads with a great user experience and to do so without breaking the internal means of communication we hold highly within the company — a consistent design system built to promote pixel-perfect designs. This means reusing our frontend component library and delivering a consistent user experience across the entire user funnel, every single time.

2. Speed of Iterations

Iterative and user-data-driven development of software is highly encouraged here at Omio, and as such we’ve built pipelines and processes that enable teams to move fast across the entire company.

Delivering highly performant ads require a lot of tests and iterations to run successful campaigns.

For example, if we went with using the typical WYSIWYG solution, a simple A/B test fostered by a change in design will require communicating with our Ad ops to implement the new design and also tweak the ad campaign set up. This isn’t very efficient.

A more solid approach would be to let our frontend engineers take care of the design implementation, connect this with our A/B test service and letting our Ad ops focus solely on managing the ad campaign. This breeds a division of labour and specialization among the engineering and ad ops teams. All engineering efforts are centralised within the engineering team and the planning, execution, tracking and analytics of the ad campaign is managed solely by the Ad ops team.

This sort of separation of concerns weeds out unnecessary dependencies between teams, a common source of friction when building any product. This leads to faster ads development and release cycles.

3. Versioning and Using a Single Tech Stack

With a WYSIWYG editor, your options are limited. You write some HTML and CSS, and for writing Javascript, you’re confined to writing scripts within the script tag of an HTML panel.

What if your team had spent time building a thriving ecosystem around a specific modern tech stack? A stack that includes release pipelines, preview functionality, modern development experience, and embraces a set of standards and best practices?

As a company, our frontend stack relies on React for creating delightful user experiences. No engineer should be forced to write HTML, and CSS in a WYSIWYG editor when we’ve built a solid infrastructure around our tech stack.

The benefits you get from using a modern tech stack likely outweighs what’s offered by WYSIWYG editors in an ad manager.

Now consider versioning, an integral process in the way software is developed today. When you have multiple developers working on a single application, as is the case in most notable projects, it’s almost impossible to prevent developers from overwriting code changes and breaking each other’s code without a solid versioning system.

With modern versioning systems, a developer can download the current version of the project, work locally and merge their changes without stepping on another developer’s toes. This is important as you can deploy varying versions to different environments such as QA and production, and also work locally in confidence that you’re aren’t jeopardising your colleague’s efforts.

These were strong considerations while designing and planning our native ads implementation. It doesn’t matter what technology stack you use, these concerns remain potent.

We believe that building well-implemented native ads doesn’t mean kicking your current tech stack and development processes out of the window or compromising on a simple yet integral process such as versioning.

4. Internationalization

When building a global brand, the internationalization of your products is important. It could very well influence the acceptance of your product offering.

If your app / website is available only in English language, you will be cutting off the opportunity to tap into potentially larger foreign markets.

86% of localized campaigns have been found to outperform English campaigns in both click-throughs and conversions.

Internationalization is not a trivial requirement. You need correct translations (preferably by experts/natives), and you need to create a process for which your engineers and copywriters can stay in sync on these translations. For most companies, a process has been tested and currently serves the need of your website/app Internationalization.

Here at Omio, we’ve built a process that leverages PhraseApp service which provides us with instantaneous updates. With internationalization being a core requirement for our product offering, it goes without saying that this was a huge requirement for our native ads as well.

How do you make sure that copywriting and translations are seamlessly integrated into the ad development experience? How do you also ensure that instantaneous updates are received as soon as translations are updated? Most ad manager editors just don’t provide the same level of confidence, communication and reliability you get from a standardized internationalisation process. Regardless of your current internationalization process, you’ll most likely spend ample engineering hours if you tried to replicate this within the confines of an ad manager.

5. Sharing context between the Ad and the Website

Naturally, most ads do not interact with the page itself. They either open a new window or perform a whole page reload once being clicked on.

Hence, one requirement we put on ourselves was:

If our ads are created treated with the same standards as the rest of our product, they should behave like it.

This in turn would mean: They are capable of interacting with the page they are placed on, thus providing a seamless user experience.

Sharing context between a native ad and a parent window sparks interesting engineering challenges.The scope of this article doesn’t permit a full-blown discussion on all the problems encountered and our technical solution to them.

However, the crux of the challenges stems from the fact that native ads powered by an ad manager are typically rendered within an Iframe, and an iframe possesses inherent security limitations set by every browser.

A common clause you’d hear within the tech community is: “use the right tool for the job”. While “the right tool” is sometimes subjective, in some cases the choice is based on the ease the tool provides for solving certain engineering challenges.

For our native ads implementation, we decided we’d have a greater chance of solving this challenge if we used the same tools and services available to us in our day-to-day development processes.

The reason this was important for us is that our native ads aren’t just made of static images and text. They were designed to be highly interactive with the host page, and this poses even more challenges.

Doing this outside the comfort of a standard development process would mean solving difficult engineering challenges with unfamiliar tooling provided by an ad manager. While this may not be the wrong call for everyone, in our case, our judgment was based on reusing the tools we already have in place and making sure we were ready to tackle the challenges that’d come from implementing highly interactive native Ads.

The “right tool for the job” in this case was sticking to tried-and-tested tools we already leverage every day in our day-to-day development. Without going into too much detail, we leveraged the window.postMessage browser API and wired it up with existing redux actions on the frontend. This allowed us to establish a 2-way communication between the iframe and parent. We will post a deep dive into our technical solution in the follow up article.

What’s next?

So far we have seen great initial results which have proven that our users really like interacting with our native ads. Seeing that our tech and product work has paid out is encouraging for us as a team and we will see how we can scale the approach from hereon.

In the next segment we will shed more light on the technical details and the overall setup of the system, so watch this space for the next segment of ads with a great UX!

~

Enjoyed the read? Omio is hiring! If you would like to be part of our team and solve great problems, make sure you visit our jobs page and follow us on Medium.

Google Ads and React.js: Delivering Ads with a Great UX was originally published in Omio Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.