Disqus - Latest Comments for tolmasky

Re: alert debugging — Patents and Juries

tolmasky — Wed, 29 Aug 2012 17:52:38 -0000

Yeah I was actually thinking of proposing something similar in a later blog post -- essentially trying to have something that more closely models the peer-reviewed system that scientific journals use. Scientists respect the results of peer-reviews because their own community is making them, and its usually 3 peer reviewers and not just one.

Re: alert debugging — The Promise of the Web

tolmasky — Thu, 22 Sep 2011 22:53:49 -0000

I've been in this business a while actually. I was on the original iPhone team and wrote Mobile Safari. So as it turns out, I know how these things work from both sides of the equation.

Secondly, all your examples of "contributing" are trivial. It's like saying "want JavaScript to have a fibonacci function? Just write it! See you really do have a say in things! It's that easy." OK, great.

PhoneGap represents exactly the opposite of what I want from the web. PhoneGap is transforming a web technology and making it into an inferior native technology. PhoneGap only works in the little native wrapper they write, oh and by the way, I have yet to see any impressive PhoneGap apps. Let me know when something that is charting in the app store is written in PhoneGap then *maybe* we can have a discussion. I'm also not aware of very many significant technologies PhoneGap has created and introduced which then made it back into the browser. I'm still waiting on that camera API to finally become available... This of course being a straw man issue altogether because PhoneGap is simply providing features that *already* exist on native (and are oftentimes already proposed in a spec). So yeah, maybe someday they'll make it into the browser, but it won't be because of PhoneGap.

Those public forums for discussion you speak of rarely involve actual web developers because the process is so frustrating. For a little humorous reading, go find the thread where the query selector was denied long before jQuery existed (because why would that be useful?), and just think of all the man months (years?) that resulted in wasted developer time trying to micro-optimize in JavaScript.

Re: alert debugging — The Promise of the Web

tolmasky — Thu, 22 Sep 2011 22:19:03 -0000

There is no misunderstanding here, you simply like the way things are (slow, and inevitably always behind competing technologies), and I don't. I'm not trying to have the standards bodies predict features - I agree, they are terrible at writing features. Quite the contrary, I would simply like a way for us the developers to implement those features ourselves instead of having to beg for them only to have them show up in a semi-functional state upwards of a decade after they were needed. Had the iPhone existed back in the day, YouTube may have been a solely native phenomenon (the way check-in based social networks are almost entirely mobile native today).

It's fine, the web can clearly exist the way it is, just don't be surprised if it loses more and more ground to native. 5 years from now people may be self publishing blog apps instead of sending you a URL. Might seem crazy now, but I would have said that nytimes making a native app was crazy 5 years ago too. If you are OK with that, then by all means continue to support the current process and infrastructure.

Re: alert debugging — The Promise of the Web

tolmasky — Thu, 22 Sep 2011 22:05:27 -0000

There is absolutely something stopping me and you from innovating and having that widely adopted as a standard.

For starters, how exactly do you propose we innovate? We create our own mini browser for every little feature and try to get enough adoption? This is impractical - there is no way to do this. At BEST you can try to get your feature implementation accepted as a patch to one of the existing open source browsers - but here there is still a gate keeper. Notice that no new feature has ever been developed in the way you describe -- as something individual developers have independently created, tested, and then had move in to mainline. It has always been introduced by one of the big major players (such as Apple with canvas or Microsoft with XMLHttpRequest).

Also, your statement about no corporate ownership is laughable. There is a ton of corporate ownership. Right now web standards are much more influenced by corporate interests than anything else, or have you already forgotten the *endless* fights about which video codec we should use for HTML5, which ultimately resulted in a completely fragmented implementation. Did you have a big say in that? Of course not, it was all political infighting. Right now, if Apple or Microsoft were to decide that feature X was counter to their business' interests, they could effectively kill it and there's nothing we can do about that.

I don't understand where you're coming from regarding everybody's opinion counting and all of us agreeing, and none of these technologies being imposed on us. I don't recall being asked my opinion on any of this. I don't recall to agreeing to any of this, and I certainly would call the current state of affairs as these technologies being imposed on us by a very small minority (which happen to control the browsers of course). Compare this to Rails, where anyone can fork, actually demonstrate a feature, and force the owners to adopt it. Plugins used to be an outlet for us to do this (this is basically what Adobe did with video on Flash). No longer.

I think an interesting exercise for you would be to try to submit an idea to the W3C. After successfully doing that, come back and tell me about what a great democracy web standards are.

Re: alert debugging — The Promise of the Web

tolmasky — Thu, 22 Sep 2011 19:35:40 -0000

Again, my main point is not to destroy HTML, and I don't think that's what would happen. Day 1 of this new technology would not be everyone scrambling to write new alternatives to HTML, that would be SEO suicide. My main goal is to make the development of HTML truly democratic the way most open source projects are.

If you look at the revolutionary changes in the web, they all happened this way. Canvas came about because Apple decided to add it as a completely proprietary extension to Dashboard. Microsoft (!) added XMLHTTPRequest. All of these were ground breaking on the web, and completely unpredicted by standards bodies. Would you like me to link you to the famous discussion thread where built in query selectors were denied long before jquery existed?

Now, imagine if all of us had the ability that only a few browsers have now - to add features we thought were important without asking permission. Imagine if tomorrow I could start implementing Cocoa's new automatic layout in HTML, perhaps by adding francisco-layout: to CSS. This would change HTML and CSS very little, and be mostly a *renderer* change. Instead, today I have to be content with whatever the browser vendors deem worthy as a proper CSS addition.

Re: alert debugging — The Promise of the Web

tolmasky — Thu, 22 Sep 2011 19:30:04 -0000

There are competitors, lots of them. They're called native, and from where I'm sitting, they're winning.

Re: alert debugging — The Promise of the Web

tolmasky — Thu, 22 Sep 2011 19:28:41 -0000

As I said in the article, I have spoken to Joe a number of times about this, and I even had him read this beforehand to make sure I wasn't putting words in his mouth. All that to say, I really think he and I are in agreement about this stuff.

The point about Apple providing compilers is an improper analogy. The correct point is should Intel be designing high level API's? Of course not, Intel precisely only provides an instruction set and a compiler and allows everyone else to write the abstractions they see fit.

Re: alert debugging — The Promise of the Web

tolmasky — Thu, 22 Sep 2011 16:11:27 -0000

I feel you may have misunderstood my argument. I went into explicit and lengthy detail about how what we need is multiple owners, in other words, true community involvement.

Re: alert debugging — The Promise of the Web

tolmasky — Thu, 22 Sep 2011 16:09:48 -0000

A point I didn't make in the article is that plugins also provide an outlet for niche markets. Even if you're point is correct (I'm not sure it is, but more on that later), plugins can still provide functionality for mathematicians or economists who have very niche desires (such as presenting LaTeX -- not the greatest example but you get the idea). Standards bodies and browser writers are swamped as it is and don't have time to accommodate for a lot of these things. Its not fair that just because they do not have a general population attraction they shouldn't be allowed on the web. Here very niche plugins employed by small communities would be fantastic.
To your actual point, there was a lot of "necessity" back in the IE days and I didn't see a lot get done. Remember, individual corporate interests are also at play here. If we had a dominant browser vendor who had a competing video service, it wouldn't matter how much we "need" video on the web, they'd actively work against it, its happened before.

That's why I think the standards actually work best when balanced by plugins. Plugins provide a quick entry to market, allow us to make mistakes, and then once its clear this is good and necessary, it can make its way into the standards. Realize that HTML5 video is still not fully deployed or implemented even today -- its been a *long* time.

Re: alert debugging — The Promise of the Web

tolmasky — Thu, 22 Sep 2011 16:04:43 -0000

So, two points here:

1. I think the key to interoperability is actually plain text transmission. As long as the web was fundamentally about pushing text across the wire, Google could still index everything. So basically, imagine a new low level file type, where you "included" HTML, CSS, and JavaScript. So if someone invented a new markup language, or not even, just imagine someone deciding that markdown should be a first class language on the web. Those files would still be indexable.

2. Most web pages would still be written in HTML. My goal is not to get rid of HTML, just allow for it to be community maintainable (like jquery). If, for whatever reason you invented your own set of languages to do something really out there (like Mario Brothers on the web or something). Then sure, *maybe* it would be less indexable -- but that is already the case today since right now it would just be a big gob of JavaScript. I think the web I'm proposing (provided plaintext transmission) is strictly as interoperable and indexable as today's.

More importantly though, I think the point of my blog post is the premise: that there is a problem with the web. I'm not sure if my admittedly not fleshed out solution is the best, but I think right now most people don't even think there's an issue period.

Re: Introducing Jake: A Build Tool for JavaScript

tolmasky — Wed, 28 Apr 2010 15:13:34 -0000

We are running CommonJS on narwhal (http://narwhaljs.org), which supports a number of engines under the hood, including Rhino and JavaScriptCore (and V8 to a degree as well I believe). And yes, we recommend it, we've been using it for months now, and under JSCore its very fast, and it includes the tusk package manager that makes getting things like jake very easy. If you look at the end of this article, we explain how you can install narwhal.

Re: Cappuccino 0.8

tolmasky — Sun, 11 Apr 2010 03:38:54 -0000

Yes, framework images are also sprited. Basically, we generate one file per "bundle". That means that in a typical application you'll have something like the AppKit images and the main app images. Press is already capable of taking all the code from different frameworks and combining it into one with your app, our next goal is to do the same with images.

Re: Internet stocks Predictions for 2020 (GOOG, AMZN, maybe FACB?)

tolmasky — Tue, 05 Jan 2010 16:23:05 -0000

Apple's stock symbol is AAPL not APPL

Re: alert debugging — Mockingbird, Cappuccino, and what really matters.

tolmasky — Tue, 17 Nov 2009 21:04:45 -0000

We are definitely looking into this, I haven't replied because I think it deserves an entire post of its own, which I will be putting together once Atlas work cools down a bit.

Re: alert debugging — Mockingbird, Cappuccino, and what really matters.

tolmasky — Thu, 05 Nov 2009 04:10:14 -0000

We are one of the few frameworks that goes out of our way to make it clear when *not* to use. You are precisely correct that cnn.com and nytimes.com should not use Cappuccino. Take a look at any of my presentations and you will see that this is precisely the first thing I always say.

The reason for Cappuccino is that just as I wouldn't want a "widgety" cnn.com, I also don't want a "pagey" powerpoint or photoshop, it would be equally terrible. This of course holds true of Mockingbird as well.

Re: alert debugging — Mockingbird, Cappuccino, and what really matters.

tolmasky — Wed, 04 Nov 2009 19:07:54 -0000

It all depends on your audience. Mockingbird is a design app, and I'm willing to bet that the target audience probably either runs Firefox or Safari. Thus all those grandmas and teenagers using IE don't really make a difference. In fact, you may very well be doing yourself a disservice in using Flash, since Flash, when idle, has been known to choke up over 50% of the CPU. That's right, my *entire system* gets slower thanks to Flash on Mac OS X running as a separate process in Snow Leopard. There's a reason people have clicktoflash installed. You shouldn't provide a detrimental experience to the people most likely to actually pay for your app just to maximize exposure to people likely not to use it.

The opposite is of course true: at least today, there is no "one true way", it depends on the app you are making.

As an aside, Cappuccino does work in IE. I have not looked at Mockingbird's code so I don't know why they chose to release the *beta* to just non-IE browsers for now, but as they've stated they will.

Re: Building a Better JavaScript Profiler with WebKit

tolmasky — Tue, 05 May 2009 02:11:08 -0000

There is a bug on this and my fix just got accepted: https://bugs.webkit.org/sho...

Re: Building a Better JavaScript Profiler with WebKit

tolmasky — Fri, 01 May 2009 15:43:36 -0000

One workaround to needing to keep a pointer around that I've already seen people use is something like this:

function named_f(aName, aFunction) { aFunction.displayName = name, return aFunction; }

Which would allow you to do:

named_f("myFancyName", function(){ blah; })

However, the idea here is certainly not to replace all existing circumstances that already work just fine, but to provide you with a new tool for the cases when they don't work, or the cases where generation is handling the task so you don't really need to worry about how much typing it is. Joose and Objective-J are really good examples of this as they simply auto generate the names for you.

Re: On Leaky Abstractions and Objective-J

tolmasky — Mon, 08 Dec 2008 23:31:15 -0000

He means 280 Slides, our application: http://280slides.com

Re: XMLHTTPRequest, JSONP & Cappuccino

tolmasky — Thu, 09 Oct 2008 03:42:43 -0000

Absolutely. In fact we use PHP in 280 Slides.