On “On Asm.js” • Hacker News Board

Re: On “On Asm.js”

#31

Post by cdash » Thu, Nov 28, 2013, 5:33 AM UTC

azakai wrote: post #26

fdej wrote: post #15

Naive question: is there a reason why we cannot just compile programs to both native/bytecode and javascript and have browsers automatically fetch the version they support? If it turns out that native/bytecode universally runs (say) 20% faster and loads in half the time, the javascript target will eventually die a natural death of obsolescence without compatibility ever being sacrificed. If it turns out that the java…

Well, that seems to be what Google is doing with PNaCl and pepper.js. Pepper.js uses emscripten to compile PNaCl apps so they run in JS (specifically asm.js). In Chrome the PNaCl version can run, and everywhere else it runs in JS. That sounds like what you are proposing? You can try that approach out right now, http://www.flohofwoe.net/demos.html http://trypepperjs.appspot.com/examples.html Those two sites have the s…

Except for the fact that you can not compile threaded programs to javascript I am pretty sure while you can to PNaCl and this is my problem with this talk of asm.js, until it supports threads I don't really consider it an acceptable solution.

Re: On “On Asm.js”

#32

Post by jheriko » Thu, Nov 28, 2013, 5:42 AM UTC

derefr wrote: post #20

jheriko wrote: post #14

"On a shared medium like the web, where content has to run across all OSes, platforms, and browsers, backwards-compatible strategies are far more likely to succeed than discrete jumps." This is a valid point, but hits on something that constantly grates with me. We already have something massively more cross platform and performance focused than JavaScript - C. The problem is that the standard library for C is utterl…

Native code is, at the bottom of its ladder of abstraction, always held at the behest of some vendor's platform or another. Microsoft, Apple, and Google will never agree on a set of standard C libraries that could be used to build rich, modern graphical applications. If they could, we'd never have needed the web for anything other than the ideas of hyperlinks and intents--everything else could be done with URL-specif…

"Microsoft, Apple, and Google will never agree on a set of standard C libraries that could be used to build rich, modern graphical applications."

this is probably very true, but it isn't even a real problem. the standard library can be expanded to encompass rendering, audio, networking and co. regardless as to platform nitty gritties we can implement a layer over the top (lots of people do this to make games already).

when i look at the web as an approach to being platform independent i see something which is truly quite poorly constructed. the kinds of bugs and problems in the webstack are utterly alien in my world... libraries to work around browser bugs? laying out objects on a screen 'complicated'? its just shoddy all over... especially the browser implementations and the myriad frameworks piled on top of javascript and CSS.

coupled with the staggering loss of performance and increase in complexity I have no desire to use web tech to develop my cross platform products - and my native development moves at an extremely rapid pace.

i qualify this very heavily with "i know how to do this and have done it alone and in teams many times more often than once"

a great example of this is everything already in the C standard library which - whilst it seems simple today now its done - hides a great deal of OS and platform specific details which vendors still disagree on but programmers in that environment are largely (and rightly) unaware of. a quick look into the Win32 apis, X11, BSD socket implementations or the Cocoa/Objective-C stack on OSX will show up just how different the platforms can be in their 'low level' interface for many things.

Re: On “On Asm.js”

#33

Post by jheriko » Thu, Nov 28, 2013, 5:44 AM UTC

azakai wrote: post #27

jheriko wrote: post #14

"On a shared medium like the web, where content has to run across all OSes, platforms, and browsers, backwards-compatible strategies are far more likely to succeed than discrete jumps." This is a valid point, but hits on something that constantly grates with me. We already have something massively more cross platform and performance focused than JavaScript - C. The problem is that the standard library for C is utterl…

C is not sandboxed, and C has lots of undefined behavior. For those reasons, it is problematic for the web, which needs to let people view any site from any browser and platform, in a safe way. People have tried to "fix" those issues with C, and usually they end up going pretty far, ending up with stuff like the JVM or CLR.

this opinion is utterly unjustifiable imo and exactly what i mean by 'the old security arguments are obsolete'

your comment suggest that you simply don't understand sandboxing and virtualisation i'm afraid. nor how the technology of the web works down to the metal.

Re: On “On Asm.js”

#34

Post by jheriko » Thu, Nov 28, 2013, 5:46 AM UTC

steveklabnik wrote: post #18

jheriko wrote: post #14

"On a shared medium like the web, where content has to run across all OSes, platforms, and browsers, backwards-compatible strategies are far more likely to succeed than discrete jumps." This is a valid point, but hits on something that constantly grates with me. We already have something massively more cross platform and performance focused than JavaScript - C. The problem is that the standard library for C is utterl…

JavaScript is sandboxed, and safe. C......... isn't.

but it trivially can be - this is very measurable and lots of people do it. see for instance iOS, OS X, Android, Windows 8... actually I can just list the modern operating systems that don't provide such an environment out of the box:

(end of list)

Re: On “On Asm.js”

#35

Post by pcwalton » Thu, Nov 28, 2013, 6:13 AM UTC

jheriko wrote: post #32

derefr wrote: post #20

Earlier quoted context omitted.

Native code is, at the bottom of its ladder of abstraction, always held at the behest of some vendor's platform or another. Microsoft, Apple, and Google will never agree on a set of standard C libraries that could be used to build rich, modern graphical applications. If they could, we'd never have needed the web for anything other than the ideas of hyperlinks and intents--everything else could be done with URL-specif…

"Microsoft, Apple, and Google will never agree on a set of standard C libraries that could be used to build rich, modern graphical applications." this is probably very true, but it isn't even a real problem. the standard library can be expanded to encompass rendering, audio, networking and co. regardless as to platform nitty gritties we can implement a layer over the top (lots of people do this to make games already)…

> laying out objects on a screen 'complicated'?

As jwz said in 1998 [1]:

"Convenient though it would be if it were true, Mozilla is not big because it's full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big."

I think any document and application layout system that handles all the use cases of CSS is going to be about as complex as CSS. Certainly PDF and Microsoft Word .DOC are up there in terms of complexity.

[1]: http://www.jwz.org/doc/easter-eggs.html

Re: On “On Asm.js”

#36

Post by ygra » Thu, Nov 28, 2013, 7:03 AM UTC

pilif wrote: post #16

pornel wrote: post #12

In this exchange UTF-8 got dragged into list of ugly hacks, but it is a beautiful hack. Endian-independent, more efficient than UTF-16 for most languages (often including CJK web pages: halved cost of HTML & URLs makes up for 33% extra text cost), supports easy and safe substring search, can detect cut characters, and all that with ASCII and C-string backwards-compatibility. If I could redesign entire computing platf…

The disadvantage of utf-8 is that it's a variable length encoding. This means that certain operations which are usually O(1) are O(n) with UTF-8: one is finding the n-th character in a string, the other is finding the length in characters (though that's also true for null terminated C strings) Another problem is that swapping a character in a string might cause the (byte) length of the string to change, which might f…

You're still wrong on UCS-2: Except for JavaScript were it's still used (afaik there are unportable workarounds, but it's still specified that way) all others use UTF-16. Yes, many methods operate on code units instead of code points (because the character type is usually 16 bits wide), but code-point-aware methods usually exist in Java, .NET and others. Just because a string is treated as a sequence of UTF-16 code units that doesn't make it UCS-2. You could with the same argument say that everything that uses UTF-8 and gives you access to the underlying bytes doesn't support Unicode at all, but only ASCII.

Re: On “On Asm.js”

#37

Post by mercurial » Thu, Nov 28, 2013, 7:10 AM UTC

PeterisP wrote: post #28

rolux wrote: post #23

Earlier quoted context omitted.

"UTF-32 (or UCS-4) is a protocol to encode Unicode characters that uses exactly 32 bits per Unicode code point. All other Unicode transformation formats use variable-length encodings. The UTF-32 form of a character is a direct representation of its codepoint." ( http://en.wikipedia.org/wiki/UTF-32 ) Of course, the problem of combining marks and CJK ideographs remains.

That's the point - you get O(1) functions that work on codepoints. Since for pretty much all practical purposes you don't want to work on codepoints but on characters, then codepoint-function efficiency is pretty much irrelevant. I'm actually hard-pressed to find any example where I'd want to use a function that works on codepoints. Text editor internals and direct implementation of keyboard input? For what I'd say 9…

For a lot of usecases, you're just dealing with ASCII though (hello HTML). Wouldn't it be possible, in a string implementation, to have a flag indicating that the string is pure ASCII (set by the language internals), thereby indicating that fast, O(1) operations are safe to use?

Re: On “On Asm.js”

#38

Post by willvarfar » Thu, Nov 28, 2013, 7:43 AM UTC

pilif wrote: post #16

pornel wrote: post #12

In this exchange UTF-8 got dragged into list of ugly hacks, but it is a beautiful hack. Endian-independent, more efficient than UTF-16 for most languages (often including CJK web pages: halved cost of HTML & URLs makes up for 33% extra text cost), supports easy and safe substring search, can detect cut characters, and all that with ASCII and C-string backwards-compatibility. If I could redesign entire computing platf…

The disadvantage of utf-8 is that it's a variable length encoding. This means that certain operations which are usually O(1) are O(n) with UTF-8: one is finding the n-th character in a string, the other is finding the length in characters (though that's also true for null terminated C strings) Another problem is that swapping a character in a string might cause the (byte) length of the string to change, which might f…

"Text normalization in Go" https://news.ycombinator.com/item?id=6806062 was here yesterday and made me wonder: how can you handle ligatures, accents, digraphs etc in fixed-width?

Perhaps text parsing is just a hard problem?

Re: On “On Asm.js”

#39

Post by PeterisP » Thu, Nov 28, 2013, 7:57 AM UTC

mercurial wrote: post #37

PeterisP wrote: post #28

Earlier quoted context omitted.

That's the point - you get O(1) functions that work on codepoints. Since for pretty much all practical purposes you don't want to work on codepoints but on characters, then codepoint-function efficiency is pretty much irrelevant. I'm actually hard-pressed to find any example where I'd want to use a function that works on codepoints. Text editor internals and direct implementation of keyboard input? For what I'd say 9…

For a lot of usecases, you're just dealing with ASCII though (hello HTML). Wouldn't it be possible, in a string implementation, to have a flag indicating that the string is pure ASCII (set by the language internals), thereby indicating that fast, O(1) operations are safe to use?

What you say is done with UTF-8 + such a flag - if the string is pure ASCII (codes under 127) then the UTF8 representation is identical. IIRC latest python does exactly that, sending utf-8 to C functions that expect ascii, if they are 'clean'.

But for common what usecases you're just dealing with ASCII? Unless your data comes from a cobol mainframe, you're going to get non-ascii input at random places.

Html is a prime example of that - the default encoding is utf8, html pages very often include unescaped non-ascii content, and even if you're us-english only, your page content can include things such as accented proper names or the various non-ascii characters for quotation marks - such as '»' used in NYTimes frontpage.

Re: On “On Asm.js”

#40

Post by dgregd » Thu, Nov 28, 2013, 8:19 AM UTC

azakai wrote: post #7

dgregd wrote: post #6

> I see plenty of reason to keep betting on evolution So why Mozilla helped to kill WebSQL? Because NoSQL (IndexedDB) is so much better than SQLite? Mozilla is too much focused on Brendan Eich baby. They should really move forward because JavaScript is becoming new IE6.

WebSQL was a completely separate debate, if I recall correctly, the issues there had to do with WebSQL being heavily dependent on SQLite, a single implementation. So it was hard to spec in a vendor-independent way like web standards require. IndexedDB is much less capable than SQLite, no doubt about it, but still very useful, and far far simpler and feasible to spec and standardize (which it has been).

It is another case where they make fundamentally bad decision.

In case of WebSQL, 40 years of legacy is not important. Millions business apps developers needs are not important. Clean and nice spec is more important for Mozilla guys.

However in case of Brendan Eich baby, legacy is very important. Ugly hacks like asm.js, without W3 specs, are promoted. Try to guess why.