On Sunday, 21 June 2015 at 10:07:05 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 21 June 2015 at 09:07:52 UTC, Joakim wrote:
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.
Start from scratch, in what direction? You need a design that
is generic enough, yet more productive than what exists.
I've sketched out one possibility in the past, with more details
in subsequent comments in that thread:
http://forum.dlang.org/post/[email protected]
Surely you could think of other approaches that would ditch the
current document format also?
And then you need to wait 5 years for end users to install the
viewers, before you can use it.
Not necessarily, you'd probably start by simply linking your app
into the viewer, ie using it just like any other UI toolkit
library, until it became popular enough that you could separate
out the viewer as its own app.
I don't see native apps winning over the browser based apps.
Only in very limited domains, of daily use (like purchasing
tickets), but for non-technical reasons.
I think you are complete ignoring the current mobile app wave
then. There are plenty of valid technical reasons why
web-centric organizations like Facebook tried to use HTML5 for
their initial mobile apps but then had to backtrack to native
mobile apps.
And let's face it, many "native" apps are 50% browser based,
just wrapped up in a shell. They use the HTML5 web-view.
Because it is easier and performs well enough.
More likely because they already built a simple webapp and don't
want to duplicate effort. These are the low-end apps that
started on the web, whereas those that start on mobile now often
don't even bother with a webapp.
think about how you want to do it. Simply dumping more
features on top of the old web stack is a recipe for failure.
I hear you saying it, but installed base is way too important a
factor to be ignored. What you can do is changing the
underlying engine, but keep the compatibility.
Browser install base is overrated in this day and age when people
install apps aplenty and easily from mobile app stores. They've
been trying to change the underlying engine for a couple decades
now and haven't gotten very far.
You need a scene-graph / DOM.
Not really, certainly not the latter if you chuck HTML/CSS/JS.
DOM is a scene-graph.
Which is why I said you could chuck the DOM, but probably want
some simpler kind of scene graph instead.
You've got to be joking: why would anyone want to use either?
Because it is backwards compatible.
You were arguing that it wasn't that bad. If the only reason you
can give is because it's legacy tech, you just argued against
yourself. :)
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.
Java has been available for years, almost nobody used it. Flash
was available for years and it was only used in limited
domains. Active-X was available. PNACL is available. asm.js is
available, and webasm doesn't offer much more than asm.js in
the near future.
You can wish, but certainly not guarantee.
You seem to have missed the discussion above. I guessed that
they were allowing webasm to directly manipulate the DOM, rather
than having to ca
