Security on one server, ran by someone that knows what they're doing, will be better than what we have now, which is thousands of webservers ran by people who have almost no idea what they are doing and no time and money to dedicate to doing it right.
Take a look at what servers get hacked. It isn't often those that are well maintained by trained people with years of experience. It's usually people stupid enough to run a server that hasn't been updated in three years.
The trick is to make centralized copies of important, or oft used, files available. I'd not just do DTD's. I think as AJAX, Web 2.0, or whatever you wanna call it, grows more popular and demands users download more and more Javascript, images, etc that are often the same files between different websites that it could be very useful to them if we stored a copy of those shared files on one server, with caching properly configured, so that users need to only download and store one copy instead of dozens of copies.
You don't have to centralize the originals - just copies. You get the benefits of a centralized resource without the risks of a centralized organization.
I'm planning on building a multi-terabyte RAID5 for my home out of these some time in the next couple months. Now the big question is how I'll make backups. I'm thinking of just using a couple spare 1TB drives as external hdds or maybe making a spare RAID5 in a Mini-ITX case so I can port it around as my external hdd.
I'd like to do a 6TB RAID5 but I'll probably end up with two RAID5's with three 1TB disks each so that I can make my backups.:)
I don't know about in 16 years but I bet within 10 we're talking about the first petabyte drives. I know I'll be able to fill those up too. I could do it now if I could afford to buy the drives and the infrastructure needed to support them.:)
I collect spam to test my AI programs on. I have a bunch of filters that process images into different rpresentations - basically flagging matches to different patterns and building new patterns from combinations of existing patterns. I've experimented with bayesian filters on the output of some of my toys and it seems to work rather well. The filters might output a text string like:
This is pretty simplified compared to what the filters actually output but overall it provides a pretty good bit of text that most bayesian filters can do something with. The filters gather simple information such as the file md5, width, height, times file has been matched, average color, average grey value, color and grey value averages of common blocks, the same color and grey values for everything after the most common color is removed, text recognition, shape reconition, and keys for learned patterns of these different values that are recognized in the image. Other than the md5, width, and height these values change little when scaling, clipping, watermarking, changing fonts, tinting the image, etc. I've trained my filters on millions of images over the past decade and they really work pretty well although I'm always finding new improvements to make.
My goal is to build an intelligent program that can classify and respond to visual input so spotting spam doesn't seem to far a stretch. I have trouble believing that spammers could generate a random enough image to fool the filters while still being usable to humans. Of course, the price is CPU time for the user but most of my filters don't use a lot of CPU time and bayseian filtering dosn't use a lot either so it's really not to bad.
As someone that has a XO (OLPC) I'll say that it is way better than any cheapie laptop I've seen. If it was available for retail purchase here in the US I'd buy several to pass out as gifts. The quality is great and it really has a lot to offer for such a low price tag. I mean it comes with the ability to participate in a mesh network and be connected to a normal wifi AP at the same time, has a decent built in camera, has a pad for pen input, is very durable, is very lightweight, stays cool, has a decent battery life, has features that make it usable as an ebook or handheld game, the software is custom written to take advantage of the laptop and work within its limited specs, and is just pretty damn cute. Every kid I've tested it on has loved it as have most adults. And remember that they actually plan to get production costs down to under $100 per laptop and then start distributing low-cost add-ons such as an OLPC printer. Your average cheapie laptop is not going to be the same.
That said, I can't believe they are distributing the XO to kids already. The software is not done at all. IMO the software is barely usable thus far. Work on the software is progressing pretty fast, and in fact that is why I have an unit, but I would not yet be distributing them with the software in it's current state. I hope they have easy access to the units being distributed so they can be updated as needed.
The problem with page state and back/forward/reload issues is only waiting for an update to the DOM to properly include state information. It shouldn't be to difficult to make it possible for apps to overload those functions to do something that makes more sense in context of their app. Switching to Java, Flash, or whatever does no better because they support those functions even less than AJAX.
Most browsers let you deny scripting from taking over control of your status bar, right-click functions, and other things that can be annoying (at worst you have to download some sort of extension to do this). Again, these are no less held hostage with Java or Flash.
IMO Java and Flash is not Web 2.0 - it's just the same boring stuff that didn't work 10 years ago with few improvements or new concepts. Web 2.0 should not replace Web 1.0. A good web based application should be usable with Javascript and CSS turned off and no plug-ins. Add Javascript, CSS, or even Java and Flash should just improve the application by using the extra functionality that is available.
I'll certainly agree that Javascript, CSS, HTML, etc have limitations. Some of these can be overcome eventually by improving these technologies. Some can also be overcome by making proper use of Java, Flash, etc to give a boost. Myself, I'd rather leave my apps as backward compatible as possible by building a normal HTML app and then layering on Javascript and CSS and then layering Flash and Java on top of those so that with any layer missing as much capability will be retained as possible. So, for example I might use a Flash based sound manager to lend improved audio to a HTML/CSS/Javascript based game, controlling the Flash abiltiies via JS, rather than writing the entire game in Flash. That way if the user doesn't have Flash they only lose sound capability.
It's quite possible to write something like a web based graphics editor using Canvas and SVG but you might want to use Java components as downloadable filters (as sending the entire graphic to the server to process every filter might be to slow) so just have each filter download on-demand. That has the additional benefit of not needing to download a single massive Java app before it can become useful. Of course for something such as a graphic editor there are fewer downsides to a pure Java or Flash based app as you care less about being useful for users without your plugin of choice and aren't likely to care about blind users or search engine placement. Many apps can find a better middle ground though - anything that primarily works with text-based information. Stock trading and spreadsheets I'd say fall into that category of being useful to not require plugins for.
I use LISP, Prolog, Perl, PHP, Python, SQL, and pretty mcuh whatever language I find useful in web apps all the time. It's easy enough to run them on your servers and let them communicate with your web client. You don't even need to use a page refresh anymore to do it. If that isn't good enough you can compile most languages into Java and interact with those components. I know Python, LISP, and Prolog can be compiled to Java so it isn't a shortage by any means. Again, usually you don't need to resort to using Java but in the rare cases it is needed it supplies plenty of power to supplement AJAX apps.
I'll disagree about GMail. It's way less clumsy than Outlook, Thunderbird, or any other email program I can think of. My biggest complaint about it is it's lack if disk space which I doubt many others suffer from. Web apps encourage the author to keep things simpler, easier to use, and less bloated than the authors of desktop apps. That is a real benefit IMO. Email is all about representation of information and that is exactly what the web is for. I don't think there should be a logical difference between web and application. It's all about making it easy to process information and follow the connections between bits of info. If your app can't be fit into that model then maybe there is something conceptually wrong wi
Wait time is hard because most of us are now using broadband of some type but there are always a few people still using dial-up or something in-between, such as connecting over the cell phone network. I generally try to keep the first load time down by turning on compression in my web server, sometime running Javascript & CSS through whitespace/comment strippers, and delaying as much of my Javascript and CSS from downloading until after the page has finished loading as possible. After that, I try to keep things low by supporting caching of my CSS, JS, and images and keeping my HTML reasonably clean and simple. Still you'll always have trade-offs between download speed and functionality.
I don't know that we need a replacement for HTML/JS/CSS so much as we need an upgrade. Javascript Behaviors should be part of the JS standard and not require the downloading of an extra 50Kb of code. Common libraries should be enabled to cache in the browser and be used with multiple websites more easily. All browsers should support sending Javascript and CSS compressed. Stuff like that.
I can't say I've experienced any flakiness with GMail, Google Maps, and other major AJAX apps I've used. Certainly no more than I've exprienced with Flash or Java apps or even a lot of desktop apps. The flakiness usually comes with poorly designed and tested stuff on smaller sites. I usually test my stuff in Firefox, Opera, Safari, IE6, and IE7 and sometimes it can be a pain to get everything working but I'd say 90% of my problems come from IE. This is an IE problem and not a problem with HTML/JS/CSS. Poorly designed and tested code will always be a problem with any language.
My code is typically pretty clean on the backend. The HTML, Javascript, and CSS is largely kept untangled and is easy to work with. I do wish this process would be made easier but again it's an incremental upgrade that is needed more than a total replacement. Communication with a backend server isn't overly complex or tangled either. The biggest issue is to not inline code your Javascript and CSS into your HTML and to make an effort to make sure important features will work without CSS or JS.
Generated code like ASP.NET and other tools produce can be useful but is as much trouble as not for some projects and really limits your ability to think outside the box. I think it's to early in the 'web 2.0' to be trying to solidify a standard of what we can and can't do.
Java, Flash, ActiveX, etc have all kind of sucked due to thir bulk, security issues, installation needs, inappropiate design for rapid application dev, etc. I have used all of them sometimes, when needed, but don't feel they are the right direction to go. JavaFX, to me, sounds like more of the same - gee whiz features with the core issues poorly thought out and worked out. Is JavaFX going to be based on Java? That alone is enough to keep me from using it from most projects. Java syntax is not appropiate for RAD and often web development has to be able to respond quickly to new needs, found bugs, etc.
I wouldn't mind a new scripting language if it would solve these problems, not create new problems, and would work with all current major browsers (Firefox, Safari, Opera, and IE) without using plug-ins or similar bad ideas. I'd probably suggest modifying Python to have built-in DOM support and to allow assigning scripting to HTML/XML using CSS-like behaviors. Possibly making XUL + friends into a real standard across browsers. I'd also vote for forcing SVG and Canvas support in all current browsers as well as adding some built-in audio/video capabilities to the browsers. OBJECT and EMBED are a broken concept and plug-ins suck.
Just making IE follow the actual standards for Javascript + DOM implementation would be a huge step forward in making developer's lifes easier. They have no excuse not to since the implementations used by Firefox and Safari are freely usable.
It's a pretty well known fact that most people would rather use an out-of-the-box solution than try to do things themselves. I can see some businesses running their own servers and some geeky people like us but the vast majority of people would rather have a system managed by someone else on a network managed by someone else. No matter how easy doing it yourself is it's still almost always easier to let someone else do it. Only people that need solutions to problems not yet covered by a service company will probably want to do things themselves. Them and us geeks that like doing things ourselves just because.:)
Of course it's much more price effective for a central company to adminstrate lots of servers/apps than for lots of individuals to do so. My company just switched most of our servers to running as virtual machines on a single physical machine - much better use of hardware and easier to manage. Also improving things by having a couple people that know what we're doing manage the network and servers instead of letting a lot of people that don't know what they're doing do it. Overall, things are much more reliable and we expect to save a lot of money over time with this strategy. The same strategy applies to a single company managing services for others - in fact we're considering, since we have far more experience and infrastructure in our company than most other companies in our area, offering hosting and management of systems for other companies.
I think it'll be an interesting battle as companies try to battle it out to become your application server of choice, for different apps, while still trying to stick to the free or almost free price range.
I don't agree. No more complex than a mobile website is to make it doesn't cost a lot or take much time. It's mostly making your site work even when bells and whistles such as Javascript, CSS, Flash, and Java aren't available and keeping your text terse and to the point and your images sized for small devices. I don't really see a point to the mobi tld but part of that is because of the stupid choice of 'mobi' which is itself a pain to enter on a phone. My vote is still for 'pad' which could actually be entered on a keypad easily. Still, it's easier to just have your web server detect mobile devices and send them the correct version of the site. The only real benefit to a specific tld is that people that see it on your advertising will recognize it as being usable from their phone.
I already have redundant crap glued to my tv. Distributed processing is a benefit because it'd allow that redundant crap to work together to do something other than gathering dust. I probably wouldn't upgrade all my crap to have Cell processors in it but when I upgrade it anyway, as I'm likely to do within a five year period, then I may as well get new equipment that'll work together instead of being at war with each other.
Upgrading a console every five years is a dying concept. It's much easier, and cheaper, to use a fixed system and just add additional systems as needed. Games are getting to the point where more of their processing will be parallel anyway so why cram it all into a single box? My guess for the PS4 would be a smaller, faster version of the PS3 that is CPU-compatible with more RAM, HDD, and possibly a better video chipset. I'd also take a guess at a mini rack-mount attachment where you can plug-in streamlined versions that don't have bluetooth, usb, a/v, etc built-in but that will fit into the nice little rack. The prices could come down, the systems could get a lot smaller, cooler, quieter, and less energy hungry, and performance could be increased rapidly instead of in five year leaps. Sony could sell the intitial units for prices parents wouldn't run from and offer affordable upgrading to the power of the system. A lot more people would shell out $200 three times than $600 once especially if it adds onto what they already have.
The Cell processor isn't just a Sony thing and is available to be added to any company's products. You can buy Blade servers that run a Cell processor. It's a real CPU and not just a toy CPU for some gaming console.
Developing distributed programs isn't that difficult. What is difficult is taking existing code libraries and tools and porting them to a distributed model. With game consoles and PC CPUs going towards that model though developers are going to have to make the change. Once your libraries and tools are designed for distributed programming it can be easier because you don't have to do things in time slices. Getting a lot of CPU intensive complex systems to run in tiny segments as you loop over them is a much bigger pain in the ass IMO.
I disagree. I think making games work on multiple gaming units instead of constantly forcing an upgrade to a newer model is a better idea. In five years when a PS3 costs $200 I'd be glad to buy a second one or even a third for newer more intensive games. I'd love to see a little icon on the box saying that the game requires two units. I'd hope they'd make it more user-friendly to network the machines together by that time though.
I'd love to see a massive world that could be raytraced in movie quality during realtime gameplay. They mentioned that possibility with networked PS3's early in their rumor phase and it is one of the concepts I found most exciting. As I remember they said that as they get Cell processors into other consumer electronics that some of the work could be offloaded to the CPU in your tv, dvd player, etc. That'd be awesome.
Am interesting point - I suppose I could develop code in JPython and compile it with GWT. I usually use Python for my non-web GUI apps so that could be a workable concept.
Still, it's not significantly easier IMO than developing with Javascript and CSS so long as you have a framework that's already developed the widgets and worked out the compatibility issues.
Just a side rant.. I have to say that I really hate Internet Explorer. Even IE7 has significant problems with it's Javascript and CSS which require hours of work to code around. Even worse since we still need to support IE6 too. Last night I wanted to write a simple tabbed pages widget and it took me longer to work out the IE bugs than to write the original code. IE7 was having an especially annoying bug where when hiding and unhiding content it'd randomly lose page elements. But if you did an alert() they'd reappear. How stupid is that? Okay.. end rant for today.
AJAX shouldn't be a pain. Maybe your programmers are overly excited about it and want to throw the kitchen sink at every problem but that doesn't make the concept a bad concept. My general rule is to make it work without bells and whistles first, and then you can use clean methods like CSS and Javascript behaviors to improve the apps for people that have CSS and JS.
Saying you don't need AJAX for anything isn't right. If you really can make your applications more user-friendly and avoid using bloated technologies like Java and Flash then you have a good reason to use AJAX. A well written AJAX'd app shouldn't be any harder to maintain other than obviously needing your programmers to be properly trained in writing clean XHTML, CSS, and Javascript. You do need to have a more diverse skillset to develop modern websites than you did in 1997 but then website development required more skills in 1995 than developing a Gopher site before that but I think most people think the work is worth it.:)
A simple example that comes to mind would be developing a web-based chat program. Sure you can force the entire page to reload every few seconds and when the user submits but it'll feel clunky and annoying. Using some Javascript to monitor presence and incoming messages, as well as sending outgoing messages, without any page reloads makes the experience a lot nicer for users and is more like a non-web app.
Re:All of these frameworks are mostly overkill
on
GWT Java AJAX Programming
·
· Score: 2, Insightful
You'd be assuming that the average developer writes better code than the framework developers. My experience is that the average coder, through lack of time, laziness, or inability, writes pretty crappy code. On average you probably get lighter, and better, code by using a framework. Of course I've seen some pretty crappy frameworks too.. but you can choose not to use those.:)
Using a framework is like using functions or objects. If you go crazy with the concept then it'll end up being crap but if you use it in a way that makes sense then it'll help you a lot. You don't want to create a function for a single line of code you're going to use once but you may want to create one for ten lines of code you're going to use a dozen times. You don't want to create a class for a single on line function you'll use once but if you begin building up application logic in a way that needs to have self-contained data and logic that'll be reused and built on then objects become very good. Frameworks are just the same. If you're making a page with a few lines of Javascript on it then a framework is overkill. If you're creating a complex application then using a framework will save you time and make your code easier to maintain - assuming you choose, or build, the right framework.
Your comments seem a little odd because web design has become very much like working with Unix-style single purpose programs. If you have trouble it's probably because you aren't coding in Unix-style. My web applications are composed of many smaller programs that each do a single thing. These can be written in whatever language is most appropiate but they speak to each other in common interfaces. My back-end is composed of services that communicate with XML-RPC. The front-end is a thin layer that usually divides the front-end logic between the web server and web browser and all the code is kept mostly seperated. The web server uses PHP for templating, input scrubbing, and calling the back-end services. Most of my code is standard XHTML which if viewed without CSS, Javascript, and the rare bit of Java or Flash looks like very boring circa-1997 content. CSS makes it look nice and Javascript gives it better interaction. The applications work without either of these - they just aren't as nice a user experience. The XHTML, CSS, and JS are kept in completely different places so they are essentially discrete components. Likewise with any Java or Flash I use.
If I have to deal with interfacing with something that doesn't use a XML-RPC interface then I create a service, to sit between it and the rest of my applications, that gives it a XML-RPC interface. I've been recently doing this with Intuit Eclipse which I expect to make programming multiple apps to use much easier. Lots of libraries available, for just about any language, to interface with XML-RPC. Not to many available to interface with Eclipse's IDMS-XML. I've created similar translation services to handle S&H, payment processing, instant messaging, etc. Much easier to maintain than a single massive app.
My web applications are stiched together very much like Unix shell commands. Many small and simple parts that together can do just about anything. If you start mishmashing it all into single files then of course you'll go insane. Using discrete services also makes it a lot easier to divide load across multiple machines and to impose different security levels on different services.
Now if you just wanna bitch about how different browsers handle CSS and Javascript and can join you there. IE7 has helped a lot but I still spend more time fixing issues with IE7 than I do with Firefox, Safari, and Opera combined. Unfortunately, I still have to make sure IE6 at least works even if it isn't perfect.
To bad GWT uses Java. I wouldn't say that Java is the easiest language to use for rapid development like web applications usually require. Of course the saving grace might be the number of tools that exist to make building GUIs in Java easy. Still, I'd rather see something more RAD oriented than the Java is. It's impressive work even if it isn't perfect though - I think it'll lead the way for better development models in web design.
I think a domain-specific markup language designed for high power web apps is a better idea. Just compile those into HTML/CSS/JS until some browser actually supports the language native. I wonder if XUL and all that Mozilla stuff couldn't be compiled into HTML/CSS/JS the way Google is compiling the Java.
My favorite AJAX trick is still from whomever invented Javascript Behaviors that attach using CSS rules. I use that library constantly and would love to see the concept made into a real standard. I know that when I've developed GUI apps in Java for cellphones I've used libraries that would let you style the UI and attach application logic to the UI using a modified form of css and it really made development easier. With Behaviors my HTML is clean and the application logic is easy to change.
I'd go with Wifi and get Wifi enabled cellphones (like T-Mobile has) that will enable you to place and receive calls via Wifi when it is available. It'll save you airtime charges too if you can use your own Wifi internally.
Or if you don't need cell capabilities and don't mind a bit crappier phones you can get Wifi phones for Skype and Vonage.
What we need is laws to protect private users who share their bandwidth and standards in APs to make it easy for them to do so and to create a standard way for people to connect. An open wirless AP in every home and business should just be expected. Let the users create the network themselves if you really want what is best for the consumer. Of course businesses will cry foul over their lost chance to squeeze every penny out of the consumer and government will cry foul because it'd make it much harder to control and spy on the consumer.
Eventually it will happen though. There are just to many benefits to the consumer and to few downsides for it not to eventually. Someone just needs to release a killer app for the system and people will flock to it. Consumers don't understand technical reasons something will be ebtter but if they lust for a product that users it then they'll demand it.
It's just a comfort issue. If you used GIMP more you'd become comfortable doing things in it. I feel about Photoshop the way you do GIMP. I use GIMP daily and can crank out complex stuff in short order. It's definately not a drawing program but for graphic manipulation it does a great job. I love that I can move single images around so that I can edit them while still seeing the windows behind them - it really helps when trying to match colors and graphic styles.
My only big complaint right now is true for almost every other app I've used - it does not handle processing thousands of fonts very well. My load time is bad and there is sometimes lag when browsing fonts even on a powerful machine. Of course Mac OS had much worse of a cow over dumping in 10,000 fonts so I can't think to bad of GIMP for it's handling.
It could just download the app and process everything locally. If it were me programming it, I'd have the the program download small parts, as needed, rather than all in one and keep a cache and run everything locally. Of course I probably wouldn't try to keep multi-gig files in memory either and would instead treat the files more like Google Maps where it works with small blocks at a time as needed. In this day code should be designed to be ran in parallel anyway so it makes even more sense to do things in small blocks. If I have a 16 core CPU I sure as heck want to run the process across all 16 instead of waiting for one core to do it all.
I agree. I use GIMP daily for graphic design and it works great. I can't stand the layout of Photoshop even though I was using Photoshop before GIMP even existed. Some things GIMP can't do but most things it can and it does them well. I avoid Photoshop whenever possible because of it's bulk and rigidness which gets in the way more often than not.
Now - if only there were a real Illustrator alternative.
This used to be addressed through offering programs as shareware. Make the first program free and easy to get and then make money by selling new installments.
Slashdot Mirror
Security on one server, ran by someone that knows what they're doing, will be better than what we have now, which is thousands of webservers ran by people who have almost no idea what they are doing and no time and money to dedicate to doing it right.
Take a look at what servers get hacked. It isn't often those that are well maintained by trained people with years of experience. It's usually people stupid enough to run a server that hasn't been updated in three years.
The trick is to make centralized copies of important, or oft used, files available. I'd not just do DTD's. I think as AJAX, Web 2.0, or whatever you wanna call it, grows more popular and demands users download more and more Javascript, images, etc that are often the same files between different websites that it could be very useful to them if we stored a copy of those shared files on one server, with caching properly configured, so that users need to only download and store one copy instead of dozens of copies.
You don't have to centralize the originals - just copies. You get the benefits of a centralized resource without the risks of a centralized organization.
I'm planning on building a multi-terabyte RAID5 for my home out of these some time in the next couple months. Now the big question is how I'll make backups. I'm thinking of just using a couple spare 1TB drives as external hdds or maybe making a spare RAID5 in a Mini-ITX case so I can port it around as my external hdd.
:)
:)
I'd like to do a 6TB RAID5 but I'll probably end up with two RAID5's with three 1TB disks each so that I can make my backups.
I don't know about in 16 years but I bet within 10 we're talking about the first petabyte drives. I know I'll be able to fill those up too. I could do it now if I could afford to buy the drives and the infrastructure needed to support them.
I collect spam to test my AI programs on. I have a bunch of filters that process images into different rpresentations - basically flagging matches to different patterns and building new patterns from combinations of existing patterns. I've experimented with bayesian filters on the output of some of my toys and it seems to work rather well. The filters might output a text string like:
md5:16613765e1f9a23fe6244b90d9483e1f found:9 w:450 h:600 color:ddc3b2 color:decec3 color:d3bdaf color:debfab color:e5c2ac altcolor:d1ac95 black:21 text:"ASIANGIRLS . JP"
This is pretty simplified compared to what the filters actually output but overall it provides a pretty good bit of text that most bayesian filters can do something with. The filters gather simple information such as the file md5, width, height, times file has been matched, average color, average grey value, color and grey value averages of common blocks, the same color and grey values for everything after the most common color is removed, text recognition, shape reconition, and keys for learned patterns of these different values that are recognized in the image. Other than the md5, width, and height these values change little when scaling, clipping, watermarking, changing fonts, tinting the image, etc. I've trained my filters on millions of images over the past decade and they really work pretty well although I'm always finding new improvements to make.
My goal is to build an intelligent program that can classify and respond to visual input so spotting spam doesn't seem to far a stretch. I have trouble believing that spammers could generate a random enough image to fool the filters while still being usable to humans. Of course, the price is CPU time for the user but most of my filters don't use a lot of CPU time and bayseian filtering dosn't use a lot either so it's really not to bad.
As someone that has a XO (OLPC) I'll say that it is way better than any cheapie laptop I've seen. If it was available for retail purchase here in the US I'd buy several to pass out as gifts. The quality is great and it really has a lot to offer for such a low price tag. I mean it comes with the ability to participate in a mesh network and be connected to a normal wifi AP at the same time, has a decent built in camera, has a pad for pen input, is very durable, is very lightweight, stays cool, has a decent battery life, has features that make it usable as an ebook or handheld game, the software is custom written to take advantage of the laptop and work within its limited specs, and is just pretty damn cute. Every kid I've tested it on has loved it as have most adults. And remember that they actually plan to get production costs down to under $100 per laptop and then start distributing low-cost add-ons such as an OLPC printer. Your average cheapie laptop is not going to be the same.
That said, I can't believe they are distributing the XO to kids already. The software is not done at all. IMO the software is barely usable thus far. Work on the software is progressing pretty fast, and in fact that is why I have an unit, but I would not yet be distributing them with the software in it's current state. I hope they have easy access to the units being distributed so they can be updated as needed.
The problem with page state and back/forward/reload issues is only waiting for an update to the DOM to properly include state information. It shouldn't be to difficult to make it possible for apps to overload those functions to do something that makes more sense in context of their app. Switching to Java, Flash, or whatever does no better because they support those functions even less than AJAX.
Most browsers let you deny scripting from taking over control of your status bar, right-click functions, and other things that can be annoying (at worst you have to download some sort of extension to do this). Again, these are no less held hostage with Java or Flash.
IMO Java and Flash is not Web 2.0 - it's just the same boring stuff that didn't work 10 years ago with few improvements or new concepts. Web 2.0 should not replace Web 1.0. A good web based application should be usable with Javascript and CSS turned off and no plug-ins. Add Javascript, CSS, or even Java and Flash should just improve the application by using the extra functionality that is available.
I'll certainly agree that Javascript, CSS, HTML, etc have limitations. Some of these can be overcome eventually by improving these technologies. Some can also be overcome by making proper use of Java, Flash, etc to give a boost. Myself, I'd rather leave my apps as backward compatible as possible by building a normal HTML app and then layering on Javascript and CSS and then layering Flash and Java on top of those so that with any layer missing as much capability will be retained as possible. So, for example I might use a Flash based sound manager to lend improved audio to a HTML/CSS/Javascript based game, controlling the Flash abiltiies via JS, rather than writing the entire game in Flash. That way if the user doesn't have Flash they only lose sound capability.
It's quite possible to write something like a web based graphics editor using Canvas and SVG but you might want to use Java components as downloadable filters (as sending the entire graphic to the server to process every filter might be to slow) so just have each filter download on-demand. That has the additional benefit of not needing to download a single massive Java app before it can become useful. Of course for something such as a graphic editor there are fewer downsides to a pure Java or Flash based app as you care less about being useful for users without your plugin of choice and aren't likely to care about blind users or search engine placement. Many apps can find a better middle ground though - anything that primarily works with text-based information. Stock trading and spreadsheets I'd say fall into that category of being useful to not require plugins for.
I use LISP, Prolog, Perl, PHP, Python, SQL, and pretty mcuh whatever language I find useful in web apps all the time. It's easy enough to run them on your servers and let them communicate with your web client. You don't even need to use a page refresh anymore to do it. If that isn't good enough you can compile most languages into Java and interact with those components. I know Python, LISP, and Prolog can be compiled to Java so it isn't a shortage by any means. Again, usually you don't need to resort to using Java but in the rare cases it is needed it supplies plenty of power to supplement AJAX apps.
I'll disagree about GMail. It's way less clumsy than Outlook, Thunderbird, or any other email program I can think of. My biggest complaint about it is it's lack if disk space which I doubt many others suffer from. Web apps encourage the author to keep things simpler, easier to use, and less bloated than the authors of desktop apps. That is a real benefit IMO. Email is all about representation of information and that is exactly what the web is for. I don't think there should be a logical difference between web and application. It's all about making it easy to process information and follow the connections between bits of info. If your app can't be fit into that model then maybe there is something conceptually wrong wi
Wait time is hard because most of us are now using broadband of some type but there are always a few people still using dial-up or something in-between, such as connecting over the cell phone network. I generally try to keep the first load time down by turning on compression in my web server, sometime running Javascript & CSS through whitespace/comment strippers, and delaying as much of my Javascript and CSS from downloading until after the page has finished loading as possible. After that, I try to keep things low by supporting caching of my CSS, JS, and images and keeping my HTML reasonably clean and simple. Still you'll always have trade-offs between download speed and functionality.
I don't know that we need a replacement for HTML/JS/CSS so much as we need an upgrade. Javascript Behaviors should be part of the JS standard and not require the downloading of an extra 50Kb of code. Common libraries should be enabled to cache in the browser and be used with multiple websites more easily. All browsers should support sending Javascript and CSS compressed. Stuff like that.
I can't say I've experienced any flakiness with GMail, Google Maps, and other major AJAX apps I've used. Certainly no more than I've exprienced with Flash or Java apps or even a lot of desktop apps. The flakiness usually comes with poorly designed and tested stuff on smaller sites. I usually test my stuff in Firefox, Opera, Safari, IE6, and IE7 and sometimes it can be a pain to get everything working but I'd say 90% of my problems come from IE. This is an IE problem and not a problem with HTML/JS/CSS. Poorly designed and tested code will always be a problem with any language.
My code is typically pretty clean on the backend. The HTML, Javascript, and CSS is largely kept untangled and is easy to work with. I do wish this process would be made easier but again it's an incremental upgrade that is needed more than a total replacement. Communication with a backend server isn't overly complex or tangled either. The biggest issue is to not inline code your Javascript and CSS into your HTML and to make an effort to make sure important features will work without CSS or JS.
Generated code like ASP.NET and other tools produce can be useful but is as much trouble as not for some projects and really limits your ability to think outside the box. I think it's to early in the 'web 2.0' to be trying to solidify a standard of what we can and can't do.
Java, Flash, ActiveX, etc have all kind of sucked due to thir bulk, security issues, installation needs, inappropiate design for rapid application dev, etc. I have used all of them sometimes, when needed, but don't feel they are the right direction to go. JavaFX, to me, sounds like more of the same - gee whiz features with the core issues poorly thought out and worked out. Is JavaFX going to be based on Java? That alone is enough to keep me from using it from most projects. Java syntax is not appropiate for RAD and often web development has to be able to respond quickly to new needs, found bugs, etc.
I wouldn't mind a new scripting language if it would solve these problems, not create new problems, and would work with all current major browsers (Firefox, Safari, Opera, and IE) without using plug-ins or similar bad ideas. I'd probably suggest modifying Python to have built-in DOM support and to allow assigning scripting to HTML/XML using CSS-like behaviors. Possibly making XUL + friends into a real standard across browsers. I'd also vote for forcing SVG and Canvas support in all current browsers as well as adding some built-in audio/video capabilities to the browsers. OBJECT and EMBED are a broken concept and plug-ins suck.
Just making IE follow the actual standards for Javascript + DOM implementation would be a huge step forward in making developer's lifes easier. They have no excuse not to since the implementations used by Firefox and Safari are freely usable.
It's a pretty well known fact that most people would rather use an out-of-the-box solution than try to do things themselves. I can see some businesses running their own servers and some geeky people like us but the vast majority of people would rather have a system managed by someone else on a network managed by someone else. No matter how easy doing it yourself is it's still almost always easier to let someone else do it. Only people that need solutions to problems not yet covered by a service company will probably want to do things themselves. Them and us geeks that like doing things ourselves just because. :)
Of course it's much more price effective for a central company to adminstrate lots of servers/apps than for lots of individuals to do so. My company just switched most of our servers to running as virtual machines on a single physical machine - much better use of hardware and easier to manage. Also improving things by having a couple people that know what we're doing manage the network and servers instead of letting a lot of people that don't know what they're doing do it. Overall, things are much more reliable and we expect to save a lot of money over time with this strategy. The same strategy applies to a single company managing services for others - in fact we're considering, since we have far more experience and infrastructure in our company than most other companies in our area, offering hosting and management of systems for other companies.
I think it'll be an interesting battle as companies try to battle it out to become your application server of choice, for different apps, while still trying to stick to the free or almost free price range.
I've done this w/ VMWare for years.
I don't agree. No more complex than a mobile website is to make it doesn't cost a lot or take much time. It's mostly making your site work even when bells and whistles such as Javascript, CSS, Flash, and Java aren't available and keeping your text terse and to the point and your images sized for small devices. I don't really see a point to the mobi tld but part of that is because of the stupid choice of 'mobi' which is itself a pain to enter on a phone. My vote is still for 'pad' which could actually be entered on a keypad easily. Still, it's easier to just have your web server detect mobile devices and send them the correct version of the site. The only real benefit to a specific tld is that people that see it on your advertising will recognize it as being usable from their phone.
I already have redundant crap glued to my tv. Distributed processing is a benefit because it'd allow that redundant crap to work together to do something other than gathering dust. I probably wouldn't upgrade all my crap to have Cell processors in it but when I upgrade it anyway, as I'm likely to do within a five year period, then I may as well get new equipment that'll work together instead of being at war with each other.
Upgrading a console every five years is a dying concept. It's much easier, and cheaper, to use a fixed system and just add additional systems as needed. Games are getting to the point where more of their processing will be parallel anyway so why cram it all into a single box? My guess for the PS4 would be a smaller, faster version of the PS3 that is CPU-compatible with more RAM, HDD, and possibly a better video chipset. I'd also take a guess at a mini rack-mount attachment where you can plug-in streamlined versions that don't have bluetooth, usb, a/v, etc built-in but that will fit into the nice little rack. The prices could come down, the systems could get a lot smaller, cooler, quieter, and less energy hungry, and performance could be increased rapidly instead of in five year leaps. Sony could sell the intitial units for prices parents wouldn't run from and offer affordable upgrading to the power of the system. A lot more people would shell out $200 three times than $600 once especially if it adds onto what they already have.
The Cell processor isn't just a Sony thing and is available to be added to any company's products. You can buy Blade servers that run a Cell processor. It's a real CPU and not just a toy CPU for some gaming console.
Developing distributed programs isn't that difficult. What is difficult is taking existing code libraries and tools and porting them to a distributed model. With game consoles and PC CPUs going towards that model though developers are going to have to make the change. Once your libraries and tools are designed for distributed programming it can be easier because you don't have to do things in time slices. Getting a lot of CPU intensive complex systems to run in tiny segments as you loop over them is a much bigger pain in the ass IMO.
I disagree. I think making games work on multiple gaming units instead of constantly forcing an upgrade to a newer model is a better idea. In five years when a PS3 costs $200 I'd be glad to buy a second one or even a third for newer more intensive games. I'd love to see a little icon on the box saying that the game requires two units. I'd hope they'd make it more user-friendly to network the machines together by that time though.
I'd love to see a massive world that could be raytraced in movie quality during realtime gameplay. They mentioned that possibility with networked PS3's early in their rumor phase and it is one of the concepts I found most exciting. As I remember they said that as they get Cell processors into other consumer electronics that some of the work could be offloaded to the CPU in your tv, dvd player, etc. That'd be awesome.
Am interesting point - I suppose I could develop code in JPython and compile it with GWT. I usually use Python for my non-web GUI apps so that could be a workable concept.
Still, it's not significantly easier IMO than developing with Javascript and CSS so long as you have a framework that's already developed the widgets and worked out the compatibility issues.
Just a side rant.. I have to say that I really hate Internet Explorer. Even IE7 has significant problems with it's Javascript and CSS which require hours of work to code around. Even worse since we still need to support IE6 too. Last night I wanted to write a simple tabbed pages widget and it took me longer to work out the IE bugs than to write the original code. IE7 was having an especially annoying bug where when hiding and unhiding content it'd randomly lose page elements. But if you did an alert() they'd reappear. How stupid is that? Okay.. end rant for today.
AJAX shouldn't be a pain. Maybe your programmers are overly excited about it and want to throw the kitchen sink at every problem but that doesn't make the concept a bad concept. My general rule is to make it work without bells and whistles first, and then you can use clean methods like CSS and Javascript behaviors to improve the apps for people that have CSS and JS.
:)
Saying you don't need AJAX for anything isn't right. If you really can make your applications more user-friendly and avoid using bloated technologies like Java and Flash then you have a good reason to use AJAX. A well written AJAX'd app shouldn't be any harder to maintain other than obviously needing your programmers to be properly trained in writing clean XHTML, CSS, and Javascript. You do need to have a more diverse skillset to develop modern websites than you did in 1997 but then website development required more skills in 1995 than developing a Gopher site before that but I think most people think the work is worth it.
A simple example that comes to mind would be developing a web-based chat program. Sure you can force the entire page to reload every few seconds and when the user submits but it'll feel clunky and annoying. Using some Javascript to monitor presence and incoming messages, as well as sending outgoing messages, without any page reloads makes the experience a lot nicer for users and is more like a non-web app.
You'd be assuming that the average developer writes better code than the framework developers. My experience is that the average coder, through lack of time, laziness, or inability, writes pretty crappy code. On average you probably get lighter, and better, code by using a framework. Of course I've seen some pretty crappy frameworks too.. but you can choose not to use those. :)
Using a framework is like using functions or objects. If you go crazy with the concept then it'll end up being crap but if you use it in a way that makes sense then it'll help you a lot. You don't want to create a function for a single line of code you're going to use once but you may want to create one for ten lines of code you're going to use a dozen times. You don't want to create a class for a single on line function you'll use once but if you begin building up application logic in a way that needs to have self-contained data and logic that'll be reused and built on then objects become very good. Frameworks are just the same. If you're making a page with a few lines of Javascript on it then a framework is overkill. If you're creating a complex application then using a framework will save you time and make your code easier to maintain - assuming you choose, or build, the right framework.
Your comments seem a little odd because web design has become very much like working with Unix-style single purpose programs. If you have trouble it's probably because you aren't coding in Unix-style. My web applications are composed of many smaller programs that each do a single thing. These can be written in whatever language is most appropiate but they speak to each other in common interfaces. My back-end is composed of services that communicate with XML-RPC. The front-end is a thin layer that usually divides the front-end logic between the web server and web browser and all the code is kept mostly seperated. The web server uses PHP for templating, input scrubbing, and calling the back-end services. Most of my code is standard XHTML which if viewed without CSS, Javascript, and the rare bit of Java or Flash looks like very boring circa-1997 content. CSS makes it look nice and Javascript gives it better interaction. The applications work without either of these - they just aren't as nice a user experience. The XHTML, CSS, and JS are kept in completely different places so they are essentially discrete components. Likewise with any Java or Flash I use.
If I have to deal with interfacing with something that doesn't use a XML-RPC interface then I create a service, to sit between it and the rest of my applications, that gives it a XML-RPC interface. I've been recently doing this with Intuit Eclipse which I expect to make programming multiple apps to use much easier. Lots of libraries available, for just about any language, to interface with XML-RPC. Not to many available to interface with Eclipse's IDMS-XML. I've created similar translation services to handle S&H, payment processing, instant messaging, etc. Much easier to maintain than a single massive app.
My web applications are stiched together very much like Unix shell commands. Many small and simple parts that together can do just about anything. If you start mishmashing it all into single files then of course you'll go insane. Using discrete services also makes it a lot easier to divide load across multiple machines and to impose different security levels on different services.
Now if you just wanna bitch about how different browsers handle CSS and Javascript and can join you there. IE7 has helped a lot but I still spend more time fixing issues with IE7 than I do with Firefox, Safari, and Opera combined. Unfortunately, I still have to make sure IE6 at least works even if it isn't perfect.
To bad GWT uses Java. I wouldn't say that Java is the easiest language to use for rapid development like web applications usually require. Of course the saving grace might be the number of tools that exist to make building GUIs in Java easy. Still, I'd rather see something more RAD oriented than the Java is. It's impressive work even if it isn't perfect though - I think it'll lead the way for better development models in web design.
I think a domain-specific markup language designed for high power web apps is a better idea. Just compile those into HTML/CSS/JS until some browser actually supports the language native. I wonder if XUL and all that Mozilla stuff couldn't be compiled into HTML/CSS/JS the way Google is compiling the Java.
My favorite AJAX trick is still from whomever invented Javascript Behaviors that attach using CSS rules. I use that library constantly and would love to see the concept made into a real standard. I know that when I've developed GUI apps in Java for cellphones I've used libraries that would let you style the UI and attach application logic to the UI using a modified form of css and it really made development easier. With Behaviors my HTML is clean and the application logic is easy to change.
I'd go with Wifi and get Wifi enabled cellphones (like T-Mobile has) that will enable you to place and receive calls via Wifi when it is available. It'll save you airtime charges too if you can use your own Wifi internally.
Or if you don't need cell capabilities and don't mind a bit crappier phones you can get Wifi phones for Skype and Vonage.
What we need is laws to protect private users who share their bandwidth and standards in APs to make it easy for them to do so and to create a standard way for people to connect. An open wirless AP in every home and business should just be expected. Let the users create the network themselves if you really want what is best for the consumer. Of course businesses will cry foul over their lost chance to squeeze every penny out of the consumer and government will cry foul because it'd make it much harder to control and spy on the consumer.
Eventually it will happen though. There are just to many benefits to the consumer and to few downsides for it not to eventually. Someone just needs to release a killer app for the system and people will flock to it. Consumers don't understand technical reasons something will be ebtter but if they lust for a product that users it then they'll demand it.
It's just a comfort issue. If you used GIMP more you'd become comfortable doing things in it. I feel about Photoshop the way you do GIMP. I use GIMP daily and can crank out complex stuff in short order. It's definately not a drawing program but for graphic manipulation it does a great job. I love that I can move single images around so that I can edit them while still seeing the windows behind them - it really helps when trying to match colors and graphic styles.
My only big complaint right now is true for almost every other app I've used - it does not handle processing thousands of fonts very well. My load time is bad and there is sometimes lag when browsing fonts even on a powerful machine. Of course Mac OS had much worse of a cow over dumping in 10,000 fonts so I can't think to bad of GIMP for it's handling.
It could just download the app and process everything locally. If it were me programming it, I'd have the the program download small parts, as needed, rather than all in one and keep a cache and run everything locally. Of course I probably wouldn't try to keep multi-gig files in memory either and would instead treat the files more like Google Maps where it works with small blocks at a time as needed. In this day code should be designed to be ran in parallel anyway so it makes even more sense to do things in small blocks. If I have a 16 core CPU I sure as heck want to run the process across all 16 instead of waiting for one core to do it all.
I agree. I use GIMP daily for graphic design and it works great. I can't stand the layout of Photoshop even though I was using Photoshop before GIMP even existed. Some things GIMP can't do but most things it can and it does them well. I avoid Photoshop whenever possible because of it's bulk and rigidness which gets in the way more often than not.
Now - if only there were a real Illustrator alternative.
Did nobody else read Lord of the Flies? Geez these old paranoid people need to learn to read.
This used to be addressed through offering programs as shareware. Make the first program free and easy to get and then make money by selling new installments.