joehewitt

It's rarely at #1, but it has been a permanent fixture in the top 20, while most other apps are only on the chart for a short time. That adds up.

My point wasn't that Linux or Python or jQuery own their sectors. I responding to your claim that a single owner promotes stagnation.

It's important to distinguish the Internet from the collection of web technologies. The Internet is the thing that needs to remain open and uncontrolled.

Hell yeah, they had data binding in the 90's. Was ahead of its time, like XMLHttpRequest, but never caught on.

http://msdn.microsoft.com/en-us/library/ms531385(v=vs.85).as...

It gave us Chatroulette! :)

Yeah, the checklist of web technologies is getting longer, but that's only part of the solution. They don't all work together very well. For example, Alex Russell has been opining recently about the way DOM interfaces are awkwardly adapted to JavaScript due to the committee's insistence on targetting IDL. That's why the W3C could never have invented jQuery.

I've been trying to duplicate native scrolling in iOS recently and I'm getting killed by details that the specifications don't cover and WebKit authors don't document. For example, tons of trial and error uncovered the fact that CSS keyframes animations are unusable for elements wider than 1024 pixels, due likely to OpenGL issues on iOS. If the W3C and WebKit had any clue how developers would actually use the stuff they design, they would have made this fact clear by at least providing a way to query the optimal texture size used under the covers.

Over and over you find little examples like this which demonstrate that the web's "leadership" is completely disconnected from reality on the ground.

It didn't take a seer to imagine that having camera access was a good idea, but it takes a pretty boneheaded committee to wait this long to do it. Hell, Adobe put camera access in Flash years before iOS even existed. I don't love Flash, but even they benefitted from have a single owner.

Lots of good things coming to the platform now, but progress was even faster in the mid-90's when Netscape and IE were growing up. IE4 and IE5 in particular had a lot of great features that have since been forgotten, and are only now being reconsidered for standardization. Remember behaviors, image filters, CSS expressions, and data binding?

Has Linux stopped improving? Has Python stopped improving? Has jQuery stopped improving? It all depends on who the owner is.

I clearly stated you need more than just a single owner, you need a single owner that is competent and cares. We can't just snap our fingers and have that, but I'm hoping to at least help people to start thinking about it.

You're right, it's not the best sentence I've written in my life. Thanks for the feedback.

I was trying to convey that the web is always going to have to fight for its survival, contrary to the common assumption that the web has some magical properties that ensure its long-term prominence.

The W3C writes specs, not code. They do not own the actual rubber that hits the road, and so they are only indirectly responsible for what happens on the real web. I want to remove the separation of architecture from implementation and have one entity control both.

Exactly the kind of arrogance I cited. You don't want to risk a bad owner so you'll let the whole thing die from neglect by committee. I would rather have Microsoft be the only browser vendor than have the web shrink dramatically.

Sorry if I didn't make it clear I meant the web will never be the dominant platform in the future once the current trends play out. I am aware of current market share proportions.

HTML is capable of anything, given the makers of browsers will it to be so. There's nothing inherently special about "native" technlogies, other than OS makers tend to give new features to the platforms they own first. It doesn't have to be this way, but will probably remain so, because the leading OS makers (once Microsoft, now Apple) have the discretion to throttle the flow of new goodies into their web browsers, and it would seem they often do. Really, how else can you explain the fact that Safari in iOS 5 still lacks the ability to utilize the camera?

Are any of the big registrars trustworthy? I'm trying to consolidate all of my domains on Namecheap right now. I transferred one domain from Dyndns and they did the transfer within a few hours (nice!). Then I went to transfer another from Network Solutions and four days later I am still waiting. Do they think I'll change my mind if they refuse to release the domain for a week?

I recently wrote something just like this for Node.js:

https://github.com/joehewitt/markdom

It's used on http://uponahill.com to extract Flickr urls so I can query the Flickr API and get complete metadata about each photo. My gf, who does most of the writing/photography on the site, has found writing in Markdown and copy/pasting Flickr urls a pretty frictionless experience compared to the Wordpress CMS.

I'm excited by OnSwipe's potential and I'm optimistic they're going to get it right eventually. For me, the biggest problem has been that OnSwipe makes no attempt to handle URLs correctly. URLs from the desktop version redirect to the TOC on iPad. When you visit articles on the iPad, the URL bar is not updated, so you can't even bookmark or share what you're looking at. Once they get this right, I think a lot of the grief expressed on HN will fade away.

When you scroll horizontally, you're indicating that you want to see more photos, so naturally the text should disappear. When you scroll vertically again, you're indicating that you want to move to the next post, so naturally the text should appear again. You're free to scroll horizontally or vertically at any time, and the result is pretty consistent if you do. What you call "forcing the user" I call "making educated guesses about the user's intentions".

I made it so you have to scroll the text a little bit further so that the photo would stay pinned down long enough that you could see it, and scroll horizontally to the other photos. You're right, though, that page up/down (and arrow keys) would be a nice way to nav also.

The goal here is not to be "truly innovative", but to emulate scrolling behavior which should ideally be performed by mobile WebKit, but isn't. But I must have done a good job since you only notice the background image being pinned, and not the fact that (at least on an iPad) the entire page is being scrolled with JavaScript. Also, try scrolling horizontally.

It will work on Android as soon as I get some Android devices to test with. It should currently "work" on Android, but probably not well.

Make sure you're on the latest version of Chrome (12). The new hardware acceleration is necessary for the large photos to scroll smoothly.

I assume you're testing on an Android device then... I don't have one to test (but I will soon), so I'm not surprised it doesn't perform well there.

Anyway, the current code is trying to replicate the feel of iOS scrolling. An Android implementation should try to replicate the feel of Android scrolling, which is much different. I will get around to it...

Libraries like these should not be necessary, but since Apple has not implemented proper scrolling of elements and iframes, we're left to do it ourselves. Perhaps iOS 5 (just two weeks until wwdc!) will solve the problem and make this project obsolete (I hope so).

Even if they do, libraries like these may still be necessary for more advanced scrolling mechanisms like those that snap to page boundaries or involve scrolling/zooming hybrids (like photo viewers common to many apps).

Making it easy to save Firebug CSS changes back to the source file was at the top of my todo list in 2007, and I was really bummed that I didn't get the chance to build it. Years later the Backfire extension came out, which does alleviate some of the pain of saving CSS, but I still think there's room for improvement.

There is definitely an opportunity to create an amazing HTML5 IDE, but I also think that smaller and more focused tools have value. I intend to avoid the temptation to try and boil the ocean so that I can actually ship something useful this year.

That's a disappointing attitude. Let me give you a great counterexample.

Chrome was initially a completely fork of Webkit, but Google eventually chose to work with Apple and merge all of their changes to the Webkit trunk. This was only possible because Webkit, unlike Android, allows outsiders to commit.

The costs of maintaining a fork of a project as large as Webkit (or Android) are so huge, even Google didn't want to bear them for long. The benefits of the merge are huge for all users. Not only does Chrome continue to get Apple's changes downstream, like CSS transforms, but Safari gets Google's changes, like web sockets. In Android today, this sort of collaboration would be impossible.

I am obviously expecting that in a few years time Android will suck much less, or I wouldn't bother investing time in it.

I never said it was "hard", just that I was surprised that the simple task of "get me this URL" required me to work with some abstract classes for "async tasks". Strikes me as overengineering. The networking classes could easily encapsulate the threading stuff and let me just stay on the UI thread, as every other networking library I've ever worked with has done.

I've found other places in the Android SDK when, rather than simply using callbacks to encapsulate asynchronous work, I'm required to deal with the threads myself (see GLSurfaceView). You can accuse me of being "confused and ignorant" but I feel I am making a valid critique of the API design.

That is true, but it is much easier to accurately implement a VM spec correctly than complex high-level specs like CSS and HTML, which leave a lot of ambiguity. New hardware interfaces are also a lot easier to specify when you're talking about functions which are rarely going to be called directly by human programmers, since they will usually be accessed through higher-level frameworks.

Overall, the goal is to make implementing a browser a much simpler and direct process, and to defer as much complexity as possible to libraries which can be easily downloaded and updated. This would not only result in more a heterogeneous ecosystem for web developers, but fewer browser bugs and incompatibilities.

This isn't just about replacing JavaScript with a CLI VM. It is about replacing the entire web stack, from HTML, CSS, and SVG all the way down to JavaScript.

The primary benefit of this would be that high-level languages like HTML would be implemented on top of the VM, and would no longer be hard-coded into the browser. This would allow you to, for instance, link to the latest version of the HTML runtime the same way you would link to the latest jQuery. This would mean that we would no longer have to wait for the browser vendors and standards bodies to bring us cutting edge technologies. This would also mean that alternative UI toolkits and languages would play on the same level field as HTML and JavaScript.