Hacker Newsnew | comments | show | ask | jobs | submit login

Completely disagree.

I don't even think Google "adopted" NaCl, it's still more a private project of a few, compared to Chrome(OS) and Android.

NaCl is one of those technologies that I secretly hope fails. Pull the plug on x86 already, FFS.

Saying that the Open Web needs an app-store to compete with the walled gardens is also a fallacy. Quite the contrary, the web competes with the walled gardens because it doesn't have such master-record. You will see this pattern repeat itself; the chaotic nature of the web beats any attempts to impose "order" upon it. Cf. the dismal failure of dmoz and other curated directories, compared to search engines.

If you want to use performance critical software that pushes the limits of your machine, download it, use Java or whatever.

I doubt the app-store model will survive long term; individual merchants and vendors tend to move faster than the infrastructure that houses their shops and supports their business (almost literally.) The moment a few merchants diverge from the proscribed machinery of the market, and exploit inefficiencies, as they will, is the moment you will see this model come apart at the seams. If the entire model isn't killed along with its platform by changes in technology.

The one good example I can give you is the buildings built throughout South East Asia to house street-vendors. Specially in Cambodia and Vietnam, the governments built multi-story shopping centers, just piles of concrete, and invited vendors to push their carts in and congregate. The markets might have looked like proper malls at some point, but with time, they're just shaded bazaars like any other street market, except this one isn't dried by the sun and there is no drainage. Over time, the building has all the appeal of a street market, except you have to climb up some slippery stairs tightly packed with pickpockets. However, most higher-end merchants gather around the vertical-bazaars and open proper walk-in shops with more products, better presentation, and all the amenities of a private property (fan, seats, water cooler, bathroom, TV/radio, etc.)




Comments like this demonstrate why web _applications_ will lose

The inertia and individual investment in HTML and JavaScript is so incredibly high that web players (from the browser makers such as Mozilla to the individual web developers) absolutely steadfastly refuse to evolve with changing requirements.

The belief that JS+HTML is "just fine" and no significant evolution is required to support application development is absolutely incomprehensible; what other application platform available today has seen iteration as glacially slow as the web? The browser makers have consistently stuck to their "HTML+JS is fine for everyone" guns, ECMAScript has failed to evolve almost entirely, and no common application development framework or platform has emerged.

HTML+JS libraries -- such as jquery -- are just fine for interactive document publishing, but are no replacement for Cocoa, Android, or Qt. The lack of common re-usable and extensible UI components is a travesty. Proponents like to advance the idea that this chaos is a benefit -- choose whatever tools you want -- but the rising popularity and the massive investment in application development on native app stores demonstrates a market desire for something simpler: A common well-defined application development platform is valuable, and the only barrier to adoption in the web world was a trustable distribution mechanism -- app stores.

The fact that you think App Stores will fade away is demonstrative of a failure to understand why the app store is so popular -- ease of distribution, easy to use common development platform, ease of payment processing, common UI (instant user familiarity), performance (!), open development platform (no JS sandbox, not all languages must be filtered through JS).

Ask yourself why Google has ChromeOS on one hand, Android on the other, and is working on technologies like NaCL that could bring many of the advantages of Android to Chrome?

Lastly, hopefully I can pre-empt the "JS is a common bytecode platform, just target that" crowd. Yes, you can emulate any other turing machine on top of a turing machine, but that doesn't mean it will be fast, clean, easy to use, easy to debug. It absolutely makes no sense to halt the evolution of the browser as a platform and instead tell everyone to use a high-level language like JavaScript as a common bytecode.

[Addendum]

I also should mention, anecdotally, that I've had some long-winded conversations with a member of the Chrome App Store team -- me from the perspective of a long-time native developer, them from the perspective of being tasked with coming up with ways to improve the web as an application development platform.

From my conversation, which may or may not reflect reality:

There seem to be two schools within the Google App Store team. The first (and seemingly most common) belief that there's nothing terminally broken with the DOM, HTML and JavaScript, they just need to find a way to make it easier to implement re-usable UI components, perhaps a common model for namespaces, objects, and other small improvements to JS.

The second seems to believe that a fundamental re-imagining is required -- perhaps dropping the DOM entirely in favor of rendering with canvas and a traditional view/event hierarchy. Consider opening the playing field for more languages (eg, via NaCL).

I think the competing strategies within Google and the clear differences of popularity between them -- Android, Chrome/ChromeOS/Chrome AppStore -- provide an enlightening view as to the likely future of application development on the internet.

-----


HTML+JS libraries -- such as jquery -- are just fine for interactive document publishing, but are no replacement for Cocoa, Android, or Qt. The lack of common re-usable and extensible UI components is a travesty.

Cappuccino http://cappuccino.org/

SproutCore http://www.sproutcore.com/

Ext JS http://www.sencha.com/products/js/

-----


I don't want to dismiss these out-of-hand, but they're really not a replacement for a modern application development framework.

Beyond functionality (of which these can and do provide considerably less), part of what makes a platform like Cocoa/UIKit so valuable -- it is used by every application on the device. The applications will interoperate both with each other and with the OS (background services/tasks, quicklook, spotlight, etc, etc, etc). The interaction model will already be familiar to the user, visual cues will be understood, the speed and inertia of animations (such as scrolling) will be expected. There is an enormous value to being able to leverage user expectation, and this is where too many choices falls down.

-----


I have seen many apps (on all platforms -- iPhone, Android, OS X, Windows, etc.) that deviate from user expectations. Ultimately, meeting user expectations is the responsibility of the developer not the framework.

HTML has its own set of visual cues that you and millions of others easily interact with every single day. I would argue that the interaction model of HTML/JS apps may be as familiar or more familiar to users.

I don't disagree that HTML/JS apps can be difficult to develop, but I do not think they are going to "lose". (I don't think they are going to win either. It's not a win/lose situation.)

Since it seems that your background is in native applications, I just wanted to provide you with some references to frameworks that provide something a little more advanced than jQuery and interactive documents.

Obviously, each team needs to look at its project and goals and choose whether a native app, an HTML/JS app, or both is appropriate.

-----


I'd like to point out a couple of things about these choices for examples of rich UI libraries: All three of them throw most of the DOM, and reimplement almost everything from scratch: structure, layout, and most behavior (outside of that provided by input elements that can't realistically be implemented by hand). I don't think you can ask for a stronger indictment of the DOM and related APIs with respect to implementing applications.

And that's the problem. It's not [p]NaCl vs. Javascript. It's whether the core APIs are designed for the task, which in the case of web applications they clearly aren't. The most egregious failings of web applications stem directly from bad APIs, and if you look at their counterparts (for example) in iOS and Android, there's absolutely no comparison. A better script engine (and yes, almost anything would be better than Javascript) would be nice, but would do very little to solve the API problem (don't forget that NaCl can't call anything not provided by the browser, so it can't serve as an "escape hatch").

There are those who suggest that the browser APIs are close to "good enough" and just need to be tweaked a bit to make it possible to create good, efficient web apps on par with modern native apps. I'd like that to be the case (my day job is working on browser application tooling and infrastructure), but so far it's not happening where it matters most -- on mobile devices. On the desktop you can usually get away with murder because the machines are so fast (and have so much memory), but on more limited mobile platforms (and by limited I mean ~1GHz ARM with ~0.5G of memory) web apps aren't even close to their native counterparts. There are some laudable attempts out there (e.g. Gmail mobile, the Sencha Touch demos), but if you poke on them a bit you start to notice obvious performance and memory issues (e.g., when Safari Mobile crashes on the iPad it's usually out of memory).

Does this mean native apps in app stores will "win", and the web will "lose"? The web "won" on the desktop (for most kinds of apps, anyway), in spite of its severe limitations, because it provided a reasonably stable platform and super-simple deployment. App stores solve the deployment part of this problem reasonably well, but fail badly at the cross-platform part. Can the web be made "good enough" in time to win again? I don't think anyone can accurately predict the outcome at this point.

-----


Yeah, well, web is not native, it's not meant to be, and it will never be, and I for one am glad that it's so different from native development.

-----


Mozilla would be happy to replace Qt/Cocoa/... with HTML+CSS+JS (or XUL). So it's obvious they'll be highly reluctant to have the exact opposite.

Microsoft once tried this in Windows 98 (thanks tightly-integrated IE) - and fairly succeeded. Since then, the attempts to "bring the Web to the desktop" are fairly constant.

-----


Yet another new one is QT Web runtime: http://qt.nokia.com/developer/qt-roadmap (for lack of better link really)

-----


I couldn't agree more if I were suddenly granted the magical ability to concur with the power of a thousand suns.

As far as NaCl goes, the absolute last thing the web needs is portability/endianness issues. I'm writing this comment on a phone (ARM), and I also browse on my desktop machine (x86-64) and my netbook (Atom, x86). (Not to even mention PS3/XBox 360/Wii/older Macs, all of which come with browsers.) Wanna make web the web worse? Force developers to target several architectures for their apps, or greet users with "Your CPU isn't supported!" pages. Lots of Webapp developers have trouble with cross-browser issues!

If you look at Firefox plugins (native) versus extensions (Javascript), you can see fairly plainly that, even though it's slower, the ease of development in Javascript (even with all its quirks) outweighs the benefits of native code, even for heavyweight extensions.

The best solution, in my opinion, is to expose a (fast) bytecode VM to web developers. Javascript is okay for a lot of purposes, but it's a messy language, and can be pretty clunky. A bytecode VM (one that at least has a Javascript front-end) could solve most of these problems. Off the top of my head, the JVM has Rhino for JS (as well as support for Ruby, Python, Clojure, and a host of others) and is easily restricted, if somewhat heavyweight. The Lua VM is faster than the JVM, is portable to a number of platforms (having a clean, portable, lightweight implementation), and I suspect that a Javascript front-end would not be hard, given the similarities between the languages (Lua could be described as a cleaner, faster Javascript). The language of choice would be up to the developer, as long as it could target the VM (and we'd not have to put together hacks like minifiers or $language-to-JS compilers like CoffeScript and Objective-J). Getting Google, Microsoft, and Mozilla to agree on a VM is trickier, although I hear MS loves Lua.

I also agree with the app store assessment (1000 suns, etc.), but have little to add.

-----


NaCl works on both ARM and x86 using the same downloadable bytecode. The long term goal seems to be to translate the bytecode in the client using a sandboxed LLVM to target the local architecture

See the following video from the recent LLVM Developers' Meeting

Portable Native Client, David Sehr, Google [mp4,269mb] http://www.llvm.org/devmtg/2010-11/videos/Sehr_NativeClient-...

-----


As I understand it, if you use Native Client now, you get an architecture-specific binary. The LLVM bitcode based portable version is still a work in progress. So it's more accurate to say "long term goal" than "works".

The problems with Native Client go beyond its currently x86-specific nature though. The Web is based on open standards, and a requirement for most standards is having multiple independent implementations. Native Client is a complicated enough technology that it might be completely impractical to spec it in sufficient detail and independently reimplement.

You might think this is only a technical issue of standards process, but a standard with only one implementation ends up de facto controlled by a single entity, even if the implementation happens to be open source. In practice, you'll get support for the platforms and CPU architectures that Google cares about, in their priority order. You can see how that might not be so appealing for an entity that doesn't want Google to be setting the agenda quite that much.

In addition to this, the security architecture of the whole thing seems pretty dubious. It does have a better attempt at security design than ActiveX. But given the basic approach (binary-level validation of binary code), it has a lot of attack surface.

All that being said, it's a neat project with a lot of hack value. It just doesn't seem like a great fit for the Web. It is likely more driven by Chrome OS at this point.

-----


So are you arguing against Native Client or pointing out a couple of niggles with the current implementation of Native Client? I don't think anyone was suggesting that the current experimental builds are perfect and infallible.

And if a single implementor is a bad thing, shouldn't you want Mozilla in on it?

-----


The best solution, in my opinion, is to expose a (fast) bytecode VM to web developers.

The base Squeak/Pharo VM runs bit identically on over 50 platforms. The performance of the Lua VM and its suitability for ECMAScript is very attractive, though.

-----


While you make fair points that I mostly agree with, I have a tiny nitpick: Lua isn't really a simpler Javascript; although I understand the point you were trying to make so I won't argue over it. :-)

-----


It's true; it's a bit of an over-simpification. I was trying not to get any more long-winded than I already was. :)

-----


Lua VM is not faster than JVM or V8; you might be thinking about LuaJIT, which is not as portable as the standard Lua implementation and uses different bytecode format.

-----


I don't know which Lua you're used to, but as of 5.1, it's incredibly fast; I may be benchmarking the wrong things (the big one I tried was finding the first 2,000,000 primes by trial division, which should lend itself well to hotspot optimizations). Either way, though, I'd still argue that a VM (JVM and Lua were just a couple of examples of VMs that are fast, used in real applications, and are readily jailable) is the ideal solution.

-----


I'm referring to these benchmarks: http://shootout.alioth.debian.org/u32/which-programming-lang...

-----


FYI, Firefox extensions can contain native code. Of course, you need to include a binary for every OS/arch/Mozilla version triple you wish to support.

-----


I mentioned extensions; the first half of my previous job was spent on FF plugin development. Once in a while, one of us would get frustrated enough to try looking at how extensions are built for FF; never worth it. (Our IE guy was enviable in the sense that he only had to produce two DLLs, and got to work in his language of choice.)

-----


This is kind of at odds with your earlier comment...

-----


> "If you want to use performance critical software that pushes the limits of your machine, download it, use Java or whatever."

This is a bit too simple. The web is becoming a platform for rich interactive applications more and more. Nowadays we can use tons of applications without downloading and installing any software. Most people would agree this is a good thing.

However, the web as a platform is inherently broken. Engineering large scale web applications with the sheer combination of HTML, CSS and JavaScript is just a pain in the ass. Every level of abstraction you introduce is pushing the limits of the browser already. Having a sandboxed machine code interpreter would allow developers to spend their time on developing software using their own favorite abstractions. This can save time and frustration.

Maybe NaCl or even some bytecode alternative have their disadvantages, but they solve a very annoying problem for sure.

-----


Not disagreeing with you, but just one point:

> Saying that the Open Web needs an app-store to compete with the walled gardens is also a fallacy.

Chad doesn't say that the open web needs an app store, just that "it needs a realistic answer to native code." I assume he wants to avoid a future of fast app store apps vs. slow open web apps, not encourage the creation of a one-stop shop for web apps.

-----


NaCl is one of those technologies that I secretly hope fails. Pull the plug on x86 already, FFS.

There's no reason why NaCl should be inherently limited to x86. x86 is currently the biggest platform, but there's no reason why NaCL couldn't switch to a "Universal" payload like OS X has, combining the 2 largest ISA. (x86 and arm?)

EDIT: I've since read that NaCl is working on LLVM, which would be even better.

-----


1. LLVM is not portable. PNaCl is trying to make it so, but it's a work in progress.

2. A 'universal' payload with ARM and x86, would just work on them. What if in 5 years we have new architectures? Only supporting ARM and x86 would hold back innovation there.

-----


1) Yes, it's a work in progress, just like NaCl.

2) You're posing a what-if for 5 years down the road? Your horizon is really that far? Sounds like grasping for straws to me.

-----


Are you saying we shouldn't think 5 years ahead?

GP was right, including just x86 and ARM is not good enough. Heck it even ignores x86_64 right now, and won't support new SIMD extensions that come out from time to time. Not to mention be a barrier to anyone introducing a new arch, as GP said.

Thinking ahead here is vital.

-----


Thinking ahead is good, but precluding a technology because a particular implementation would have to be changed in 5 years is just flat-out silly for tech. You couldn't ever buy a car with criteria like that. Grasping for straws.

-----


The point is that if you have only x86 and ARM binaries, you can't run them directly on a new architecture. It isn't a matter of changing an implementation.

It's like trying to run a C64 binary today. The only practical way is emulation, which is slow - but thankfully fast enough in this case. In general though, it means new architectures will run more slowly than existing ones. That's not a good thing.

-----


By then just recompile it for the next wave of tech/standards.

-----


Do you think we still have the source code to all C64 binaries out there? We don't. And in 5 years, we won't have the source to all the stuff we are running now.

-----


Fine, those things can just die or limp along.

-----


I doubt the app-store model will survive long term

In general, yes, but there's a good chance more niche stores like Steam will survive for a fairly long while.

* Compared to e.g. either of the Apple app stores, Steam is a very open platform: there are very few demands imposed on the publisher, and developers can release updates whenever they wish, for example. The only other platform where the sort of iterative development Steam can provide is possible is the Web.

* It provides a tremendous value-add: infinite game downloads, automated patching and save file syncing in the cloud. Of course, none of these are issues with a Web-based game, but at least some of the stuff available on Steam isn't going to be possible in the browser any time soon.

* Games are generally much less fungible than the average application, Valve's own games even more so.

* Valve's earned the trust of most PC gamers, including mine. It's probably (percentage wise) the most trusted app store vendor currently in business.

-----




Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: