3 ms·
Google should be pushing Portable Native Client, not plain Native Client, which is by implication Non-Portable. NaCl solves Google's problems, but is a damaging
by pslam 14y ago
Google should be pushing Portable Native Client, not plain Native Client, which is by implication Non-Portable. NaCl solves Google's problems, but is a damaging standard for the rest of us.
Nobody should be pushing CPU architecture specific executables as a web standard. Yes, you can compile is for x86 and ARM, but that's incredibly short-sighted. What about PPC? MIPS? Some future architecture that hasn't been invented yet? Do we have to make a virtual machine then? Yes, you can also compile as LLVM bitcode, but then why give prejudicial preference to x86-32 and ARMv5? (Note the specific versions there) You might as well just ship as PNaCl and skip NaCl altogether.
PNaCl is an amusing evolution of web scripting: we've come full circle from a JVM thru Javascript back to a solution which is almost a JVM. To be cynical, it seems like an awfully huge project just to avoid writing Java.
- gsnedders 14y agoHeck — we're already having enough pain as Typed Arrays expose system endianness to the web platform. Most scripts using Typed Arrays are already broken on big endian systems, and it's practically inevitable that Typed Arrays are going to have to convert endianness dynamically to appear little endian.
- saurik 14y agoFWIW, LLVM offers other advantages over a JVM, such as letting you not have to use things like garbage collection and strict typing (as in, you can have arrays of random garbage that you type cast back/forth through structures and unions; that's all allowed in LLVM, and all considered safe by way of PNaCl AFAIK, as it doesn't care whether your program works or fails, only that it doesn't escape).