Box.net CEO: HTML5 could kill desktop software(venturebeat.com)
venturebeat.com
Box.net CEO: HTML5 could kill desktop software
http://venturebeat.com/2010/05/28/box-net-html5/
17 comments
Only tangentially related, but a great article on debugging PHP in vim by one of the other co-founders of box.net: http://tech.blog.box.net/2007/06/20/how-to-debug-php-with-vi...
Hope some of my most used software gets ported onto this new 'HTML5 thingy' before it gets killed!
- Matlab/Mathematica - Photoshop - Blender - America's Army - OneNote - LinqPad - ...
(bring on the pain)
- Matlab/Mathematica - Photoshop - Blender - America's Army - OneNote - LinqPad - ...
(bring on the pain)
Haha!
Well, I don't know how much we have to worry about production oriented software disappearing.
From what I see, the web has caused a shift in the production of cultural content, away from centralized media industries to something resembling cottage industry. Wouldn't there be a rise in production oriented software to meet the demands of creators needing better, faster, and easier tools?
Let's face it, the web is never going to take over for production oriented software. People will need to be squeezing every last calculation out of their hardware while they're making things and they need feedback without delay.
You couldn't work in Illustrator with a 50ms delay, so where do you draw the line for what is computed client-side and what on the server? Sure, filters could be processed server-side. But complex drawings, taking up lots of RAM, constantly requiring a re-render?
We don't even need to talk about server-side audio production.
It's not that there aren't tools that work just as well or much better when served in the cloud, it's just that there will always need to be tools that demand to be run as close to home as possible.
It seems to me that the amount of people wanting to use production oriented software is going to grow at least at the pace of consumer oriented software.
Well, I don't know how much we have to worry about production oriented software disappearing.
From what I see, the web has caused a shift in the production of cultural content, away from centralized media industries to something resembling cottage industry. Wouldn't there be a rise in production oriented software to meet the demands of creators needing better, faster, and easier tools?
Let's face it, the web is never going to take over for production oriented software. People will need to be squeezing every last calculation out of their hardware while they're making things and they need feedback without delay.
You couldn't work in Illustrator with a 50ms delay, so where do you draw the line for what is computed client-side and what on the server? Sure, filters could be processed server-side. But complex drawings, taking up lots of RAM, constantly requiring a re-render?
We don't even need to talk about server-side audio production.
It's not that there aren't tools that work just as well or much better when served in the cloud, it's just that there will always need to be tools that demand to be run as close to home as possible.
It seems to me that the amount of people wanting to use production oriented software is going to grow at least at the pace of consumer oriented software.
I think you are kind of missing what is going on with a lot of html 5 development. There is actually little need to communicate with the server with a lot of web apps. Like illustrator, look at Aviary (I think they use flash right now) but the application is in the browser but all computation happens on the client, the only communication with the server would be to save the file. I see this being the same way with audio/video etc. There is the overhead and the performance issues, but not really a delay.
I hate to drag this point up again, but the most advanced HTML5/Javascript demos are a poor imitation of what could be done on the desktop 10 years ago.
My personal view is that the web is good at things which are inherently communication centric. Nothing else justifies the restrictions that working within the web browser brings. Flash might be the whipping boy of internet technologies, but at least its reasonably write once.
I think the thin client architecture is a paradigm that will constantly cycle in and out of fashion but never quite deliver on its promise.
My personal view is that the web is good at things which are inherently communication centric. Nothing else justifies the restrictions that working within the web browser brings. Flash might be the whipping boy of internet technologies, but at least its reasonably write once.
I think the thin client architecture is a paradigm that will constantly cycle in and out of fashion but never quite deliver on its promise.
Matlab? Mathematica?
http://www.sagemath.org/ http://www.monkeyanalytics.com/
I am not sure what "HTML 5" has to do with analytics software though. I usually don't need video or crazy mouse capabilities when doing statistical analysis.
http://www.sagemath.org/ http://www.monkeyanalytics.com/
I am not sure what "HTML 5" has to do with analytics software though. I usually don't need video or crazy mouse capabilities when doing statistical analysis.
There is a mathematic plugin, that let's you view & play with mathematica files online.
I guess what the original poster meant, was instead of plugin use HTML5, but I dunno whether that's going to work for Mathematica (performance wise).
I guess what the original poster meant, was instead of plugin use HTML5, but I dunno whether that's going to work for Mathematica (performance wise).
I imagine Blender could be ported straight into NaCl, for one.
It can but what's the point? Some of these applications are dealing with lots of temp files, huge textures, models, etc.
What would putting it under web page do for it? People might get confused that they can switch machines and continue working with their files, while in fact this is not possible.
HTML5 is cool, but for some (powerful) users plain-old shrink-wrapped software is better, especially if that software is dealing with data close to gigabytes (CAD, Image processing, etc.), or if that data is shared adhoc (there are special versions of Maya where instead of saving/loading to the file system, everything goes through a specialized file I/O - this might come a custom solution from Autodesk, or some other way).
I work in game company, and the only web applications that we use are the ones that make sense to be used from there: - Bugtracking - DevTrack or Bugzilla - Some custom statistics server - Intranet pages - vacation forms, etc.
Everything else is native Win32, or Win64 apps - MFC, wxWidgets, Qt, .NET, Direct3D, whatever there is. I doubt we'll switch this way, as moving some of these apps to the web is simply "NEW" to us, and we still don't trust it enough.
Every app you move from shrink-wrap version to the web - you need a server - every server in an organization needs someone to take care of it - what happens when it needs to be rebooted? what happens if it goes down?
It's way safer for certain apps, to be as they are.
For example I can't wrap my head of using P4 (Perforce) over the web interface - yes it's there - but I prefer (the obsolete now) P4Win32.exe
What would putting it under web page do for it? People might get confused that they can switch machines and continue working with their files, while in fact this is not possible.
HTML5 is cool, but for some (powerful) users plain-old shrink-wrapped software is better, especially if that software is dealing with data close to gigabytes (CAD, Image processing, etc.), or if that data is shared adhoc (there are special versions of Maya where instead of saving/loading to the file system, everything goes through a specialized file I/O - this might come a custom solution from Autodesk, or some other way).
I work in game company, and the only web applications that we use are the ones that make sense to be used from there: - Bugtracking - DevTrack or Bugzilla - Some custom statistics server - Intranet pages - vacation forms, etc.
Everything else is native Win32, or Win64 apps - MFC, wxWidgets, Qt, .NET, Direct3D, whatever there is. I doubt we'll switch this way, as moving some of these apps to the web is simply "NEW" to us, and we still don't trust it enough.
Every app you move from shrink-wrap version to the web - you need a server - every server in an organization needs someone to take care of it - what happens when it needs to be rebooted? what happens if it goes down?
It's way safer for certain apps, to be as they are.
For example I can't wrap my head of using P4 (Perforce) over the web interface - yes it's there - but I prefer (the obsolete now) P4Win32.exe
Production apps will ultimately be ported to the web if things like NaCl take off. Porting current apps to the web as they are with the goal of having them in browser, have them run inside Chrome OS won't change much of course. But that's an unimaginative take on the possibilities.
The real point of porting to the web is to make these apps accessible to more people. To apply web workflows to their development, like change their UI after monitoring analytics, ship often, etc..
Large production apps like Photoshop can be split off into thousands of modules, which will be loaded only when the user is using a particular feature. That's a very different development process, currently Photoshop is developed for CDs, one big ship date, one big upgrade, all features in, want them or not.
The way apps are paid for could also change. If you're not using certain features, you shouldn't be paying for them, shouldn't be investing in their development while features you do use are neglected.
It's not really the technology of the web that will bring about such changes. NaCl mainly enables you to run normal binaries, as you already do on the desktop. The real change will come from people rethinking how they make and deploy apps.
The real point of porting to the web is to make these apps accessible to more people. To apply web workflows to their development, like change their UI after monitoring analytics, ship often, etc..
Large production apps like Photoshop can be split off into thousands of modules, which will be loaded only when the user is using a particular feature. That's a very different development process, currently Photoshop is developed for CDs, one big ship date, one big upgrade, all features in, want them or not.
The way apps are paid for could also change. If you're not using certain features, you shouldn't be paying for them, shouldn't be investing in their development while features you do use are neglected.
It's not really the technology of the web that will bring about such changes. NaCl mainly enables you to run normal binaries, as you already do on the desktop. The real change will come from people rethinking how they make and deploy apps.
This "death of desktop" talk has been around a long time, and we'll rinse-repeat until we're blue in the face, but this just isn't the case at all.
HTML5 will be the death of Flash and Silverlight as we know these products today. That doesn't mean the product by name won't exist (think jQuery-esque like platforms for HTML5), it will just change forms.
That's my guess anyways.
HTML5 will be the death of Flash and Silverlight as we know these products today. That doesn't mean the product by name won't exist (think jQuery-esque like platforms for HTML5), it will just change forms.
That's my guess anyways.
I almost never use drag-and-drop for anything because it only works if my windows are arranged just so.
I'd be curious to know how normal this is. Maybe if a lot of websites implement it, we'll be able to get some real stats on how often it actually gets used.
I'd be curious to know how normal this is. Maybe if a lot of websites implement it, we'll be able to get some real stats on how often it actually gets used.
In Mac OS X drag-and-drop is convenient even with small screen sizes because of "spring-loaded" folders and Dock icons, so you don't need a special arrangement of windows. I often use it by dragging an item into a Dock icon, pressing Space (or waiting a second), and then dragging on the window once it opens.
It works great with Exposé as well.
Just so you know, the major insurance company I'm related to is still using IE6 as its standard browser.