Hacker News new | ask | show | jobs
by daleharvey 5390 days ago

    "Now imagine a world where the browser ran something
    lower level. Where Google, Mozilla, Microsoft, Opera, 
    and Apple’s jobs in providing a browser more resembled 
    Intel’s job of providing a chipset: they simply 
    provided hooks for basic technologies like sound, 
    camera, movies, geolocation, etc. And on top of that,
    we the developers wrote HTML, CSS, JavaScript"
here lies the problem, coffeescript was cited in the article, you yourself wrote or at least worked with obj-j, there is haml and sass, writing alternatives to javascript / html / css is not a problem, people are doing it all the time. If browsers cant provide access to higher level API's in a complete and consistent manner, how do we expect them to provide low level ones?

There are 2 main problems with the web right now that I can see being brought up repeatedly

1. Devices / Lower level API's, new android devices have access to the camera but all things considering that is very weak, why do we not have standard solutions for clipboard access, device apis, filesystem apis, storage etc

Phonegap are doing great work for this on mobile, Mozilla have also talked about this in their mobile browser, if phonegap can do this cross platform then how in the hell can browser manufacturers not? why doesnt firefox already ship with this support on the desktop?

2. is performance, is javascript going to ever be fast enough that we can build rich applications and games, right now the smallest page animation triggers ridiculous stuttering, is it javascripts problem or the doms? is it fixable with current solutions? blazing fast hardware accelerated webgl or canvas doesnt matter if the host language cant lookup a variable without random second long pauses.

nacl is often brought up as the solution here, but I have a hard time seeing how providing a sandbox to execute native code is gonna help me build a nice mobile app that uses web technologies (forms, links, standard tools for accessibility) and can still do a decent page transition without stuttering

This article doesnt seem to draw any conclusions about how to solve these, and the "everyone can be the owner of the web" seems almost like its apologizing for Joe Hewitts confusingly completely off base conclusions.

I dont have any answers either, but happy that the conversation is being started.

2 comments

You bring up some really good points. I also agree that NaCl is not ideal. In my opinion plain text transmission of data is essential for the web, which would allow things like Google to keep working regardless of the "language" being used, whether it be HTML or Markdown, etc.

Having thought about it more, I think the real issue here is standards. All these other problems are a function of that in my opinion. The problem with standard stagnation and lack of competitiveness, whether it be missing features or hardware access, is not a coincidence in my opinion. This isn't some rut we are currently in that if we work hard enough we'll get out of. Instead, I think that the structurally process itself is predisposed to it. 5 years from now, the web will just have a new set of technologies that its behind native on. In other words, the way things are headed, the web can never be cutting edge. And sure, there will always be things that work well on the web, but I would personally like a cutting edge web.

Additionally, I'd like to add that as I stated in the article, I have discussed these thoughts with Joe on more than one occasion, and even had him look this over beforehand to make sure I wasn't putting words in his mouth. I don't think I was apologizing for Joe, I just think this is a really complex situation where the same analysis can take different shapes.

Your second point is moot. 280slides proved high quality desktop class applications are possible on the web. Cappuccino helped reinforce that fact by providing several more apps, some of which rival even their desktop counterpart (picsengine, which no longer accepts new subscribers, is just as capable as iPhoto. In fact my father actually like Picsengine better!)

Recently the new iCloud applications show that sexy animations are also possible on the web, if you're willing to put time into polishing it!

Performance on the web hasn't _really_ been an issue in years. The real issue is bad developers set the bar for web applications very low.

Your second point is moot. 280slides proved high quality desktop class applications are possible on the web ...

So ... where are they now? It was a nicer webapp, but no substitute for Keynote. Having worked with ObjJ/Cappaccino, I found it to be a frustrating attempt at working around the browser, rather than an actual solution.

Performance on the web hasn't _really_ been an issue in years. The real issue is bad developers set the bar for web applications very low.

That's poppycock. In terme of performance, you simply can't come close to what native apps are doing. We invest enormous effort in leveraging threading and extremely low cost implementations in native code, even dropping down to NEON/etc where appropriate.

There is room for higher level languages (arguably that's what ObjC is, plus ARC) but JS simply is not a replacement for what native app developers are doing. NaCL is.

280slides was nothing more than a demo app that hasn't been touched in 3 years. Atlas was the real product of 280north. I suggest trying Cappuccino today. If you're dealing with any significant browser issues, the problem is certainly not Cappuccino.

You can talk benchmarks all you want, but it doesn't change the fact that for 99% of consumer facing applications you won't have any noticeable benefit from those native speed.

You can talk benchmarks all you want, but it doesn't change the fact that for 99% of consumer facing applications you won't have any noticeable benefit from those native speed.

I'm not talking about benchmarks, I'm talking about actual application development, and the real impact the tremendous number of hours we spend as consumer app decelopers on performance has on the user experience.

I honestly can't even fathom your position, given the context of my experience maximizing application performance. All available CPU cycles are spent quite directly on performance and functionality.

Your position implies to me a myopic inexperience with development beyond the web.

Exactly what kind of applications are you building that require lower level languages in order to be performant? I can't think of an application I use on a daily basis that can't be done equally well in the browser. Of course there will always be certain applications that will need lower level support, but those are a very small minority.

Your position implies to me a myopic inexperience with web development.

Exactly what kind of applications are you building that require lower level languages in order to be performant?

All of them. You don't necessarily need C, you simply need to not waste CPU cycles on things that neither improve the user experience nor decrease development costs. You could achieve this with a higher-level language, including something like ObjC and ARC.

Your position implies to me a myopic inexperience with web development.

I'm very familiar with the space. Every cycle counts -- if a cycle is not spent on user experience or decreasing development costs, it's a completely wasted cycle. Browsers waste mountains of cycles.

Modern desktop and mobile software makes heavy use of SMP (threads), SIMD, specific CPU-optimized code paths (in addition to SIMD, and requires that the basic platform infrastructure be as low cost as possible. You simply could not achieve glassy-smooth scrolling and other near-instantaneous UX otherwise.

I seriously doubt that you've ever built a desktop/mobile application given that you "can't think of an application I use on a daily basis that can't be done equally well in the browser.".