WebAssembly in production and “minefield” Smart TV: an interview with Andrei Nagikh

Interest in WebAssembly is great, but so far you rarely meet people using this technology in a working draft. Developing applications for Smart TV is also “not typical JavaScript” when everyone has heard about something, but few have tried it personally.

And Andrei andreynagih Nagih has experience in both spheres: he previously worked on Smart TV-applications of the Peers.TV project, and in recent months has been so closely acquainted with WebAssembly, which eventually made a report on this at our HolyJS conference. And in the online broadcast of HolyJS, we asked him about both.

And now they decided that Habr's readers could also be interested in it, and made an edited text version of the interview.

(If someone is more comfortable with the video format, you can watch the original video instead of reading the post .)

Eugene phillennium Trifonov: You gave a presentation on WebAssembly here - were there many questions from the audience, and whether they were from “theoretically interested”, or were you practically using ?

Andrei Nagikh: After the report, I spent a whole hour answering completely different questions in the discussion area, I am surprised that there were so many of them across the whole spectrum. Most of the questions were from those who are “just interested” for now, but there were also people who already use them. What is surprising, because there are so few such people. There were quite practical questions.

Eugene: Previously, about WebAssembly said "soon it would have matured and become applicable." And now the technology is as “matured”?

Andrey: The technology itself is already quite working, you can use it in production. Here we use. But the problem is with the tools. The compiler itself is quite good, since it turned out to be older than the technology itself - it is available from the previous version, with asm.js. But debugging tools, source maps, debugger - this is still difficult. I think in the next year or two browsers will pull up these moments.

Eugene: And because of what you initially needed WebAssembly - what kind of project, and what is the benefit from this?

Andrei: One of our projects, ByteFog is a technology for P2P video content delivery. We are probably the most ideal user case that you can think of for WebAssembly. We already had a large code base in C ++, we did not want to rewrite it into some other language, and we needed it in the browser. Therefore, this technology seems to fit here completely.

At first we thought that we would take, simply compile and it will work. But, of course, this is not the case in life, that is why this rake report was born and, in fact, how to drag it all into production.

Oleg olegchir Chirukhin: And what were the main problems?

Andrew: The main problem is that we do not have access to the system. We had a native application, it could do anything. When we port it to a browser, we cannot do anything beyond javascript. And with this you need to somehow live, you need to use the browser API.

The process of porting our application took, conditionally, eight months. However, during this period we did a good refactoring of our code base, which is, in general, good. And now we can port it somewhere else.

Oleg: Tuling has already been mentioned, but is it possible in more detail? Debugging, tracing, profiling, that's all.

Andrei: In short, everything is bad. But there are small flashes of good things.

Well, the compiler is more or less settled: this is Emscripten (I'm talking about C ++, in other runtimes - Rust, Go, Kotlin / Native - differently).

Debugging: Firefox supports source maps, which is not bad in itself. Google Chrome just allows you to see the assembler code, you can put a stop point there, but it's so-so.

The profiler works better in Firefox, a bit worse in Chrome. The difference is that Firefox unwinds the names, that is, makes them as they are in the source code. Chrome shows mangane names, and you have to squint to understand what is there.

Oleg: How do people adapt from JavaScript to C ++ and vice versa?

Andrew: Probably, you can look at me here - initially the fender, which has now touched the native code. But to be honest, before the project I had a desire to try to pee something natively. So, probably, I am not very representative.

My colleague Yura, who acts in the project from C ++, and I talked a lot: he told me about the advantages, I told him about JavaScript. And he was interested in JavaScript. Coincidence is ten out of ten: does a native want javascript to learn when this happened? And we had a good team.

There is still a third person — this is Kolya, the architect, who generally looked at the assembler code and said: “Guys, you can debug here and so. Well, look, everything is clear: this is a stack machine, here we are working with memory, then arithmetic ... guys, why do we need source maps? ”Well, he can write under the embedded-system, in his free time he does it.

Oleg: Do you have any special surprises from C ++: from the language, from usability, working with it?

Andrei: Well, of course, I was ready for this. The most important surprise is that, having communicated with the pluses during the project, we realized that JS and C ++ have a lot in common. It would seem completely different languages, but you can find the point of intersection. On this topic, you can even make a separate report, you will need to think about it.

Evgeny: And now, after the one and the other, what do you want to write on?

Andrei: Actually, I'm not ready to write in production in C ++. I would do something for myself on it. Well, JavaScript - where does it go?

Oleg: What about the fact that C ++ is fast, and with a bunch of cool features like templates? Couldn't templates help in the frontend when writing any super standard code?

Andrei: There is such a joke: “if you have a problem and you want to solve it with a regular expression, then congratulations, you now have two problems”. I have a feeling that something similar with the templates. In our project, we try not to use templates, the architect is very resistant when C ++ developers try to implement something there. The problem arises with debugging: it is never clear where exactly it bahnul.

Oleg: So it is not clear what is happening in the code that has been generated? He can not build a source map to the source?

Andrew: As far as I know, even in native C ++ with templates, debugging is hard. When we drag it under WebAssembly, we will have debugging problems under WebAssembly. So I think it will be a hell. (looks at the camera attentively) Children, do not use C ++ templates!

Oleg: Without templates, it will turn into C. It will be possible to write on pure S.

Andrei: But what about the objects?

Oleg: Well ... "C with classes", yes. I just think that writing code in C with classes and idiomatic C ++ with templates are two completely different methods.

Andrei: Yes, it is possible.

Oleg: The philosophical question: don't you think that when WebAssembly is added to browsers, a portal opens to hell?

Andrei: Looks like it. Because now, probably, it will be fashionable to take any of the libraries or C ++ programs that have been written for the entire existence of C ++, try to compile it in the browser and see what happens. Today I showed the Windows 2000 demo in the browser.

Oleg: I mean, is this really full Windows 2000?

Andrew: Yes, this is the same Windows 2000, which was 18 years ago and which needed a whole computer to run - and now Chrome is enough for it.

Oleg: And what about the things that require kernel mode, is that all?

Andrei: She runs in the QEMU emulator, which was ported to WebAssembly personally by Fabrice Bellard (by QEMU). There, of course, you can not access the file system to the network. But this is Windows 2000, it starts up, scribbles, and everything is there. You can see.

Oleg: Let us turn to the topic of applications for Smart TV. By the way, can you do something interesting with WebAssembly?

Andrei: It would be possible if he was supported there. With smart TV, what's the problem? This development is like the development of the frontend ten years ago, because Smart TV is not updated. The man bought the TV, hung it on the wall, and it hangs there for years.

Oleg: But I always have there “wait, the firmware is loading.” Already enrages.

Andrei: The firmware may be loading, but, as far as I know, it does not directly update the system, the browser. As a result, we still support TVs many years ago, on which the browser is presented as Chrome 5.

Oleg: I do not even remember that.

Andrei: I do not remember either. Development for Smart TV, especially old ones, is a minefield similar to the frontend of the browser wars.

Oleg: So you had to make a super-cross-browser layout, which will work on both ancient and new versions?

Andrei: Yes. There, in fact, the problem is not so much with the layout as with JavaScript - API incompatibility, now I don’t remember everything.

Oleg: And what else from the browser available would you like to use on Smart TV, but not?

Andrei: A million things, starting with flexs (this is not even JavaScript) and ending with WebRTC. ByteFog uses WebRTC. How wonderful it would be if we dragged into Smart TV the code that we already have ...

Eugene: And besides the mentioned problem, developing for Smart TV - what is it like in general? What were the sensations?

Andrei: Sometimes there was a feeling that the developers of the Smart TV browsers did not like the programmers who were developing applications for Smart TV, because the debugging tools were very bad, they were almost nonexistent. This does not apply to modern platforms Tizen and webOS, they have done better. But I did it earlier, then there were old platforms, and everything was bad there. The best debugging tool was weinre, which is actually not a debugger - JavaScript cannot be stopped there; This is a port of Chrome DevTools, which works on web sockets. In general, it was possible to debug layout there, but practically nothing could be done with JavaScript. Somehow we lived.

Oleg: Why bother debugging at Smart TV itself, if you can run it in a browser?

Andrew: In the browser we have JavaScript and there is an API that gives us a browser. These are two different things. Similarly, on the TV we have JavaScript, we have an API from the browser engine ...

Oleg: Most likely, this is WebKit.

Andrei: Yes, as a rule. And there is another category of API - those that provides the platform of this TV. First of all, this is a player, then other options - remote control and so on. These APIs in the browser will not.

There are emulators, manufacturers actually provide them, but they do not fully correspond to the hardware. Therefore, it is not a fact that the debugged on the emulator will work on the TV. And vice versa: on the emulator it may not work, but on the TV it will be fine to run. So in the end we came to the conclusion that we do not use emulators, but try to debug on real hardware. It turns out faster: you do not waste time on bugs that are not.

Oleg: And how many platforms did you have to deal with, and over time they became smaller or larger?

Andrei: When I was working on Smart TV, there was a transition of manufacturers from the old operating systems, which were conditionally called Linux and were each with some kind of sauce, to the new ones. Then we had to write three different applications - for Samsung, LG and Panasonic. These applications, relatively speaking, copy-paste code. And then almost at the same time there are news that Samsung is switching to Tizen, LG to webOS, and Panasonic to Firefox OS (after that it did not survive, and Panasonic now has a fork).

In general, it would seem that everyone is changing the platform - why not converge on some one? This would be much better for everyone, especially for developers: there would be more software, users would get more useful programs. But no, we still write different applications.

Oleg: And can you somehow polish on all platforms?

Andrew: Well, in the end we came to a single framework, substitute platform-specific things and try to write cross-platform business logic. But it seems that this could have been avoided.

Oleg: Is there also an Android TV?

Andrew: There are, with two kinds. Before how did you do? Inserted the usual Android into the TV, and let it go. And then Google made a special branch of Android TV, better optimized for the D-Pad, that is, control from the remote. There are such TVs. But this is a separate story and a separate store.

And if in mobile devices Android won all and the most different manufacturers stopped on this OS, then with TVs at Google it was not possible to make it. Instead of all being limited to one platform, there were one more of them, like in the xkcd picture.



Eugene: I have a TV under Android TV with a 4K screen at home, but from the HDMI input it really takes 4K, but the built-in Android is 720p there. Why it happens? Since the TV by 4K standards budget, probably, the manufacturer has saved on iron?

Andrei: Yes, I think, here they rest against the fact that the operating system cannot render 4K-image on this hardware. In fact, this is a common situation when Smart TV (that is, the part on the TV that comes from applications) does not use full screen resolution. FullHD subsided to HD Ready, 4K - to FullHD or even to 720p. This is such an interesting moment when we cannot show 4K content on 4K TV, although we have both TV and content.

In general, TVs often crashes the interface - this, unfortunately, is the scourge of Smart TV platforms. And on Yandex.Market do not put a tick "TV, which will not slow down" and filter. Apparently, it remains to come to the store and choose there.

Oleg: And how does this affect the development of applications? If you add a lot of divs, does the application become slower and slower?

Andrei: Of course. If you need to render a large list, you have to pervert and render it not all, but in parts. We could have two hundred of them in the list of channels, and we could not render the list entirely - he then had brakes when scrolling.

I'm talking about the situation here a couple of years ago. On TVs that are released now, everything can be much better. But, again, people rarely change TVs.

Oleg: What do you think, what is the future of all that we see in Smart TV now?

Andrei: I am pessimistic. I hope my prediction is not justified, but we saw the decline of 3D technology on TVs, when all manufacturers said: “Okay, nobody buys it, it is not a key factor when choosing a device”. It seems that Smart TV can comprehend this fate, although I would not want to.

Oleg: And what then is the main pattern of using this thing, if you do not have a Smart TV? Get a big fat PC and stick it on the TV?

Andrew: Big computer, I think, no one will stick. Maybe the consoles will be the best choice, but the Smart TV and consoles have one thing in common: remote control. And to make good control from the console is very difficult. Sometimes they make joysticks with an accelerometer, that is, they implement gesture control, or emulate a mouse, but this is also far from ideal. In general, the problem with Smart TV is rather in the area of ​​UI / UX. In part, the television UX can be assisted by voice control - in Peers.TV it is supported by the user's smartphone, and now we are working on a special remote control with a microphone.

Eugene: Yes, I see that Google is also diligently leading TV in the direction of voice control. While this happens with varying success. But then let us end the conversation this way: let's hope that in some future our viewers will just say “run HolyJS broadcast for me”!

If you have any questions on reading about WebAssembly or Smart TV, ask them to Andrey in the comments.

We also note that the next HolyJS will be held in St. Petersburg on May 24-25 . Her program has not yet been announced, but there surely will also be a place for an “atypical javascript” that goes beyond the usual front end - and tickets gradually increase in price.