Hacker News new | past | comments | ask | show | jobs | submit login

I have most reason to doubt 8. I think it'll mature, but I doubt a fully "standard" stack will come about.

I suspect WASM will lead to a lot less stuff being done in JS.




I'd rather bet that react/the react ecosystem will be have a >60% share than WASM being extremely common.


There's a bit of a push to get everything that isn't rendering out of the render thread, and if you're going to do a bunch of logic in a web worker I guess it isn't a big jump to do it in Go/Rust/whatever.

I agree with your intuition, though -- I don't think it'll become too widespread. Projects will start in all-js in the front-end, and no language will provide sufficient benefit to motivate rewriting half of the client.

I'm less sure about back-end development trends but I think "less standardised than the front-end" is a gimme. Maybe Node/Express or similar will pick up, but I feel like they've been waning the last few years. Go servers seem trendier.


I’m optimistic about Elm or something like Elm that represents a minimal core of today’s emerging best practices (virtual DOM, static types, functional core & imperative shell) while cutting off the fat (mutability, type coercion) and providing valuable affordances and guarantees (educational compiler messages, no runtime exceptions.)


Why?


WASM does not fix DOM manipulation, so…


You can render using WebGL so you don't need DOM manipulation, any UI library in any language will do. The advantage to this method is that you are no longer limited by browsers slow and inconsistent DOM implementation, you can just make your own.


And create an accessibility nightmare.


Everything is an accessibility nightmare until somebody creates accessibility tools for it


That has yet to hinder web developers.


Like Flash with even less consistency? I hope not.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: