4 ms·

Does this eventually end up as yet another virtualization layer? How big and bloated does the web stack become before we start again, with a lean protocol and m

Does this eventually end up as yet another virtualization layer? How big and bloated does the web stack become before we start again, with a lean protocol and markup language for text documents?

creshal 11y ago
Markdown over Gopher? Yes please.
dspillett 11y ago
The lean protocol and markup language will still be there to use though. This just gives us a new tool that is right for a different set of jobs and hopefully integrates well with the other parts when needed.
- creshal 11y ago
  Assuming HTTP and HTML ever qualified as "lean".
  - dspillett 11y ago
    Fair point. CSS too. But they are leaner than piles of javascript which is in turn leaner (at least from a dev stack point of view) than a full compilation stack and process. We have quite a range of useful options for our needs now: * Plain text. Sometimes it is all you need. Just server text/plain via HTTP and be done. Add markdown or similar as you see fit. * HTML+CSS for most occasions because you want to add at least a little style. * Add in a little JS when you need some basic interactivity or because you are presenting a lot of information and the option to hide/collapse some of it is useful to the user. * Add a lot of JS and libraries once you are getting into proper "application" territory rather than just a fancy page of information. * Start compiling form other languages when for your project needs some constructs not available or easily emulatable. * Start considering WebAssembly when your project really really needs the performance gains possible over JIT compiled JS (or you want the binary format for obfuscation purposes) None of those options invalidates the ones before it, so it really does come down to having a good selection of tools and picking the right one for the job. The fact it is all cross-platform (at least it is if you ignore "legacy" browsers like IE6 and Android 2.3.x, don't mind using less efficient polyfills for the not-quite-legacy-yet options, and are careful to remain compatible with a range of screen sizes and (once you introduce interactivity) input methods) and the big names appear to be playing nice enough is icing on the cake. I think we are living in good times in this respect.
cpeterso 11y ago
WebAssembly will have a backwards JS polyfill, but browsers could implement WebAssembly natively and gut the JS middle layer. Mozilla (and then Microsoft and Apple) did the same thing with asm.js. WebAssembly becomes the unifying abstraction layer instead of JS.
- creshal 11y ago
  > WebAssembly becomes the unifying abstraction layer instead of JS. I wonder how long it'll take until browsers implement JS in WebAssembly, to make it easier to maintain/upgrade.
slowmotiony 11y ago
Let's ditch HTML/CSS for XAML! No more googling how to vertically align a block in another block. I'm in 100%.
- M8 11y ago
  That would be a dream.
- Aldo_MX 11y ago
  Flexbox

Does this eventually end up as yet another virtualization layer? How big and bloated does the web stack become before we start again, with a lean protocol and markup language for text documents?

creshal 11y ago

Markdown over Gopher? Yes please.

dspillett 11y ago

The lean protocol and markup language will still be there to use though. This just gives us a new tool that is right for a different set of jobs and hopefully integrates well with the other parts when needed.

creshal 11y ago
Assuming HTTP and HTML ever qualified as "lean".
- dspillett 11y ago
  Fair point. CSS too. But they are leaner than piles of javascript which is in turn leaner (at least from a dev stack point of view) than a full compilation stack and process. We have quite a range of useful options for our needs now: * Plain text. Sometimes it is all you need. Just server text/plain via HTTP and be done. Add markdown or similar as you see fit. * HTML+CSS for most occasions because you want to add at least a little style. * Add in a little JS when you need some basic interactivity or because you are presenting a lot of information and the option to hide/collapse some of it is useful to the user. * Add a lot of JS and libraries once you are getting into proper "application" territory rather than just a fancy page of information. * Start compiling form other languages when for your project needs some constructs not available or easily emulatable. * Start considering WebAssembly when your project really really needs the performance gains possible over JIT compiled JS (or you want the binary format for obfuscation purposes) None of those options invalidates the ones before it, so it really does come down to having a good selection of tools and picking the right one for the job. The fact it is all cross-platform (at least it is if you ignore "legacy" browsers like IE6 and Android 2.3.x, don't mind using less efficient polyfills for the not-quite-legacy-yet options, and are careful to remain compatible with a range of screen sizes and (once you introduce interactivity) input methods) and the big names appear to be playing nice enough is icing on the cake. I think we are living in good times in this respect.

cpeterso 11y ago

WebAssembly will have a backwards JS polyfill, but browsers could implement WebAssembly natively and gut the JS middle layer. Mozilla (and then Microsoft and Apple) did the same thing with asm.js. WebAssembly becomes the unifying abstraction layer instead of JS.

creshal 11y ago
> WebAssembly becomes the unifying abstraction layer instead of JS. I wonder how long it'll take until browsers implement JS in WebAssembly, to make it easier to maintain/upgrade.

slowmotiony 11y ago

Let's ditch HTML/CSS for XAML! No more googling how to vertically align a block in another block. I'm in 100%.

M8 11y ago
That would be a dream.
Aldo_MX 11y ago
Flexbox