Ask HN: What is the future of back-end development?

I unfortunately don't have the specifics myself, but this would be the perfect point for someone else to chime in about DOM manipulation speed and the other various sources of browser overhead. I know they're nonzero myself.

WebAssembly won't turn the browser into a "perfect" runtime. Things will still be glitchy and slow and buggy and stuff, like they are today. Except now there will be multiple WA implementations, with low-level bugs 99% of webdevs won't be able to debug... :D

It may be helpful to see WA as a W3C-ratified JVM (Java VM) for your browser: like the JVM, WA is bytecode-based, and like the JVM, WA will be targetable from many languages.

You might even compare it to JVM + Swing - where WA is the JVM, and the DOM (and all other related bits) are like Swing. (Swing is notorious for being slow, although it's recently a lot faster.)

I think client-side will "break though" in the way you describe when there's something that bridges the (relative) ease-of-use of the DOM and the performance/accelerability of WebGL. I doubt that will happen soon though, considering the cementedness of HTML+CSS and the associated investment (eg full-stack CSS3 hardware accel).

-

I don't have a clear picture of the backend side of things at the moment, but I can offer these comments:

You've probably heard of WebTorrent. WebTorrent is not BitTorrent, because WebRTC P2P channels use SCTP on top of DTLS, which is effectively UDP on the wire. Besides being a headache for sysadmins who manage deep-packet-inspecting proxies, this essentially isolates the Web as its own "network" in practice - the only way you can talk to servers is via TCP+HTTP or UDP+DTLS+SCTP+. This makes things somewhat difficult. WebTorrent is actually a fully independent network that uses SCTP instead of TCP or UDP - the protocol is the same, it's just tacked on top of SCTP (& co). I expect (or at least hope!) that in a couple years next year most BitTorrent clients will have WebTorrent support.

There's also the fact that mobile networks are notorious at handling "unusual" data, because cellular data gets mangled by lots of pesky/fussy infrastructure as it bounces between your device and what might be considered the "traditional" Internet backbone. I've heard UDP is touch-and-go, for example, or even access to unusual ports. There's also the well-known fact that radio dropouts are still common and fundamentally hard to fix, even in 1st-world areas. This makes peer-to-peer networking incredibly hard.

A relay-as-a-service system to handle issues like these (SCTP->TCP gateway; connection persistence (very hard); etc) would make for an excellent DDoS generator, so at this point these types of things would need to be fixed at the application level, on a case-by-case basis. Unfortunately.

For another example consider Skype, which recently switched to an entirely client-server model, wherein the client talks solely to Microsoft servers; in the old days if the Skype client decided you had an awesome CPU/RAM and network and your NAT config was sane, it made you a supernode for clients who didn't have working NAT. Yup. Ref: "skype supernode", also http://www.zdnet.com/article/skype-ditched-peer-to-peer-supe...

There's also the fact that it's not (yet) possible to cleanly and reliably detect what kind of connection you're using on all OS platforms, so the old supernode system might decide your flaky home 3Mbps DSL connection isn't supernode material, but once you switched your laptop from Wi-Fi to your $5/MB 100Mbps 4GX connection, suddenly your uplink would look perfect for servicing all 100 clients that appeared to be geographically nearby... :D - and all P2P systems suffer from issues like these.

In short, federated, distributed peer-to-peer applications aren't quite there yet, and I expect WebAssembly is one of those technologies that will probably take enough time to mature that you'll have plenty of time to figure out where it's headed and position yourself appropriately.

I seem to be doing a lot more "mashup" work than ever before, joining up disparate back end systems in order to hide it all behind a simple modern front end. In the past if I was developing an order processing system I would work on the view/UI side of things as well, now I expose the functionality via an API and let the front end guys develop a nice interface for it all.

Also lets not forget you don't actually want any mission critical, confidential or security stuff happening on the front end no matter how WebAssembly gets.

There will always be a backend.