Building Better Interfaces with SVG (2015) | Hacker News Reader

Building Better Interfaces with SVG (2015)

slides.com

429 pointsstesch106 comments

Having spent the last 3 years building complex visualisations with SVG, the biggest drawbacks I found are:

- Poor optimisation. Browsers have done a lot to speed up HTML + CSS rendering via the GPU, and you can you use WebGL to make canvas fast. SVG seems to have been neglected in comparison.

- No layout management. HTML + CSS isn't perfect in this regard, but you still get blocks + inline text, floats, absolute positioning, tables and flexbox (and soon, grids). In SVG, you get absolute positioning, and that's it. If you want to do any kind of complex layout, you have to calculate everything yourself in script.

I'm not sure the major browser vendors really care too much about SVG. Compare the huge advances made in other areas of the web platform with the years-long, incredibly unambitious SVG 2 specification process.

It's a real shame as as this presentation shows, you can do some incredible stuff with SVG. But it could be so much more if there was just a bit more effort invested.

Let's do something about it. I'm done with HTML+CSS.

Also what about editors? In my experience writing graphics this way (via XML files) scares off 95% of the artists. Programmers can do it, but they make crap art. A designer who is good/interested enough in doing these is very rare.

So unless there is excellent support (can make animations, generates nice code,..) by Adobe products it wont catch on.

Adobe Illustrator exports to SVG.

https://helpx.adobe.com/illustrator/how-to/export-svg.html

And how good is it? Does anyone knows examples/has done some serious work in it?

For what it's worth the SVGs exported by Sketch are workable. I usually go in by hand and clean up the exports, but it's nowhere near as bad as old dreamweaver html exports.

I've had the opposite experience. Exports from sketch have the potential to be way off the canvas. This page has helped quite a bit: https://medium.com/sketch-app-sources/exploring-ways-to-expo...

I routinely use Illustrator for fairly complex SVGs that are subsequently included in web pages, and the code is pretty serviceable. SVGO will clean it up a lot, but usually to the point of make it much hard to hand-tune.

In my experience the exported SVGs from Illustrator can be pretty noisey.

I do frontend web dev in a big, mixed-media advertising agency. The logo's that we design for clients are created in Illustrator so they can scale to billboards or banner ads. The psd's that I receive for websites often contain icons done in illustrator. Exporting to svg is easy to do but yields code that is messy in the way that exporting a Word document to html is. It works but I'm not going to edit the code.

dealing with `id="Layer1"` is annoying, but trivial. The endless nested `<g>` elements can be deleted. I've heard it's gotten better (I've neglected to ask for an update from CS6 for the past 2 years.

What is absolutely terrible is dealing with SVGs exported from Sketch. And that's all our UX/UI/Designers use these days.

For what it is worth, Illustrator CC got an update on one of the .x versions (17.2?) that brought "Export SVG to Web" option that produces web quality SVGs (maybe SVGO exported even?), a huge improvement over the old Save As SVG route.

I think artists and prgrammers ahve more in common than you think, so does pg . . . he even wrote a book about it—

Hackers and Painters: http://paulgraham.com/hp.html

It's less of an issue for visualisations, as if a designer creates a mock-up, it's only used as a guide for implementation by a programmer, rather than an actual asset.

However we have used Sketch's SVG export for things like icons, and I've found it to be pretty good. There's even an CLI export tool than you can integrate into your build process.

Most vector tools export to SVG, and you can use SVGO[1] to clean it up and optimize it.

1: https://github.com/svg/svgo

SVGO is interesting. One of my biggest complaints over the years has been that most tools that export to SVG do it in such a way that the file is so difficult to understand and edit that the results are useless.

Use https://inkscape.org/

https://github.com/artursapek/mondrian

Inkscape is a good vector editor and works with SVG.

unless you're on a mac, where it's too slow and buggy for any "real work".

Mac is too slow in general for any CPU / RAM intensive work. Use Linux with better hardware in such case.

Is it worth investing that effort, though? WebAssembly has entered its public alpha on multiple browsers and is coming a long way. It'll make WebGL easier to use and will probably give rise to other graphical UI APIs that run directly in the browser. Does SVG still have a place in a WebAssembly world?

I dont think that many websites will be made in webassembly. Its more made for full webapps and games.

CSS/SVG is used for websites.

That's a great point. I bet WebAssembly will result in an altogether next generation of technology given what we want to achieve today, not what we wanted to achieve in the early 1990s. But I have a feeling svg will have a big roll to play, and not only as inspiration either.

I don't know, but I really, really don't hope we get to the point where every web application ships a bespoke, WebAssembly rendering engine and treats the browser as WebGL dumb terminal. That sounds like a complete dystopia.

Think loading times are bad on script-heavy websites now? Wait until every web app uses its own mix of graphics, font and layout libraries, all compiled from C/C++ to WebAssembly and shipped in a 100MB blob. And rendered without any integration with accessibility technologies, and with basic things like copy and paste disabled to stop you "stealing" content. No thanks.

That's probably going to happen anyway. Just sayin'.

That'll be the first step. Then people will notice all those crazy download times, and someone will figure out that things could be better if they could write a single reusable "container" app in WebAssembly and WebGL that could host nearly arbitrary content, described in some kind of high-level markup language that's reasonably concise...

SVG markdown

It costs more to employ C/C++ developers than Javascript/HTML/CSS developers, so people are not going to recreate everything with bespoke C/C++.

Neither WebAss, nor WebGL (nor the canvas API for that matter) is a vector graphics format. When using WebGL, you still need a way to integrate complex prepared graphic content. You could implement an SVG renderer in WebGL + JavaScript I guess, but that's certainly not easier than just using SVG content straight away.

SVG 2 leaves the "painter model" behind (where z-order is determined by document order of the respective shape within its container) in favour of the z-index CSS property, so that you can address it in CSS (eg. `:selected { z-index: 1 }`). This makes it possible to describe things like interactive maps and DVD-like menus where when you click on a shape, the shape gets scaled or applied some other transform for highlighting.

However, I agree that SVG 2 leaves a bit to be desired (for example, level of detail properties). Also, animation of SVG in FF sucks compared to Chrome and Safari, or at least it used to 3 years ago. I wanted to teach my 12-year old how to make a simple browser game, but had to resort to hackish workarounds to make it run smoothly on top of using rAF etc., ruining my pedagogical ambitions.

> Also, animation of SVG in FF sucks compared to Chrome and Safari, or at least it used to 3 years ago.

I can relate to this, I use to work on a svg-heavy project in 2014 and I had the same kind of issues and I filed many bugs on FF bug tracker .

Fortunately, they've all been fixed by the mid of 2015. I don't work with svg so I don't know if everything works well now, but at least there were improvements.

Given that we see more and more desktop applications being built with web technologies (formerly with node-webkit and recently with electron), and new UI toolkit are not really popular projects right now, I really doubt that many people will develop/use a brand new UI toolkit built on top of wasm and webGL.

Time will tell though.

I've also spent the last 3 years doing a lot of svg work. The experience is really enjoyable for me, as a coder it's great to know what's going on and make things work using maths.

My work involves working with huge svg documents (up to 500k Dom nodes) with a relatively well defined structure so there are lots of bits of svg that I'm less familiar with. Because I'm fairly sensitive to performance issues I've seen the work that goes on there and you're right, it's second class compared to html but there's still development happening.

The layout management is definitely substandard. It's a bit of a kludge but you can use foreignobject to put HTML inside svg and do the layout there. On paper it doesn't look too bad [0] but YMMV and I haven't played with it myself.

All in all I'd like to see more activity in the svg space. It's a great tool and with a bit more awareness I think it could have a great future in the web development world.

[0] https://jsfiddle.net/leaverou/qwg3r/

"using maths". that sounds like an entirely different solution than building interfaces, which is what this presentation was about. The example you cited with 500K DOM nodes.. Really? How as the browser performance? Why not just convert to canvas at that high level of DOM elements?

It is different but I guess my point was that SVG is a brilliant tool for developers. We (generally) approach problems in a programatic way, and SVG allows you to do that for graphics, which is incredibly liberating.

Performance is good! I've definitely had to come up with some pretty clever hacks but it feels smooth once the SVG has loaded. In our case we need to be able to zoom in to arbitrary levels and still have crisp vectors.

Here's an example of a document with about 150,000 dom nodes. You'll see that it's a little sluggish when you're zooming in and out but after it catches up it's really quick to move around. Most of our documents are much smaller than this so there's no real delay on zoom in those cases.

https://dl.dropboxusercontent.com/u/233998/example_movement....

is it suppose to be device agnostic? I'm on a core i7 device so it's not a good indicator of how performant a given web solution is.

Generally speaking when you have that many elements, you've surpassed the threshold of what SVG is intended to do. Canvas can be a seamless replacement for SVG without any tradeoffs, other than additional build complexity

The problem with canvas is that our users need to be able to zoom very deep and still have crisp rendering. We wouldn't get that with canvas unless we rendered to a really huge canvas, right?

Yeah, the machine is definitely going to make a difference, though as I say a) most our documents are smaller than this and b) we have ways of speeding up bigger documents where required.

Sure, SVG isn't made for this, but it works. Going to canvas would mean a load of extra work and you can be sure there would be other tradeoffs and issues to work around. Additionally, SVG is super hackable. You can work with it easily front and back end. You can read it and understand what's going on.

And hey, if your users are happy.... :-)

http://www.capterra.com/takeoff-software/spotlight/144811/Co...

i think you can redraw the canvas when zooming in. So even if the canvas dimension is finite, you can redraw it with infinitely higher resolutions of data.

I get the idea, but then I'll be doing the work that the SVG engine is currently doing. So really, here you're trying to get canvas to do something that it wasn't designed to do - which is weird, because that was your argument against svg in the first place. A quick google reveals the general solution of "sounds like you should be using svg." [0]

Given that svg 100% works for my usecase, I don't have any reason to attempt anything else at the moment. People give svg a hard time about performance and I think that's counterproductive. My suggestion is that everyone should give it more of an honest shot and I suspect they'll find that there are plenty of cases when it becomes the first tool they reach for.

[0] http://stackoverflow.com/questions/19284304/how-redraw-on-ca...

I often use other elements for layout and set their background image to an SVG. Benefit of both worlds there. Does that help with any use case?

We've experimented with this, and it can help, but it's not a silver bullet. For example, we had a stacked bar chart where we used a horizontal flexbox for the core of the chart. Each entry in the flexbox was a separate SVG. This let use do nice things like set a minimum size for each bar and have the chart overflow and scroll if there wasn't enough space to draw all the bars.

But then we got a requirement to overlay a line chart on the bars. And that meant layering a separate SVG on top, and doing a bunch of script work to make sure everything lined up correctly. E.g. detecting when the window resized, or when the content overflowed, etc.

It worked, but the resulting code is not at all fun to work with. The frustrating thing is the that the layout is trivial in pure HTML + CSS, and the graphics are trivial in pure SVG. But neither has the complete story, and so you end up having to jump through so many hoops, when it feels like it could be so much easier.

I wonder if you can use Facebook's JS flexbox implementation to do the layout calculations for you:

https://github.com/facebook/yoga

I think the question is whether you can do it performantly. Adding that overhead to your client JS feels like it would be a drag.

I found tools like http://editor.method.ac/ incredibly helpful with editing and positioning SVG elements.

> In SVG, you get absolute positioning, and that's it. If you want to do any kind of complex layout, you have to calculate everything yourself in script.

Depends on what you mean by absolute. The current transformation matrix (CTM) in each group hierarchy is computed relative to the parent element.

I have no horse in the SVG vs. CSS race, but: Web designers, please, do not think that all the super-annoying gimmicky animations (rippling text inputs, wiggly text, excessively stretch-and-squashing motion) are a positive for user experience.

It might be fine for showing technical flexibility, but they do not add to interaction; they are distracting, slow down responsiveness, and worse, are non-standard and unexpected. I hope this kind of stuff doesn't catch on.

all the super-annoying gimmicky animations (rippling text inputs, wiggly text, excessively stretch-and-squashing motion)

I like to call this trend "Flanders Computing" -- where developers and designers increasingly create obnoxiously friendly websites and apps that treat you as if they're your diddly-doodly buddy-ol-pal.

A recent Windows 10 install told me "We're happy you're here!" Who exactly is "we" and why are they trying to be all buddy-buddy so soon? I assume the market research told them that this was the best start screen, but good grief is all the wiggly-wobbly buddy-ol-pal stuff so friggin annoying. It's like forced intimacy that can't be reciprocated, which feels weird.

AKA Genuine People Personalities as predicted in Hitchhiker's Guide.

http://webcomicname.tumblr.com/post/154211839894

This needs to develop into a grading system. A "Flanders Threshold" or something.

Hey cha-cho, thanks for reaching out.

Love your idea for the Flanders Threshold. Hit me up any time at john@cheesierthanaripecamembert.com and tell me what you need. I'll be more than happy to help.

Looking forward to making magic with you on the Flanders Threshold, cha-cho!

Best,

John

CEO/Sales/Customer Support*

Cheesier Than A Ripe Camembert, Inc.

(Every time I get a mail like this from some trendy tech firm, I die a little inside, but somewhere in the past year or two I think they all read the same book and now they're all doing it.)

Similarly, when I sign into slack at work, I am presented with silly little messages from my "friends at slack". Why is the empty set writing me messages? The people who work on slack are probably nice, but I don't use the "friend" label on people who I've never met.

You can configure those messages. We've set them to be hilarious things our team has said over our time together. I rather enjoy it.

Re: Windows 10, it scared me so much the first time after a bigger update with the "Hi / We've updated your computer" type splash screen. "FUCK did it just reformat everything??"

"Hi, we've updated your computer. Pray we do not update it any further."

I also experienced that moment of "oh shit!". I've rarely used Windows in my life, but when I have, when Windows blanks the display and pops up something like that and isn't booting, it's historically something scary.

Not to mention "Don't worry, everything is where you left it" which I've had a few times when booting up. And the slow fade in makes it even creepier.

Yeah, that message made me nervous. "We didn't touch your stuff...this time."

Please this. Between JS/image/font bloat and CSS animations/transitions, the web keeps feeling slower every year.

I have clients who demand things like this and can't be talked out of it. It is quite depressing how often a half-decent site gets wrecked by a stubborn client.

I'm not a fan of the ripple animation in Material Design when you click...it's way too distracting for such a common interaction in my opinion.

Not to mention it's incredibly expensive, since it's neither SVG nor CSS. On Firefox in a large webapp it will peg a core at 100% for several hundred ms, because it modifies the DOM to add "waves" and then resizes them on every animation frame.

As a front end developer with practical sentiments when approaching a solution, this was the first thing that came to mind. This presentation was entirely unconvincing in the useless examples that do not highlight practical benefits of svg over css. It does nothing to dispel the obscure nature of svg relative to css.

Many of animations are superfluous, but those that indicate state changes and especially spatial changes are useful. I think that some of the stretching-squashing motions can be pretty good. Especially on mobile, animation can give answers to two questions: how did I get here, and, how do I get back again

I don't know. All these examples from the OP with bouncy animations are much too busy for me, and make the application/website feel childish.

I think Google's Material Design strikes a good balance regarding use of animations. They sometimes have very elaborate animations, but usually in very small areas where the animation becomes an easteregg rather than an annoyance. (For example, how the hamburger menu icon transforms into the back-arrow and vice versa. Or, on the Android notification panel, how the cogwheel rolls away as it fades out. That's cute.)

Here is the actual talk: https://www.youtube.com/watch?v=lMFfTRiipOQ

We started replacing all of our SaaS application icons (Font-Awesome & entypo) to customized versions of the nucleoapp icon set. SVG is incredibly powerful and flexible. We're able to do a lot of cool and unique stuff without much CSS code or gifs. The ability to control multiple layers of a specific svg icon or element is really cool, and makes it quite easy to build unique interfaces. We even started using svg on our website for the features section. A tiny ~ 2KB img/icon can be scaled to work on any device or any resolution and look very crisp.

It can be time consuming at the beginning, but once you get the hang of it, you won't use anything else.

For anyone who is a web hacker rather than a designer, I highly suggest trying out SVG here and there in your web projects. SVG is a fantastic bridge for anyone who wants to put some graphics (dynamic or otherwise) in place, is used to just having copy as content, and/or is a bit afraid of opening PS/Gimp.

I'll second that. I converted a script that rendered images with Tk's canvas over to Cairo. Cairo's SVG output converts text to curves which makes embedded hyperlinks impractical. I added direct conversion to SVG and got nice results in short order.

The big problem when doing layouts for SVG outside of a browser is determining the bounding box for text. The best I can do is get a box from Pango and hope browsers render text close to the same way.

Ah ha haaaa...I've spent a lot of time on this this week. I currently render the text inside phantom (headless chrome) so I can correct the positions. Do you have an example of using pango?

(Ps, I now know the murky details of exactly how Firefox, chrome and Inkscape calculate their bounding box and clientBoundingRect, which is sort of sad but just the life of a coder I guess)

I think my biggest issue was(/is? ..and please reply if anyone knows a decent way around this) using an SVG icon is great - scalable, small, etc., but if you want full control over it in the CSS (for fills, outlines, hovers) you have to inline the SVG. If you're using it as part of the navigation or whatever, you have to load it over and over on every page.

It would be amazing to be able to load an SVG icon as an image with a class, and then be able to use CSS to manipulate the image (change the colour etc) but know the image is cached by the browser.

You may be interested in this then: https://gist.github.com/Bloggerschmidt/61beeca2cce94a70c9df

If you inline using JS, you can use standard styling / classes to modify the display. Since it happens via standard browser requests, you get normal caching behaviour. One bad thing though is that you have to wait for the JS to execute, so there may be some blinking.

One way to do it is to have an external file with all your svg data that you append to the dom afterwards. Wherever you want to use a svg, just reference the appended svgs:

    <svg><use xlink:href='#svg-id'></use></svg>

Here's a quick example I threw together: http://syd.jjcm.org/svgCacheTest

If you click on the folder icon you can see it being changed by the css.

Thanks for posting this - I had been running into the same issues above.

Interesting, thanks. Alas I think this solution still has its drawbacks in that you can't target classes within the SVG. Example: https://css-tricks.com/svg-use-with-external-reference-take-...

I guess you could probably turn the svg into a font and style it with css.

I bet you could do some kludgey stuff to get it to load. An idea that springs to mind is to include your svg as an image in the page (but hidden, like a sprite map) and then use the 'use' tag referencing ids in the hidden image wherever you wanted to place the sprites.

Either way, you currently have to work around a (seemingly arbitrary) restriction with browsers not allowing CSS on svg images.

Shameless plug:

ImageTracer is a simple raster image tracer and vectorizer, 100% free, Public Domain.

Available in JavaScript (works both in the browser and with Node.js), "desktop" Java and "Android" Java:

https://github.com/jankovicsandras/imagetracerjs

https://github.com/jankovicsandras/imagetracerjava

https://github.com/jankovicsandras/imagetracerandroid

So "Write Once, Run Anywhere" has become "Write Once, Commit to Two Repos"?

there is also https://github.com/parametric-svg that could be helpful for more delcarative layout that doesnt need a bunch of hand-coded JS

This slide deck blew me away -- thanks for posting. I didn't even know these kinds of things were possible with SVG.

Was particularly enamored with slide 41: http://slides.com/sarasoueidan/building-better-interfaces-wi...

I think most of the animations on that slide are not-distracting, and intuitive UI elements (except the chat box on the right).

The chatbox on the right is outrageous. "The other person is typing" should never be allowed to have this huge and distracting of an animation.

I picture myself typing this on my phone, letting it rest on the desk unlocked while continuing to read HN, but finding myself constantly disturbed by these bouncing waterdrops in my peripheral vision.

Yeah... that was the only interaction I thought was insane.

But I'm also against read receipts and showing when the other person is typing at all, so I figured maybe this is what people are into these days

I won't argue against read receipts and typing notifications in general as far as UX goes (I understand the privacy problems, but that's another thing). It's a very basic equivalent of body language for text chat.

Just a big caveat for slide #36:

> SVG text is fully accessible, searchable, selectable and 100% semantic.

Only if you don't convert the text to paths, which is really really common in the wild because someone wants a specific font or text positioning. Supposedly you can create invisible text for that purpose but I've only seen it once in a real SVG.

I've been trying to switch from icon fonts to SVG for icons, but I'm struggling with productivity/maintainability:

- SVG icons are more complicated to drop in, or complicate the code. For icon fonts it's usually just a CSS class, which is lean and expressive. For SVG, either I drop in the explicit code, which can be huge and hard to read, or I include it as external file (like an image) and lose CSS styling abilities.

- Versioning is harder. SVG icons are usually present as files, either from a thrid-party set or created and maintained using editors like inkscape. Now I either copy the code for above styling advantages, which is obviously bad for consistency, or I reference them as external images and lose stlying power again.

Are there any good workaround for those issues?

i'm writing a web-based crossword app using svg for the grid, and it's a great experience. i got the basic idea by examining the source of the guardian interactive crossword [https://www.theguardian.com/crosswords/cryptic/27089 e.g.] which is very clean and readable.

So, ctrl-f for d3 yielded no results in an article about SVG...

If you want to make impressive visualizations in very little code, I suggest you look at d3js. Here's the start of a series of fantastic tutorials done by Mike Bostock, founder of d3: https://bl.ocks.org/mbostock/3808218

I'd suggest you try that example out in http://blockbuilder.org/. I have no affiliation but it makes playing with d3 easy. After that, peruse the articles on the third example, find cool examples on bl.ocks.org, and replicate them.

A few things to note starting out(I've been learning d3 lately):

- v4 was a breaking change from v3, some v3 examples may not work out of the box but mostly will. If the >1MB bundle size of v3 scared you away, v4 is all es6 modules so you pay for what you use.

- the data model is enter-update-exit, its elegant but can take some time to understand.

- d3 looks procedural at first but is actually declarative if you follow the idioms.

- if your code keeps adding elements when it shouldn't, you probably messed up either a select/selectAll somewhere or forgot to add a class/id to the element when creating it.

- using typescript with d3 feels great but there are some gotchas; if you're interested, let me know and I'll write a blog post.

I do realize the slides are about interfaces with svg, so d3 may not be exactly what you want but damn if it isn't worth mentioning here.

Yes, there was indeed a slide on D3.

> using typescript with d3 feels great but there are some gotchas; if you're interested, let me know and I'll write a blog post.

This would be extremely interesting and useful. Please do write your thoughts about it. Thanks.

Info on typescript+d3 would be really nice. With the large scope of d3, a little auto-complete would go a long way for a beginner like me.

Does SVG still murder battery life on mobile phones?

I don't get the SVG vs. CSS slant of this. I always use CSS with SVG. So it not "SVN or CSS" it "SVG and CSS".

In the slides where this talks about the SVG way and the CSS way - I don't know enough about either to verify if its true, but are these approaches inherent in these choices? That seems awfully suspicious/disingenuous to me but perhaps it really is a fair portrayal?

How do people make SVGs these days? Inkscape? By hand? A combination?

All of the major professional vector applications export SVG, including Adobe Illustrator, Affinity Designer, and Sketch. As for animation and some of the more exotic filters, though, those usually have to be added by hand.

I use Gravit.io (Twitter templates) for fast work.

Gawd, most of the rationale provided are superficial effects that have entirely arbitrary value for most Web projects.

The claim of svg being semantic is laughable when i see one of the examples leverages the "d" attribute of an svg element.

Anyone doing work with d3 is eminently appreciative of the abstraction it provides for working with svg. There isn't an analog for working with css

The CSS heart on slide 9 looks perfect for me, while the SVG heart is blocky and not fully contained in the white box.

Google Chrome 54.0.2840.100 (64-bit Ubuntu)

http://slides.com/sarasoueidan/building-better-interfaces-wi...

Sometimes it seems to me, that Sara and Mike (D3) are the only people who talk about SVG.

And Mike seems to have a rather practical approach, while Sara is the only SVG evangelist out there.

I like her stuff, it's sad that SVG doesn't get more love.

Adobe could have made Flash just export to SVG and saved it. But heck, everyone knew it was dead the second Macromedia was bought.

SVG certainly has its uses, but I can't trust all the clever filtering stuff after seeing even modern, high-spec PCs literally crashed with relatively simple effects just by trying to draw the SVG in a browser. Something about certain browser rendering, or maybe the underlying Windows graphics APIs or someone's card drivers, just isn't stable or robust in this area, in my experience.

How does this work with respect to fallbacks and accessibility, especially for form elements?

What is the story on accessibility for SVG? Can blind people use it? That's a pretty small market, but one that you are required by law to support. A MUCH MUCH larger market is people with parkinsons like diseases who have trouble clicking on things and need to be able to tab through the elements with a keyboard... How does that work here. What is the tab order? Even if it is supported, is the tab order sane or insane?

https://www.w3.org/TR/SVG-access/#Links

Done properly, should work great.

Cool!

From 2015. Still awesome.

just cant wait until we can compile real programming languages down into web assembly, and the whole "front end" debacle can DIAF :)

Reply on news.ycombinator.com