On Sunday, 21 June 2015 at 06:20:53 UTC, Ola Fosheim Grøstad
wrote:
Thrown away in favour of what?
As I said before, start from scratch. Stop trying to shoehorn a
full app runtime into the browser because you will only lose to
native app runtimes, which is already happening because they
aren't constrained by such legacy decisions as an archaic
document format.
If you want to build an app runtime that has hyperlinks built in,
like the web does, start from a clean sheet and really think
about how you want to do it. Simply dumping more features on top
of the old web stack is a recipe for failure.
You need a scene-graph / DOM.
Not really, certainly not the latter if you chuck HTML/CSS/JS.
CSS makes design much easier than the alternative.
Only if the alternative is web design circa 1995. Once you chuck
HTML, CSS has no reason to stick around.
JS is evolving into something close to TypeScript.
You've got to be joking: why would anyone want to use either? On
the server, where you could use anything you want and there is
real competition, almost nobody uses either, node.js in recent
years and that's about it. If this webasm effort ever got into
most browsers, I guarantee that almost everybody would chuck
javascript and compile java, C#, or D to the browser instead.
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.
Prefetching and caching is used by _all_ app runtimes, whether
Java or Objective-C. They don't change the fact that the web
frontend is much slower and difficult to work with.
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.
Actually, that's one of the big problems with the more dynamic
model: it breaks search engine indexing. How does the crawler
have any idea how to navigate an app UI and generate URLs that
are meaningful, if they're even made available by the app?
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.
The HTML5 canvas does provide a way out to some extent, but
you're still stuck with javascript and I believe a certain amount
of CSS. You wouldn't do the layout manually, just download a
javascript library that does a lot of the grunt work for you. It
is on the right track, but goes nowhere near far enough. But as
I noted earlier, the canvas tag doesn't even support hyperlinks
natively, which is a pretty big omission for a web technology.
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.
Simply repeating a point, which I already addressed and noted was
irrelevant, doesn't add anything to the discussion.
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.
So your point is that your suggested binary fallback doesn't
quite work as advertised to replace SVG? Never heard of anyone
suggesting an alternative, then pointing out it doesn't actually
work. As I already noted, SVG doesn't have to be text to be
"embedded."
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).
Very responsive because they're made up of trivially simple line
art, perhaps.
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.
It wouldn't be confusing at all. You'd simply do all that in
your text SVG authoring format and HTML on your side, then
compile SVG to a binary encoding on the server and send that to
the browser. The browser would have to understand this binary
encoding instead of text SVG and do all the same steps it does
with text SVG now, except it would all work much faster for the
user. :)
On Sunday, 21 June 2015 at 07:38:02 UTC, Nick Sabalausky wrote:
On 06/21/2015 01:42 AM, Joakim wrote:
At this point, it's just a software issue. Mobile devices
just need UI
features like multiwindow to make more capable use of large
desktop
monitors.
No, there's more to a desktop/laptop than just processing power
and keyboard/monitor/mouse. The mobile devices are also
(currently) shit at storage space (not to mention virtual
memory) and peripherals. And then for devs, ie the people who
actually make all this stuff in the first place, there's even
more improvements needed.
I have almost 50 GBs of storage on my tablet, between the
built-in flash and an SD card, about half what I have on my
ultrabook. If I weren't filling that 50 GBs up with many GBs of
HD video, that's plenty of space for most people. As for
peripherals, you're talking printers and scanners? Do people
even use those anymore? :) If there's any demand for those at
all, the dock for your smartphone will have a USB hub that
supports them.
As for devs, they're a small percentage of the computer-using
public, similar to hard-core gamers who want the most expensive
graphics cards. But even devs, most of whom certainly aren't
using massive rigs with Xeons and 32 GBs of RAM, will make the
switch. The biggest issue there is the x86-centric toolchains
most are using, but those should transition to ARM fairly quickly.
I'm not saying it can't or won't reach parity with traditional
laptop/desktop. The groundwork is there and it IS now feasible
at least. But there's still a lot left. And, to even get there
at all, the mobile OS/device devs will have to accept that it
will require adopting more and more desktop/laptop features.
Not much left if you ask me, just multiwindow UIs, which could
have been done at least a year earlier, and transitioning the few
remaining desktop apps that haven't made the mobile transition
yet.
And I think that's the biggest question mark, as they seem
quite loathe to accept that mobile-style (or really, iOS-style,
which everyone else in mobile copied wholesale) isn't
universally superior for everyone in every way. This attitude
will prevent them from reaching parity and replacing
desktops/laptops until for as long as they choose to cling to
it. How long they'll cling to it is the question.
"mobile-style" is a very vague term, presumably you're referring
to the prevailing mobile touch GUIs. As I pointed out, the UI
will need to be adapted for desktop monitors.
But suppose, sooner or later, they've finally managed to
improve enough to render the traditional line of
desktops/laptops obsolete. It *WON'T* be a case of "mobile
killed desktop". Because they will have, by necessity, BECOME
just as much desktop as smartphone - the only difference being
the lineage. It would be, in effect, exactly the same as
laptops gaining mobile capabilities and mobile-friendly UI.
Except, oh wait, that's happening too, see MS Surface Pro.
That's what I detailed below: it's not the same and the failure
of Surface and other Windows two-in-ones shows that.
So it's NOT mobile replacing desktop/laptop. It's not "the new
defeating the old" as the smartphone/tablet fans would have
everyone believe. It's just plain old convergence. Neither side
will "win" over the other because winning this game requires
erasing the lines between both sides.
It _is_ convergence of software UIs, but it is killing off of the
old hardware form factors and previous underlying desktop
operating systems.
Yes and no. As hardware form factors, the old desktop and
laptop models
are being ditched. The desktop box will almost completely
disappear,
while the folding laptop is only really needed by a small
niche, those
for whom "lap-ability" in a plane or conference seat is
needed. I
picked up a bluetooth keyboard for my tablet last year: that
suffices
for me, and I bet most people, since I'm always going to put
them down
on a hard surface before typing. I bet 97% of the people who
currently
use laptops are in this category.
And then you need some place to set the phone/tablet. The
natural choice is to dock it into the keyboard, ideally with
some sort of hinge. At which point you've just re-invented the
laptop form factor.
I disagree that the keyboard is the natural place to dock the
phone/tablet, and the failure of such devices, both on the
Android side and especially on the Windows side, seems to show
this. I simply prop up my tablet on my desk on the side of
something, whereas most will likely just dock them in small
holders, either just to hold them up or to provide ports to
connect to a larger monitor.
The usefulness of laptop form factor won't go away, People will
just start failing to recognize that it's just a laptop in new
clothes with a few more tricks.
It will go away, for the reasons I've given. Does that mean
nobody will use laptops? Of course not, people still use
mainframes and giant workstations. You just never see them
around anymore, because it's such a small niche. :)
As for the desktop OS, Windows has essentially no penetration
on mobile,
while OS X and linux live on only in the core kernels of their
mobile
counterparts.
All that is converging is the software UIs, where mobile
devices will be
able to display apps appropriately both for constrained
touchscreens and
larger monitors controlled by a keyboard/trackpad. Only in
that last
sense are mobile devices converging, by adding software UIs to
work on
large screens.
No, as you already pointed out yourself, the hardware
capabilities are converging as well.
Heh, never said anything of the sort. Anyway, it's funny that
you respond to a quote limited to software and UIs by going on
about hardware again, never mentioning software. :)
And then you have on one hand the whole "hooking up a
keyboard/mouse" to a phone/tablet (and monitor too, HDMI-out
has become pretty common on Android)...
What is your point, that because we're still using keyboards and
mice, they're "converged?" A car still moves on wheels yet
nobody would say it "converged" with a horse and carriage. One
feature, the wheels, carried over, but most of it is completely
different. I think that since the underlying device, a
smartphone, is fairly different from a mainframe or a PC, it's
far-fetched to say the devices are "hybrid" or "converged,"
simply because they're all using similar input peripherals when
used at a desk.
But even that is only temporary, as voice and gesture recognition
will soon kill off those input peripherals too. :)
And on the other hand, you have laptops getting their
mainboards moved to the upper-half and becoming detachable from
the bottom half, and getting smaller, lighter, better battery
life...
That...is form-factor convergence.
That might be actual hardware form-factor convergence, if anybody
were buying those two-in-ones, but almost nobody is.
Of course, that's dependent on the phone/tablet folks actually
managing to pull it off. Which is certainly a possibility, I
agree,
but I'm not convinced they'll necessarily manage to, at least
not in
the short term.
It's around the bend and frankly should have been done sooner.
Never underestimate the power of corporate ineptitude ;)
I agree with the sentiment, just not sure what you're trying to
indicate with the "corporate" qualifier. "Ineptitude" alone
would have sufficed. :)
