I consider end-of-year a time to reflect. As I consider 2018, I feel it’s been a good year for me at Sabre. I’ve had the opportunity to work with many smart people as we delivered a lot of good travel solutions together. While I’m satisfied with my personal results, I can’t help but think about things that remain undone.

We all have limited time and need to prioritize where to spend it. As a developer relations engineer at Sabre, I think about and write software applications all of the time. Tools are a key part of moving quickly with quality on any software job. Choosing the right digital tools to craft software is just as important as picking the right screwdrivers, hammers and chisels for a home project.

This article wraps up ten technologies that I want to better understand in 2019. Maybe you’ll find a few that you’ll want to learn, too.

1. Docker — containers of code for manufacturing in the cloud

Think of the ways human beings have created things in the past: recipes for baked goods, checklists for forging metal objects, and telephones to repeat orders. In every case there’s a chance to take a shortcut, misinterpret, forget, splash, stumble, round off, accidentally chop, improperly fold and otherwise change the way a thing is made compared to how it’s always done.

Some changes are perfectly reasonable improvements. Some changes create a defect leading to a break or drop in performance. It’s easy for humans to make things a little bit different every time they start a project. Often that’s undesirable.

Now think of computers and software applications. Our apps are encoded in the perfection of a digital representation. We should be able to quickly make a flawless copy. It can be delivered across the country in minutes, seconds, milliseconds. We’ve been working on that for years and it’s still not good enough.

There are too many humans in the mix of provisioning servers, loading software, configuring operating environments, and signing off on deployments. How can we make that process better for people?

Docker is a technology that’s emerged as a way of helping me deliver exact copies of my software application to environments across the world. We can deliver our software quickly, on demand and at scale. This is a major convenience of control.

Everything that our software needs to work on any hardware – cloud or on-premise – is bundled into a package called a container. Containers are used as a blueprint to spin up new servers on demand.

The software isn’t just written once and then it’s done. A program and its dependencies is a plan for stamping out more copies to address users’ needs. Compare this ideal to traditional manufacturing assembly lines. Containerization helps us define our software factory built to stamp out parts assembled into flawless final goods.

Removing much of the friction around deployment encourages us to deliver changes more often. As a result, our team gets better at delivering software. Confidence rises, and we do more updates in the name of a fantastic user experience. Surely getting developers closer to the operation of their software is a positive improvement.

Frequent small changes are less risky than dropping a few big ones. We can start experimenting with existing applications to fine tune and polish. We can casually launch new apps to see their real-life promise.

The most important programming language in the world changed significantly a few years ago and we’re still trying to understand all of it. The language is JavaScript. The committee guiding its evolution documented all of the improvements and published it as something you’ll see called “ES6” or “ES2015.”

We saw changes in JavaScript that added new operators, extended syntax, debuted data structures, and increased the portfolio of utility functions.

How can I claim JavaScript is the most important programming language in the world? It’s the only one that runs in web browsers.

The web is the primary delivery platform for the world’s computer users. That includes iOS, Android and other smartphones too. JavaScript provides a path for frontend developers to become full stack developers because of Node. Node is JavaScript running on a backend server. Learning JavaScript is well worth the time for any active programmer.

If you’ve used JavaScript in the past ten years, you’ve seen it work just fine. Why improve it? Because development teams are loading up JavaScript applications with more capabilities, features and interactions than ever before. Team sizes are increasing, and software life cycles are extending.

We now have increased expectations of web-based user experiences.

If you haven’t tried JavaScript’s new features you’ll quickly see how much better you can work with it. Much of the syntax was greatly improved. How? It’s been informed by studying the best aspects of every modern programming language as well as seeing experiments conducted on the language itself. Several exploratory languages compile down to JavaScript taking advantage of its reliable execution environment. Research like that inspires the JavaScript steering committee.

Some of the new syntaxes are so popular and useful that I’ve already begun using it in 2018. Every time I pull in a new feature I see there’s more to use. I’m re-learning JavaScript and expect it will keep me occupied well into 2019.

The Go programming language has popped up on my radar from a number of sources over the past year. So much so that it gave me this uncomfortable feeling that I was missing out on something amazing that only a few insiders understood. Programmers are always excited about new tech, but the reoccurring whispers of Go were persistent.

Should we use something like this just because everyone else is and it seems popular? No, but when enough bright people rally around using something it raises our curiosity. There’s nearly always valuable takeaways in every effort beginning with curiosity.

Once I briefly looked into Go I could tell it has an interesting pedigree given its designers and sponsor company. I’m going to naively claim Go is a backend web stack language. It’s probably good for scripting O/S utilities and other automation chores as well. From my point of view, I’d learn Go looking to replace Java, Node, PHP and the like.

Go is statically typed to reduce run-time bugs, compiles to improve performance, has relatable syntax to make writing it simple and has libraries addressing the needs of modern networking. All good qualities, and I can see why there’s enthusiasm for it.

Generally speaking, augmented reality (AR) is a UX technique taking images of the user’s real-world environment and overlaying it with digital enhancements. The digital layer provides useful information, or joyful graphics, in 2D or 3D. The real-world background layer is generally produced by a camera quickly scanning the user’s surroundings.

I self-identify with being a computer programmer and a frontend programmer at that. Frontend programmers enjoy being up close to the end-user while working alongside product managers and UX designers. One possible outcome of AR is that it might become “the new frontend” in the next five to 10 years.

Many solutions for augmented reality exist. One particular combination is gaining traction:

Native apps running on Apple iOS.

Swift programming language for building my app.

ARKit for augmented-reality sensor measurement and tracking.

Notice that AR is considered separately from virtual reality (VR). VR tends to keep its viewer tethered to a base station – usually indoors. In other words, wearing face-mask style goggles tethered to a desktop computer generating a completely synthetic environment.

AR is preferred when it’s important to gets users out into the physical world where they can collaborate with other people. AR is more problematic in some ways but more fulfilling in others.

Machine learning (ML) isn’t new to programmers at Sabre. For years we’ve been watching it emerge in the news, reading about techniques, applying them to products and benefiting from it as consumers. From my personal point-of-view, I’ve been waiting for ML to get easier to dive into.

So far ML is too technical and low-level for me. Researchers are still building up fundamental layers to make ML functional, and I’m waiting for the leading tech-stack to emerge. I want ML to become easy enough that application developers can use it as a daily tool.

That ideal ML tool doesn’t need to be consumer-grade, but it does need to offer more abstraction and coordination for typical developers to enjoy working with. Now ML feels full of industry jargon and technical friction for getting started.

Most developers ought to pick up enough practical ML tech in 2019 to feel like they can be competitive. It’s important to start getting an ear for the vocabulary, understanding reasons for why, and when to use it and how to write code applying library capabilities.

Cascading Style Sheets (CSS) is a major part of any website. It’s a markup language enabling developers to define graphic design for pages shown and apps running in web browsers. CSS works together with HTML and JavaScript to complete the fundamental tools for building web-based user experience.

Over the years, designers have sought out increasing levels of control laying out their web pages. They expect the same pixel-perfect direction that they have in traditional media such as print. Demands are rising. Laying out content in the browser has never quite worked out as well as we hoped and needed.

Some tricks of the trade included using the “<table>” tag for visually formatting text and pictures based on rows and columns. Then we discovered the idea of “floats” for sliding “<div>” element containers around the screen. We could break content out of the bounds of boxy tables.

Flexbox was our first true sense of control. Just a few years ago the Flexbox display capability showed us how to achieve layouts appearing similar to a typical app UI. Flexbox still works well today. It’s the tool that we commonly reach for here at Sabre when novel layouts are needed on web apps and web pages.

CSS Grid is the latest standard for layout control, and, by all measurement, it’s the best yet. Designers can ask for uniquely asymmetrical page layouts, and developers can reasonably recreate them. CSS governing bodies have put more time into writing this standard so that the most popular web browsers accept and implement the specification. That means your CSS Grid code is more portable than any solution before.

There’s no doubt that we’ll see plenty of Flexbox, some float and even a few tables in legacy website code. Expect to see CSS Grid code when you read through modern CSS frameworks and libraries. I’ll practice with CSS Grid in 2019 to see how I can pull it into my daily developer toolbox.

There’s a common industry notion that all companies will become technology companies. We can build on that line of thinking by asking if companies will start making digital products? Particularly digital products in the form of APIs.

Why? It seems to me that a company that has become well known for doing something good will inspire other companies to become good at doing that thing, too. Offering easily consumed APIs is a gateway to that goal.

Here’s a good example: We can find a company that has a database of all roads and popular attractions in the world. When that company produces a “Maps API,” we can use it in one of our apps and become good at showing roads and popular attractions, too.

We didn’t need to send our programmers to attend the Anaximander University of Cartography to study map-making for four years and then travel the world writing down all the interesting things in it.

Instead, we would only need a few days integrating a good Map API into our app. Then we’ve improved our unique-user experience for our customers. How is that better than what the API provider does? They’re great at their subject, but they don’t know our customers as well as we do. They couldn’t replicate our unique UX that serves our audience.

It’s no secret that Sabre has a rich legacy in APIs. We offer services that power the travel industry. Our goal is learning more about making fantastic APIs to make it easier for software developers to become great at helping travelers find dream offers.

It’s been routine for two companies to interface with one another through salesmen talking. Now it’s normal for two companies to interface with one another through software developers coding to an API. Does that feel like the new normal for your business? If not today, will it be next year? If offering APIs feels like your future, it’s worth you learning more about them soon.

Internet of Things (IoT) is one of those industries that I understand is very important, but I don’t understand how to think about it. My history as a frontend/UX/web programmer is probably putting me at a disadvantage. Nothing I see in the IoT world reminds me of what I know.

One of my goals in 2019 is buying a piece of IoT-enabled hardware and programming it. Something unique like a camera, light bulb, robot or measuring sensor. IoT devices ought to work out of the box, be conveniently powered, WIFI connected, programmable, not too expensive, and obviously useful. It would be nice if it had a RESTful API too.

Learning how to program an IoT device might challenge the beliefs of a frontend programmer. Our preconceived notion of UI only being an onscreen, 2D presentation might be old fashioned at this point. A programmer might be surprised to find lights, buttons and sensors are entirely different, but often appropriate, UI. That could lead to knowing solutions for our customers’ problems.

Security became important the moment human beings got stuff that other humans found valuable. Is theft built into humanity? Maybe that’s just an interesting debate topic, but can we all agree that digital break-ins are a highly visible issue for companies?

Major breaches have brought down companies and destroyed careers. This is happening several times a year for as long as we care to remember. In fact, we can’t forget it because news coverage provides cautionary tales that none of us want to be a part of.

Any network-connected devices containing sufficiently valuable data will attract the attention of malicious actors. It’s our job to stop them. There’s no other way to say it, it’s a full-time job, and everything around security takes active hands-on work.

Security is all of our concern and software developers need to put more time into studying it. Put into practice whatever you learn about security.

Recommended resources:

Writing computer program logic in a more secure manner.

Monitoring my networking resources for security breaches.

Acting personally with more secure behaviors.

Automated testing for continuous vulnerability checks.

10. ReactJS — organize your web frontend code with purpose

If you’ve been delivering web-based software applications over the years it’s likely that you’ve been programming in JavaScript. It’s a good language that’s getting better. Especially with the improvements mentioned in topic 2 on this list.

What’s tricky is that JavaScript, and the web platform in general, doesn’t offer many opinions on how to build software at scale. Freedom of choice is awesome, but it can be disabling, too. Any popular web app built in this environment will be improved over time with more capabilities, features and interactions. When that happens, the development team size will increase, and its life cycle will be extended. Sounds like success, and that’s good news.

Now that we have increased expectations of web-based user experience, how do we architect software that operates at scale?

Frameworks have been helping address that challenge. There’s been a dozen of them over the years for frontend web programming with JavaScript. ReactJS has emerged as one of the top JavaScript framework candidates. A good framework will help teams clarify how to work together building reusable components that are easier to maintain over time.

ReactJS is popular enough to have a solid community of engaged users. They’re producing educational content in the form of blog articles, Q&A forums, conference videos and sample apps. These are big wins for a team looking to accelerate their learning and productivity.

There’s always much to learn in the tech world – too much in fact. Breaking down the options into a prioritized list makes it feel more manageable. Looking forward to finding new discoveries is one of the exciting reasons programmers are attracted to the tech industry. Opportunities for meeting the smart people inventing and teaching tech is a reason to stay.

Sabre software developers are always looking at ways to improve how we build applications and services. As we evaluate these new technologies we might decide they’re the perfect tools for building our next product.

Ken Tabor is a veteran programmer with years of experience developing websites, mobile apps and video games. He shares his enthusiasm for technology as a writer, teacher and frequent speaker at conferences including South by Southwest, DevNexus and Big Design. Ken is currently a software engineer at Sabre helping foster a modern developer experience for its API platform. His areas of interest include NodeJS, machine learning, and design thinking. He is the author of "Responsive Web Design Toolkit," published by Focal Press. When Ken isn’t working he’s having an adventure with his daughter. They’re always looking for the best chocolate, books, and coffee in Dallas. He can be reached at kenneth.tabor@sabre.com. Follow him on Twitter, @kentabor.