2014-10-29 2:58 GMT-02:00 Louis Santillan <lpsan...@gmail.com>:
> Some of the ideas you identified in "rebooting the web" were more
> clearly and concisely conveyed in Ian Hickson's Google+ post [0][1].
Sorry if I wasn't clear or concise enough, but there are points of
Hickson's post that only apply to a certain vision of the Internet
that is not necessarily the only one possible. It is understandable,
coming from someone who is/were google representative in W3C. For
example, his points 1 and 2: "be free to implement by any vendor" and
"be vendor-neutral, i.e accept input from everyone". Why do we even
need to talk about "vendors" at all? Clearly because the web browser
is so absurdly huge, that only a "vendor" would be able to write one.
It is way beyond the reach of a single programmer and even beyond the
reach of a small startup. Even if you could come up with a good
business model to make a lot of money from a new web browser, you
would not be able to implement all the standards with a startup of the
size Netscape was when it started. You would need massive resources to
ship your first version. What has changed since Netscape early days?
The barrier of entry today is much higher and innovation is mostly
dead. Also, "accept input from everyone" smells to design by
committee, and we all know what is the result of that.
I understand that the only way to challenge the status quo today is
coming up with a radically simpler alternative that still allows the
same functionality we have today. It is not impossible and it has the
potential to be way simpler than trying to stick to the standards.
Because as we all know, today's web is the result of a convoluted
series of additions and fixes that morphed a document distribution
system into a distributed application system. It never started with a
simple set of generic primitives that would allow it to grow to what
it is today. With the benefit of hindsight, it is way easier to design
a new web today than it was in 1993.
I hear some of you guys when you say that applications does not belong
on the web. I agree, but for lack of better alternative, it is
becoming the default. That's the problem that must be solved to
replace the web.
> Specifically, Ian mentioned that anything that replaces the "web" will
> have to be radically better ("faster, easier to author in, easier to
> develop for, easier to monetize").
"Faster, easier to author in, easier to develop for, easier to
monetize" are all obvious points. Now I agree that for some new
technology to replace some worse stablished one, it sometimes has to
be radically better. That's true every time that a choice must be made
to use one or another, but not both at the same time. But if the new
technology is good enough, and we can plan ways for both technologies
to coexist and talk to one another, we do not need to replace the old
standard instantly. We can build a bridge that allows for the
coexistence of both.
Today that we can execute native applications on web browsers through
NaCl, asm.js (and possible RockSalt soon), one of the sides of the
bridge is easier to build.
> Several people have pointed out
> why other attempts like XML, XForms, Java, Flash, and .Net have
> failed. And, I agree with Crockford [2] when he states that parsing
> source code like JS is better (faster, safer, portable, extensible)
> than verifying bytecode (Java, .Net, Flash).
This is not how I read [2]. I see they are comparing JS to Java, and
let's all agree how much Java sucks. Also, Harvard disagrees with them
via their 80 lines of code that are called RockSalt (although it is
geared towards executing native code, but still undefeated in the
security arena up to now). While we may agree that executing untrusted
code safely is not an easy task, Javascript and modern Web Browsers in
general are so far from being safe that is hard to make any claim in
this direction. If language X is worse than Javascript. does it make
Javascript a good choice? The main problem here is that we have a
whole generation who was grown learning JS as their first and
sometimes only language. The cultural barrier is a big challenge to
tackle.
> It looks like someone else has already considered porting Inferno
> to the current web [4].
No. That is only "Styx client library written in the JavaScript. "
Porting Inferno to the current web would be to port the DIS virtual
machine, that is the basis of Inferno, to run on top of NaCl or
asm.js.
>
> [0] https://plus.google.com/+IanHickson/posts/SiLdNL9MsFw
> [1] http://www.sitepoint.com/will-html-ever-be-replaced/
> [2]
> http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageForTheWebPart2MadnessOrJustInsanity.aspx
> [3] http://en.wikipedia.org/wiki/Representational_state_transfer
> [4] https://code.google.com/p/limbo-machine/wiki/JS
>
>
>
