On Sunday, 21 June 2015 at 05:42:13 UTC, Joakim wrote:
No, I'm not arguing for pages at all, I'm saying that model is
dead and gone. I think the hyperlink was the killer feature of
the web, but everything else, HTML/CSS/JS, is just detritus
accumulated on top, that needs to be thrown away.
Thrown away in favour of what? You need a scene-graph / DOM. CSS
makes design much easier than the alternative. JS is evolving
into something close to TypeScript.
You can do some interesting things with caching, sure, but the
web frontend is still unwieldy and slow and round-trip latency
anytime you do something is what kills you.
You can prefetch data if you want. If you have a scrolling view
you can prefetch the next page-height worth of items. I do that
for images where I have to deal with thousands of images.
document format. You are always going to be constrained by the
architectural constraints and inefficiency of the document
format.
You don't have to use it. I use it because it is more productive
and more easily allows search engine indexing.
If you don't want it, you can use the HTML5 canvas and fill the
view with it. But why would you? You would have to do all the
layout manually and create a separate version for people using
assistive technologies.
You can do that if you want. Just download binary data and
plot it to a canvas.
The fact that I could render SVG images to a png and download
that instead doesn't excuse the fact that they're putting full
text SVG renderers into the browser.
You can just send paths as binary data to the client and draw to
HTML5 canvas if you want. No need to render on the server. Of
course, that also means that you have to deal with
resolution/zooming issues, and it also means that you may have to
wait with the graphics till the whole DOM has loaded. Which is
another issue that embedded SVG solves.
I wouldn't mind an improved version of SVG with LOD support etc,
but I think that would be a different concept. SVG is perfectly
fine for embedded CSS styled line-art (which I use it for). You
can bundle HTML/CSS/JS/SVG in one file and have very responsive
websites if you wish (one file download).
Of course you could use binary SVG dynamically: you'd simply
need the right hooks in the browser and in the binary format to
manipulate it using javascript. It would not require
"binary-format editors" or "binary HTML."
No, because I typically write the fragments for the SVG as text
then programatically modify parts of the SVG. Or, I just attach
event-listeners to parts of the SVG. Not having HTML and SVG in
the same source would be very confusing.
I would have preferred something closer to Microsoft VML which
made the vector-graphics part of HTML so that you could just
insert a circle anywhere on the screen. But I guess the SVG clip
rectangle made implementation of the renderer a lot easier.
