Ok, probably spent too much time there than was necessary. "We" (whoever was there) ended up with a few faces which evolved into pimps which evolved into splodges which evolved into me trying to make the whole thing yellow.
The video of the product looks great, so I go to edit one of the examples and choose "Import to Vector Editor" and then a window loads asking me to install Adobe Flash 10 and I think to myself, why on earth would anyone create an Adobe Creative Suite killer written in Adobe Flash?
I have absolutely no artistic ability or desire to buy an iPad -- but put that on it and I might. Its like being a little kid again and discovering fingerpaint.
There is a veritable flood of tutorials nowadays that you can download or buy on DVD that can teach you how to draw or paint, even sculpt. And the materials needed for drawing are pretty minimal. Time + practice. :)
A question for you guys: What is the best way to learn about and start playing around with HTML 5. And how long would it take to produce something like this?
I see that you added the IEcanvas code to the source, but it looks like you might need to do some more IE testing. I see 3 javascript errors followed by a black screen in IE8.
It won't be long before all applications are written in HTML/CSS/JS. This is beautifully done and should definitely convert more open standard web stack doubters.
I abandoned pure standards-respecting HTML5/canvas while working on a similar tool (for pixel art, not general drawing), for reasons which will readily become apparent when you try to save a file... then load one.
Flash is still quite useful because desktoppy apps have legitimate needs which are thwarted by the browser's rather uptight security model, but are mostly satisfiable with Flash's controlled way of enabling them.
This is amazing. I'm building a little canvas drawing tool myself (http://kritzl.robsite.net -> 'Mal was') and this is great inspiration. Very slick interface and really fast, impressive.
Although the fill tool seems to have a very high tolerance. Fills the whole screen everytime. You could also add line smoothing for the drawing tools. There are reasonably fast algorithms you can use with bezierCurveTo (http://robsite.net/posts/smooth-path-in-canvas).
Well, I think it's more that the mugtug developers have much more they can do - if that's what the want to do.
Don't say that HTML5 (canvas) has a long way to go. It does - but the basis for your argument is wrong. Don't compare two different projects - with different goals, and in different stages of development - and then say one is weaker based on its current phase of development.
I have a PC/Mac/Linux I want cross portability I use trolltech and C++ or something similar. What's wrong with installation? Installation gives me access to a nice operating system with a rich set of API's, threads, memory, file system. I fit's something I want to use I install it. Installation can cause problems with older software that isn't internet aware and can't automatically update itself. That is no longer an issue.
These thing's are cute toys, but really. Let's say I want to make something that can manipulate a raw image (around 100MB) for printing, would I use a browser - well the answer is pretty obvious.
So what is this browser stuff for??? It's cute and fun I agree. But it's not really practical as an image manipulation program. It's a cute distraction for hobbyists. If you want to do real work then fire up your compiler.
Using the browser and trying to get html to do something which is easy to do with a compiler is a distraction. The internet is the powerful thing, forget about the browser and html 5, but use the internet and web standards to enable your software to use web based data stores for collabaration and publishing then you're onto a winner.
...oh and this doesn't run on 99% of machines either :-)
I went through a roller coaster of feelings as I read each paragraph of your post. And then I took a deep breath and re-read it.
So, first - You're taking an unpopular position, suggesting that the future of everything isn't HTML5 - but you do so coherently.
But, the thing is, HTML5 isn't a replacement for thick binaries - I don't believe anyone has suggested that you are going to replace Excel, Photoshop, or AutoCad with an HTML5 App. But, with that said, not everyone needs all the power of those Thick Binaries - lots of people get by with Google Docs, Zimbra, Numbers, and other applications that are "good enough." (Please, before anyone tells me that these applications are competitors for their thick binaries - Tell me how many thousands of hours you've spent on them. Any Excel/Cad/Photoshop Jockey not only knows precisely how limited those applications are, but they also find their smaller competitors unuseable. )
I'm guessing 95% plus of the non-productivity application needs can be solved by HTML5 or it's close companions. What _is_ going to be replaced is Flash. Particularly with the iPad about to come out strong (Mossberg thought it would sell millions of units when priced at $999, with the entry at $779 - He didn't even hazard a guess at what Apple is going to be able to do with a $499 machine) - people who want to write cross platform WebApps are going to _master_ HTML5, particularly with Google and Apple both driving WebKit so hard - now you get Chromium + iPad in one fell swoop - pretty hard to ignore that target environment.
Re: 99% of machines - Probably pretty close to it. How many machines out there can't run a reasonably recent version of FireFox - I'll admit there is a lot of them, but most machines in the last five years probably can.
'But, the thing is, HTML5 isn't a replacement for thick binaries'
If you have a look further up in this post people are suggesting this as far as I can see - e.g. 'It won't be long before all applications are written in HTML/CSS/JS.'
Why use a browser for content creation? Browsers are good for displaying text and graphics, but when it comes to creation sometime you're going to hit the wall - whether it's file size/memory limits/bandwidth limits.
What is the cut point for a browser app - There must be one. At the moment I'm editing and saving some movies I taped on my USB recorder to my PC, so I can watch them later. Will a browser ever be able to do this? it seems unlikely. My previous example about editing a large raw image - it seems unlikely a browser will do that. My day job is writing database apps, will a browser ever do that? seems unlikely, except for some of the front end stuff. So what are the things a browser can do? The more I think about it the smaller the class of applications is - whether it's using HTML 5, 6 or 112.
A browser app is good for
- little apps that aren't too resource intensive
- things that you'd like to access from multiple places (like email), but things like dropbox are way better for a large class - a web enabled native app
- reading web sites
- searching web sites
No matter which way you cut it, there is a class of applications that will never run on a browser. So the argument is where this cut point exists, not if it exists.
(and 99% of PC's could run this app if the people who owned those PC's could install an application called firefox, an application that is tuned for running this particular web enabled application that uses html 5 as it's file format)
I pretty much agree with you - though, I have to admit, things like GoogleMaps, GoogleDocs, are pushing that cut-point further each day.
I know a _lot_ of people who use the GoogleDocs Spreadsheet tools as their only spreadsheet, and gmail is a pretty powerful email client. I'm going to suggest that the cut point is at about 50% of the applications out there today, if we can include code that can be run offline by your browser as well. HTML5 is going to radically move that cutpoint.
Many of the new applications that we use in our company, Jira, Remedy, Confluence, Bamboo, are being built as web applications.
Microsoft Excel on Windows is still about 10x better than any spreadsheet Application out there for people who really need power, but, for 95% of the population - a lot of the web apps will serve them just fine.
Now - where I think we can all agree, is that the _backend_ of all of these webapps, are well and truly going to be thick server apps for the forseeable future.
I agree excel is a better app than google docs. I find the argument that it's just fine for 95% of the population worrying. This doesn't say that the browser is a superior technology, but an inferior technology that 'will do'.
If we turn the tables and I was advocating non web apps because they're good enough for most users, well I'm sure what the reaction would be (I'm being downvoted for advocating a technology that is superior and easier to develop for at the moment - but it seems my water is kool aid free).
I'm not disagreeing that some web apps are useful, and indeed I use them regularly, I'd put the point at closer to 5%, and if I exclude google search we'd be down to 2%. I'm a business user and I'm happy to pay for applications that I use and provide value. But the idea that is being pushed to new developers is that all future apps should be web apps is damaging to the profession and is incorrect.
If we look at the proportion of html based web apps that generate value and exclude search it would be interesting to see what percentage value of application revenue would be generated - 1%? 10%? more, less?
I also note the applications you mention are business apps with a html client and server backend which I agree are suited to an html client. Although I prefer (as do many others) a more responsive native client front end. This uses html as a more advanced 3270 terminal really, which is fine but it's not cutting edge, no matter how it's presented.
So much more could be achieved by using native front ends and just forgetting about the web browser. Look at itunes as an example it's a web enabled app and uses native code.
Perhaps I'm biased - I work for an Enterprise Focused Organization (about 100 Engineers) that builds applications for Utilities. Outage Detection, Network Monitoring, Advanced Meter Reading. We never even considered building any of these tools as thick apps - 100% Web Apps. The Tools we use to manage the builds, file the defects, track customer requests, monitor networks - all Web Applications.
But -your point has merit when I look at the _number_ of applications I use - Around 25 in a given week (Terminal.App, Mail.App (Irony. :-), Colloquy, Adium, Excel, Visio, RemoteDesktop, FireFox, VMware, iTunes, VLC, CiscoVPN Client, Calc, Wireshark, etc...).
I guess, at the end of the day, the question is, what type of user are you - Those of us who are developers, SysAdmins, may be more likely to use a lot of thick clients, whereas people who have a limited number of tasks (Customer Service Representatives, Purely Administrative) may be be more likely to use Web Tools.
I make the argument about technology that "will do" - because I recognize that most people aren't you and I, they really just want to use their computer for a very limited set of tasks and move on. But, your point about turning the tables is well made. Overall, we should recommend the best tools for the job.
It's just that Web Applications, once built, are so easy to deploy across the enterprise. It really is hard to build a decent application that can be (A) Rapidly Deployed to everyone, (B) Be maintained with patches on everyone's system, and (C) Be useful on Windows, OS X, and Linux, _unless_ you deploy it as a WebApp. For some reason, Java Apps never really took off (I'm not sure if you consider Java Apps to be Web or Thick Client - I think they are in the middle.)
And, I agree with you in terms of where I get Value - at the end of the day, when I _really_ need to get some serious content creation or analysis done - It's Excel, Visio, and, interesting enough - my local shell. I'm astonished how, 15 years into technology management, I use awk on 10 Gigabyte files to do critical work. Definitely not a webapp.
So, I guess after reading your analysis, I probably agree with you more than I disagree. In particular, "html as a more advanced 3270 terminal" brings it home for me. The reality is, when I need more than just a terminal onto a back end application, I _do_ use a local thick client, and, I'm guessing that if most of the HN audience reviewed their work habits, they do as well.
I agree it is unfortunate that Java apps never took off, but that may change, or something like java will replace it. Maybe it was a technology before it's time - or promised more than it delivered, it did have it's flaws. Silverlight and flash are trying to take that place, but no one really wants a proprietary solution.
As for the browser it has it's place, but it's not going to replace thick clients and OS's at least not in the near future.
You're making some good points and I give you credit for starting this thread taking a karma beating for it :-) You definately get my upvote.
But here's why I think you might be wrong. Your argument rests an one assumption, which is that the big datasets, the gigabyte size video you're editing, the huge science data set that you want to analyse, etc, originate on your PC.
That used to be the case traditionally and it continues to be the case quite frequently. But I think it may be the exception in a few years time. Video cameras could simply buffer the recordings and stream it right back to the data center. Satellite pictures and other kinds of scientific data could also be stored directly from the sensor to the data center instead of being stored on some PC and then uploaded for sharing purposes. Other types of data that is being analysed today is already stored on the backend and cannot be downloaded as a whole (RFID data, financial trading kind of stuff, etc). It has to be manipulated and analysed on the server.
If most data lives in google's data center the equation changes. It might be impossible to download the entire dataset and then edit it on your PC using a desktop app. The bandwidth argument suddenly favors the browser. High powered desktop computers could be relegated to a few special purpose tasks. Most users might not own machines capable of manipulating massive datasets or video files.
And then you have things like google's native client. It's not like everything client-side has to be written in JavaScript forever. There's not much left that a browser equipped with something like native client cannot do provided the data lives in the cloud.
I agree that more and more data will be stored on servers and will be processed by chunky server code. The point I'm wondering is the browser and html a good tool for accessing and processing this data? I would say no, that a native code app that uses the web infrastructure is superior - a web enabled app.
More so I think there's a lot of time being wasted on trying to get the browser to do things using html as a programming model when it's a lot easier to write native code apps and just forget the browser - call it web 4 (or 3 I've lost track of where we're at number wise).
There's no reason that the browser can't be a component of that web enabled app, just html is not the only way to write applications.
Strangely I was talking to the owner of a medium sized ISV who was relatively technically literate but not a developer. I was saying how you can deliver apps using a native app, the response was 'but don't you have to use html?'. Currently the web is the browser - this is not true, tcp/ip and other protocols existed before the browser, and there is absolutely no reason that http and html has to be the only way we communicate with servers. Indeed I belive the blindness of tying everything to the browser is costing a lot in development. It's time to move on. Keep the browser for what it's good for but don't try and shoehorn everything into a html solution.
If in your argument you say 'web enabled application' instead of browser then I agree 100%.
The main thing the browser has to offer for applications over any binary is a broader set of API functionality. With a binary you have a nasty OS-and-library-dependency rigmarole to go through - with additional hairiness when you're talking about cross-platform applications - and you have to spend more effort to maintain it because every OS changes over time. If it can be built in JS and HTML, you gain a powerful amount of portability, even if you've only written to support only a subset of browsers, and you have some assurance that the code will remain backwards compatible for a very long time to come. Those are both huge wins, and they trump most other concerns for content applications, even if the browser paradigms cause some amount of hoop-jumping to take place.
If you're talking about "infrastructure," of course - compilers, databases, servers - those are reflective of the system internals, so the lower level environment is necessary.
But outside of that domain, browser-apps are the lowest-risk platform available. That's good engineering and good business.
I would really dispute your first statement. The brower has a very limited API compared to an OS.
Cross platform app development is difficult. But then so is getting a complex web page to run on multiple browsers. To my mind cross platform development is a lot more predictable than cross browser development, but I concede I may be in the minority with that one.
But the initial discussion that everything will be done in the browser seems to have gone out the window, so I can live with some things done with a browser and thick clients to do more complex tasks. In time the browser may start to do some of the things a thick client can do, but I won't hold my breath on that one.
Regarding your idea of data being uploaded instantly, or nearly instantly, at generation: I think this is spot on, but I don't think (and I surely hope not) that the data will be uploaded to Google's (or anybody elses, in particular) servers.
Instead, I think (and hope) that the data will be seeded in a manner similar to Bittorrent, and stored in a distributed way.
The big reason I think Web apps will succeed, though, is that it's a common API. HTTP might not be the best protocol for everything, ever, but it's a pretty good protocol. JavaScript might not be the best language for everything, ever, but it's a pretty good language.
The things that our OS:es do for us today, they can keep on doing, and that can be written in C or Java or assembler, but they will eventually have to expose that functionality to the Web platform, if anybody is going to use it.
I think image manipulation applications demonstrate the graphic capabilities of the platform better than anything else. And allegorical language aside, I think web applications are not a reinvention of old solutions, but a reframing of old problems. Hint: the web will kill Adobe's Version Cue faster than it can kill Photoshop. Collaboration is the holly grail.
a very nice showcase of how redundant and useless Flash is, and will be, once HTML5 goes "live". i for one am just eagerly awaiting Flash's total death.
In this episode of the online show "Hak5" they demonstrated some home-brew multi-touch interfaces and they used those to interact with demos built in Flash : http://www.hak5.org/episodes/episode-624
I'm not sure if your familiar with Flash deployment services like Mochi Media but one of the biggest features they give Flash developers is their encryption which is not currently broken. What this means is that the Flash games you develop cannot be decompiled. Even the regular Flash apps you see out there have just a slight barrier to entry to decompile and come out the other end with working code. This kind of safety is comforting to developers. HTML will never have even a little of that saftey.
You should take a look at the minified/obfuscated source that Google's Closure produces. It really isn't much better than looking at a disassembly of a C# binary, as far as clarity goes. And all that in the name of minifying the source, not obfuscation.
Oh I'm all for HTML5, on the other hand I'm still having to support IE6 for my work and even then IE7 and IE8, it will be many years before I can fully move to HTML5 and by then I'm sure I'll use whatever tool is best for the job of making web applications for use across browsers and platforms.
I don't see why we won't see Flash and HTML5 and Silverlight and Java applets for games still going forward. It isn't a either or situation as I'll still be able to contain Flash/Silverlight/Java inside a HTML5 compliant page.
Its distinct feature is the real-time display of other people drawing on the same page. You might want to check it out if you like this.