HTML5 Canvas based fast painting app
mugtug.com
mugtug.com
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.
Though, if you want to draw on your own or with just people you know, you can create a new picture and share the URL with just the people you want.
Only thing I could suggest improving is letting the pad take up more of my screen size.
Are you planning on opensourcing the project?
I could write a more technical blog post at some point how it's done, if more people should be interested in that.
Thanks for the link!
Edit: It actually got somewhere: http://imgur.com/M8elJ.png
I went back to the site and had another look.
Poor Adobe.
XO1: running Ubuntu/XFCE/Chromium/MugTug's sketchpad. Painting with XO1 is way fast. No screen drag. None.
XO2: running the native Sugar paint app. Roughly the same feature set. Screen drag.
Edit: would be nice to have pressure sensitivity for my tablet and ability to edit SVG nodes.
And a pressure sensitive extension would require some sort of modification of the available web tools, afaik.
They are fundamental complaints about canvas thus far generally, although I note colorillo.com can at least save in SVG.
Otherwise, this "cheat sheet" helped me the most: http://blog.nihilogic.dk/2009/02/html5-canvas-cheat-sheet.ht...
The tools just aren't there yet, I'd rather develop in plain js+canvas for now (for which you can get decent editors, debuggers, profilers, etc.)
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.
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.
http://googlereader.blogspot.com/2010/01/follow-changes-to-a...
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).
selection tool defaults to 7 sided poly, which is not intuitive, and seems to move against the user's intention a bit.
That is if you want to actually do work with it and not just play around.
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 was simply commenting on some of those "Poor Adobe" claims. And in that light it is perfectly rational to write what I wrote IMHO.
I see things like this and wonder what on earth web guys are wasting there time on.
Yeah, web guys are wasting their time on portability, trivial distribution, standards compliance, and keeping full control over their applications.
even though it doesn't need to go to any destinations off that highway,
and when it was already rolling faster on client-side boulevard
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 :-)
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.
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 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.
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.
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.
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.
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%.
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.
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.
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.
how many people use Flash to play casual web games? Hundreds of millions.
I think your conclusion is misdrawn.
I see how it's an advantage, but I think if that's the full extent of why flash will win long-term for minigames, you haven't swayed me very far.
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.
how many people use Flash to play casual web games? Hundreds of millions.