I wish we never explained web components by "well, it's actually four different things, but I won't tell you which one you care about."

Spoiler: It's custom elements. It's always been custom elements.

Since forever, library authors have felt the pain of needing to match JavaScript with DOM elements. For instance, if you're writing a date picker, someone needs to call YourDatePicker.init(element) for every <input class="date-picker"> that gets attached to the DOM.

There is no built-in way or even standard way to do this. Every library shipped their own solution to this, using a jQuery plugin, global activation function, magic onload handlers or a framework-specific base class.

Custom elements make all of that go away. Just use in your HTML, or create it using the framework of your choice and it will Just Work ™. No JavaScript ceremony required to make a DOM element come alive. It's a giant step forward for how we bootstrap web apps, or how we share code between apps.

I think that leap is the reason we're seeing an increasing number of JavaScript libs switching to custom elements for script/element matching, although browser support is an unholy mess. Microsoft is dragging their feet with Edge and of course pretends IE11 doesn't exist anymore, while at the same time blocking upgrades from IE11 to Edge on Windows 7. Firefox hides it behind a feature flag. Safari mostly supports it with some caveats.

The polyfill from hell

"But we can polyfill it". Except you can't easily because it breaks assumptions of your build pipeline in interesting ways. You see, Chrome's native support for Custom Elements v1 requires native (not transpiled) ES6 classes because politics. And your app probably ships ES5 prototype spaghetti in production. So the Babel or TypeScript presets you use to support IE11 will break custom elements in Chrome.

Now you need TWO builds of every JavaScript file: One with native ES6 classes for Chrome and another with dumbed-down ES5 constructors for IE11. (hat tip to Lucas Dohmen)

Understanding and maintaining two build pipelines is totally doable for an experienced development team, but will probably keep custom elements out of the mainstream for now. An interesting date to note here is Jan 14th 2020, when Microsoft kills Windows 7 / IE11 and we might finally be able to ship ES6 code without transpilation.

Introduce Yourself

Hey there! I'm Robin Kara, living in southern Augsburg with a nice view on my garden. After work I love tinkering, discussing, hanging out and having some beers with other tech-enthusiasts and makers at the OpenLab.

Before joining makandra I was helping cloud providers in the EMEA region to have their storage backend running lightning fast, highly available and automatically provisioned. Even before I left school, both Linux and Ruby already were the tools of my choice when it came to solving problems. Computers being my hobby and making some nice summer jobs possible, it was just natural for me to start a apprenticeship for IT professional after graduation. Generally speaking, I would always prefer and advocate free software over closed source software, as long as it does the job well.

How did you first learn about makandra and what drew you to makandra originally?

Given my personal interests it's no surprise that I first learned about makandra at our local hackerspace. When I was looking for a new job where I wanted to do more Linux during the day, I was very glad to hear from Andi (who occasionally stays at the OpenLab too) that makandra could use some support with their server operations. The fact that I could also improve my ruby skills at makandra even put the icing on the cake. :)

What is your role at makandra?

I'm working as an operations engineer, keeping your servers happy and ready.

What are 3 words to describe makandra?

• agile
• reliable
• ambitious

What challenges are you looking forward at makandra?

For now, I'm looking forward getting known to all the fancy projects you host and build on our OpsComplete infrastructure. Usually it's a lot of fun for me to understand or debug complex computer networks, so I hope I can find some potential for optimizations of our infrastructure.

Are you messy or organized?

I'm desperately trying to formalize and organize everything but in the end I'm a chaotic nature and love to see how beautiful things emerge from chaos.

Best vacation you've been to?

Two weeks in Sweden's nature with some colleagues. Next to our holiday home in the forest we had a hot tub, a nice fireplace and a cold lake but absolutely no mobile internet connection. That was just the perfect setting to relax and experience nature.

Describe what you were like at age 10.

I was an easygoing but always bubbly guy, wondering about a different detail of our wondrous world every day. Often, my parents had to hold me back when I got a new toy and immediately started taking it into pieces to understand its inner workings.

Do you recall any embarrassing moment at work?

Yes. Once, I showed up at a customers site in Czechia for some weekend maintenance work, but unfortunately "off by one" week. I only realized it when I gave my customer a call to ask when he would show up and he told me "next week".. I don't want that to ever happen again. ;-)

If you were an animal what would you be?

A robin, I guess.

People would be surprised if they knew:

I did use Microsoft Windows for a certain challenge, out of free will.

What book did you read last?

Homo Deus, it's worth reading.

Vim or Emacs? (Be careful here…)

:set nocompatible and the party starts.

What tools are you using that you don't want to miss anymore?

Well, I probably couldn't live without my screw gun and my battery powered circular saw anymore. When it comes to software tools, I love my i3 window manager, taskwarrior, notmuch, vim and zsh running on a debian based distribution.

Welcome to makandra, Robin!

Rails 2.3 is 9 years old this week. And it's now compatible with Ruby 2.3.

While this is not a drop-in solution and will involve some manual work for those who want to upgrade to Ruby 2.3, it will allow Rails LTS 2.3 applications to benefit from the 2x - 4x performance improvements of Ruby 2.3 over 1.8.

If you don't want to or are unable to upgrade your Ruby version, there is no action required on your part. Rails 2.3 LTS will continue to work on Ruby 1.8.7, and we are committed to supporting 1.8.7 indefinitely.

If you have already added some monkey-patches to make your Rails LTS app work with Ruby 2.x, we recommend to remove the monkey patches and follow our upgrade guide.

Some assembly required

You can now upgrade your Rails 2.3 LTS application to Ruby 2.3 without a need for the numerous patches and workarounds related to Rails that were necessary for a Ruby upgrade in the past. It also means that we will test all new releases against Ruby 2.3 (as well as 1.8.7).

However, your application will very likely have some incompatibilities outside of Rails itself (either in your own code, or in third-party gems). Upgrading will require the attention of a Ruby developer, and a moderate amount of work and testing, depending on the size of your application.

We have managed to upgrade two medium-sized Rails 2.3 applications in about 2 days of effort each. Both are now running at roughly twice their former speed. Your mileage might vary.

If you want to attempt the upgrade, we have written a detailed upgrade guide.

Introduce Yourself

Hi, I'm Daniel Straßner, living in a town close to Augsburg. During leisure time I like fiddeling with my Raspberry PIs (there's four of them). I use them as Media PCs and server playgrounds so I can experiment with stuff like Docker, which works extremely well (check out hypriot). Other than that I care for the preservation of Bavarian heritage and customs. This means you could see me doing a Schuhplattler or playing the button box at public events around here.

Before I got into the IT industry I studied business mathematics in Augsburg. It was an internship that got me interested in software development. After my bachelor I decided to do a graduate program in computer science. During college I worked for several software companies as a working student.

How did you first learn about makandra and what drew you to makandra originally?

I learned about makandra as I found an ad for a Ruby-on-Rails workshop at the University of Augsburg. I couldn't attend the workshop, however, I checked the makandra webpage from time to time as I really liked makandra's core values and their approach to developing good software. When the time came to decide for a topic for the master thesis, I got in contact with makandra and was lucky that they had plenty of interesting new problems to solve.

What is your role at makandra?

I'm working as a software developer.

What are 3 words to describe makandra?

• professional
• efficient
• caring

What challenges are you looking forward at makandra?

As trends in the software industry are vastly emerging it will be interesting to decide for new technologies we could add to our stack. People at makandra use to make well-considered decisions about software, so don't expect us to do right away.

What book did you read last?

My bedtime reading for the last few years: The Adventures of Sherlock Holmes (pages: ~1400, pages before falling asleep: ~5 => I'm good for the next 280 years with this book)

Vim or Emacs? (Be careful here…)

Vim (but I'm still learning)

Best vacation you've been to?

A trip through the states (west). Quote: "It's not hard to be easy-going when you're living in California"

If you were an animal what would you be?

Some kind of bird (not sure which) as long as I can fly

If you had to eat one meal, every day for the rest of your life, what would it be?

Oma's Apfelnudeln mit Kartoffelsuppe (yeah that's an established term)

Welcome to makandra, Daniel!

1. Web devs will start owning performance on mobile

2017 will be the year where 20 seconds time-to-interactive on mid-range phones stops being cool. If you don't think that's an issue, maybe stop testing for mobile with a MacBook Pro and a small browser window.

Every Javascript library, Bootstrap release, web font and icon set adds seconds to load time on low-powered devices. The time has come for developers to own that trade-off instead of piling even more work on overworked CPUs and exhausted batteries.

In 2017 we will see teams succeed in making fast apps by simply loading less stuff. Expect radically smaller Javascript payloads and a move to minimalist CSS boilerplates. I even expect to see see web design with traditional web-safe fonts to save that 500 KB download of Open Sans which looks as dated as Arial these days.

Good idea that will not happen in 2017: Google search results showing how many minutes a page load will suck out of your battery.

2. IoT hype will continue to endanger the public

Pushed by consultants, every device that does not need to bundle Wifi and a web server will do so in 2017. Hence we're going to see a lot more botnets of unpatched toasters and lightbulbs.

I predict that there will be at least one large-scale DDoS attack caused by unmaintained household devices.

Good idea that will not happen in 2017: Regulations enforcing a best before date for networked devices, until which manufacturers are required to produce security patches.

3. Native apps must stop competing with the web (or die)

With two thirds of users having access to Progressive Web App features like store-less installation and offline support, the sweet spot for native apps must move or disappear.

If you're working on native apps right now, make sure to build something that cannot be done on the web: Large offline media, background audio, low-friction payments.

I predict that in 2017, several high-profile media properties will abandon their native apps in favor of PWAs, lowering maintenance costs and increasing engagement.

Good idea that will not happen in 2017: App stores allowing low-friction inclusion of unprivileged PWAs in their listings. We probably blew that chance by not buying Firefox phones in 2015.