- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
... I don't get it. They're building Javascript code from Java.. is that suddenly bad? I've seen it used to good effect in C#.
Oh wait I get it. Bad OOP - A "Patient" class has no business inheriting from what is presumably a utility class. I see now. Very interesting.
P.S. Fist!
Admin
Who needs desktop applications? Someone will surely create a web application to browse the internet, which you can use with.. er.. the BIOS?
Second
Admin
Did the story HAD to be cut in two? I had to click "read more" to discover, what, five lines? Including the return carriage?
... yeah. Just whining, don't mind me.
Admin
I've seen this entirely too often. Although, in my case, it was an Product class, and it "implemented Jsonable".
Admin
hmmm... extending a utility class is pretty stupid, but why is it always a bad idea to implement Jsonable? If that's bad, then so is making something 'Serializable'.
Unless you alway use JSON as the default serialization format... in which case its kind of silly. But if some objects are serialized in binary (like ProductPhoto), I could see the value of Jsonable.
Admin
And that's why we need multiple inheritance. Patient should also extend BillingResource.
Admin
Is this a warning about what will happen to me if I keep building Javascript strings?
Admin
And yes, “Patient” means exactly what you think it does. As does “Javascript.”
Patient as in the quality where a person doesn't mind waiting for a long time?
Admin
This is nothing. Nothing, I tell you.
I had the pleasure of writing a second-generation C++ server application to replace the following code base:
class Computer { public: virtual bool DoX(); virtual bool DoY(); virtual bool DoZ(); }; class Process : public Computer { public: virtual bool DoX(); virtual bool DoY(); virtual bool DoZ(); }; class Program: public Process { public: virtual bool DoX(); virtual bool DoY(); virtual bool DoZ(); }; class Application : public Program { public: bool DoX(); bool DoY(); bool DoZ(); };Yes, Application was a singleton class. It was configured via a hundred or so command-line arguments and a commensurate switch statement ... sort of the Swiss Army Penknife of applications.
Luckily there were no threads involved.
Even more luckily, we were never asked to make it a distributed system...
Admin
Desktop applications are only outdated to morons who don't realise how insanely complicated it is to write functional AJAX applications.
And then they complain when their new shiny webapp is 10x slower than the desktop version.
See, when you had the desktop app, it could cache data you reused over and over again. With a shiny AJAX app, you have to transfer that data back and forth from the webserver to the webclient with every single postback! HOORAY FOR PROGRESS!
AJAX: The worlds solution to managers who are too cheap to pay for an IT staff, and don't realise how much slower users are when using webapps for rich application purposes. HOORAY!
Admin
Admin
BUT IT HAS ROUND CORNERS AND GRADIENTS!
Admin
It's not just that it's insanely complicated to write an AJAX app or anything. You can write a good web app without AJAX or with it, whatever. Great web apps can be written and without TOO much fuss (though they can be complicated like you said)...
The issue is that first off, in order to use the web app, the user has to have an OS which is essentially a desktop app (and that includes all the IO code for the mouse, keyboard, display, network connection, etc.). Then they have to have a web browser which is a pretty complicated desktop app. Then, the web app has to be appropriate for what it's doing. My friend thinks that web apps are appropriate for every kind of application. That's just not true. Some things (games, some business applications, etc.) are just way more appropriate to desktop apps. And like you said, a lot of them are 10x slower than what they would be if they were desktop applications.
I know the article was written tongue-in-cheek but it irritates me when morons like Jeff Atwood insist that the desktop app is going away. No, it's not and it probably never will.
Sorry off-topic but this just reminds me of a huge WTF that I've noticed in IT lately.
Admin
Sweet a web browser built into the BIOS. It damn well better not be compliant or the world as we know it will end!!!!
I have to say though the Web 2.0 stuff and all the rest of the race to be the first software distributor/manufacture with the best new trendy wigget is starting to make me want to start a law suit for mental anguish against all major companies Microsoft being #1 on the list.
For instance moving from asp.net 1.1 to 2.0 is a brain crunch. Next to nothing works the same. I have to ask myself is this level of constant change and learning really what is best fo the industry? I mean some days I almost wish I used PHP or PERL and for me that is a really big deal.
Admin
You may want to look into the browser cache http headers, page experation and some other trendy but old things.
Admin
You're right, there's no doubting the fact that some applications can be quite usable in an AJAX or web-based environment and I like where things are going. I can't help but wonder exactly how far it can go though. A cut down version of word works relatively responsively and is usable.
What about Photoshop? Visual Studio? Any game?
And what the hell will we use our 8 core "Core 2 Septo+1" for when Google is doing all our processing on its side shipping out content to a beefed up thin client?
I'm 100% sure I'll be eating my words sometime soon but conceptually, I can't see exactly how it will "work" at the moment.
CAPTCHA: pointer, because I think I need one
Admin
What's wrong with that?
You can then pass your Jsonable objects into a JsonFactory to get a JsonBuilder or JsonWriter or whatever JSON is that handles that object.
I have XMLable objects here... bam them into the XMLFactory and BAM! XML (well, if you have a backend XMLFormatter for that object or superclassofobject). The bamming was added to actually make it interesting to read. BAM.
Admin
void* p;
Admin
I think things would be diffrent if every place that writes any code had a role reversal for a say a month. All the developers get to be the managers (they have to act like managers) and all the managers have to be developers. And let me think what could the users be... ok all the users have to be analysts lmao
Admin
Remember people. A desktop app can use datasources from the internet just as easily as a web app. In fact, generally easier, you are using a real programming language and don't have the same sandbox restrictions.
Remember, look at your first design, and think to yourself 'gloves'.
Or, hey, here's a freaking concept: write your prototype interface as a web app, with only minimal features best supported by the interface... and then add real features to the desktop clients, since it can, you know, actually support them.
Admin
Admin
public sealed class ProgrammersBrain : StackOverflowException
Admin
Admin
Uh, cache data by storing it in a hidden frame. That's even pre-ajaxy.
Admin
Nice!
Admin
Now, now... AJAXy games can be perfectly fine non-wtf material ( http://www.pseudoquest.com , for example ). You just have to limit the scope of your game sufficiently.
Now, something like this ( http://www.elizium.nu/scripts/lemmings/ ) would be just plain crazy. Not that it uses AJAX, but somehow after having discovered this site a while back, adding AJAX calls to a centralized server to retrieve individual pixel states via AJAX wouldn't surprise me in the least.
Admin
Check out Coding Horror on June 7: http://www.codinghorror.com/blog/archives/000883.html
Jeff Atwood says:
Admin
it will be used to render your last generation fat operating system... thin clients are in, thin OSes are out !
0xDEADBEEF, but i'm not sure it is a valid one...Admin
THe SMURF programming language is the ultimate solution to all problems. Let me give you an example.
smurf sql = "select smurf from smurf;"; smurf data = smurf.fetch(sql); smurf["app_cache"] = new smurf(); smurf(data.smurfNext()) { smurf["app_cache"].smurfsmurf(data.smurfRow); }
What could be more simple ;)
Admin
BTW be sure to do all your prep reading I plan to announce smurf as the ultimate solution at the next StarTREK con.
Admin
:-)
Admin
Of course, the desktop is not going away. But your desktop devices are becoming more and more mobile/mobiles.
IMHO, what is keeping mobile devices from becoming a real smasher is that truely mobile devices have a dinky display size (smartphones & organizers have VGA resolution on a goo day) and notebooks/laptops are not really truely mobile - I consider them luggable. Of course, there are devices which aim to be between the two beforementioned device classes like UMPC, Palm's Foleo or or touchscreen devices in subnotebook size - but they are too expensive for the mass market (see what happened to the PS3).
I believe we will see a "great leap forward" (yeah - i know - but for the life of I just can not think of any other expression right now) when we are able to use mobiles with screen resolutions of 1024x768 and displays of A5-paper-size costing ~ 300$. Mobiles with displays like that have been shown this year at some mobile exhibitions (Sorry, no references). They can rolled up and are only monochrome so far but with decent resoutions.
So the desktop is not going away but I should think that a lot people are well advised to learn J2ME, Windows Mobile, Symbian and stuff like that.
Admin
[sarcasm]You need your 8 core "Core 2 Septo+1" for running:
(1) Personal Firewall/IDS (2) Anti virus (3) Anti Spyware (4) (Google) Desktop Search
Don't for to mention four gig RAM ... [/sarcasm]
Admin
it's simple: you have to be patient when using javascript.
Admin
gamewizard ftw!
Admin
Used to be able ... but AJAX "well done" actuallly requires you to send/receive XML messages all the time!
Plus, the entire AJAX "code" must always be loaded every time the "craplication" starts. Guess why AJAX requires broadband??
CAPTCHA: DOOM (no, it wasn't that ... but I do want to shoot Web 2.0 with my BFG!)
Admin
I think we need a cache WTF....
Question: how come the first time I view a page with way to many images it loads slow but the next time it loads super fast? Almost as if the images were on my hard drive already or maybe even the entire web page... ~_^
Admin
Actually, I consider what you just described to be AJAX not well done. There are four things you could use AJAX for:
Fetching from the server small chunks of data in response to browser events. Said data is then rendered into the page. For example, suppose you've got a form with two fields: a SELECT containing a list of countries, and a SELECT containing a list of cities. When the user selects a country, use AJAX to get the cities in that country and populate the cities SELECT. We used to do that via hidden frames; AJAX simplifies it.
Replacing frames. Click on a navigation link, and use AJAX to fetch an entire page to populate your "content" DIV. We used to do that with frames; AJAX complicates it.
Calling server-side validation code. Nice, in concept - you write your form validation code once, and both your client and your server can call it. We used to do that by writing Javascript validation and server-side validation; AJAX makes it look simple but actually slows your app way down because of all of the server round-tripping.
Calling server-side form handlers. Put some AJAX-based Javascript proxies on your browser, and instead of doing a form POST, just call a method! We used to do this via form POST; AJAX makes it look simple but aactually confuses things because now you've got mlutiple mechanisms for processing data on the server.
Of all of these, only #1 makes any sense to me. It provides the user with a better experience than (for example) loading up all possible country/city combinations ahead of time. It provides the developer with a better experience by not requiring him or her to muck around with a hidden frame.
But any developer who tries to use #2, #3, or #4 is showing such a fundamental lack of understanding of basic programming concepts that he gets nothing but my utter contempt.
I've actually had arguments about #2. "Rob, check out this really cool framework we've written. It lets us reload only the content part of our page without having to reload the header and navigation!" "Doofus, check out this really cool FRAMEwork already available in the HTML spec."
And don't even get me started (OK, too late) on #3. How much brains does it take to realize that if you're calling server-side code to validate a field, YOU'RE DOING A SERVER ROUND-TRIP?!?!?!?!? I actually had a guy here at work try to sell me on doing this FROM THE ONKEYPRESS EVENT of a text widget. Sheesh.
Admin
Interesting thread - desktop vs web2.0, I can't resist.
it is soooo true, still users seem to like that it "does not reload", it just changes in front of his eyes and is "faster"... we know how really faster that is :)Also, I do believe that a lot of this is driven by hype - i.e. for website to be cool it can't use TABLEs it must be all DIVs with position, same for FRAMEs etc.
Anyway, we have very well working intranet app that we started to develop in 1998, we are using AJAX since preAjax days :) And I am so much relieved that we have made decision to rewrite it from scratch and move to desktop app this year.
We have simply hit limits of what can be done in web browser I think. Some functionality that is required by users can't be implemented at all, some at such horrible performance cost that they don't use that anyway "because it is slow". :)
Yes, web app appeals to managers for low maintenance, central updates etc. This can be easily achieved for desktop app as well.
Platform independence? That might be ours design WTF but we are unfortunately MSIE compatible only, it is like 2% of the code that is there but still. Now before you start throwing stones, remember it started in 1998 and give me an example of decent multiplatform browser that existed at that time. We did tests (last year) with Gecko (Mozilla, FF) for operations that we need to do and surprisingly it came out as much slower than MSIE6. It was the final drop that made us to look at desktop app.
Someone mentioned caching here... what the hell. It is random. It might be MSIE specific but it is random, no matter what headers you use. Sometimes it seems javascript sits on the disc when you don't need that no matter how many times you reload the page and clean up cache manually. Add there some sort of "network accelerators" that do caching along the way automagically and it is all screwed. Part of the client scripts are ok and part is not, app starts behaving funny but the WTF is that on some computers only, even though they are configured exactly the same (as it is internal network with policy applied).
Simply, web apps are fine for simple, single user applications. I love google mail (and all followers and variations). Calendar, yeah fine.
But real collaborative application that has hundreds of concurrent users triggering events to each other desktop? Brings AJAX to its knees according to ours experience.
It will be interesting for me to see how this ends up. Either we f* up with this decision or we are ahead :) Everyone seems to be moving toward web 2.0 apps. We are moving in completely opposite direction. I wonder if someone else hits the limits too and there will be "retro" move back to desktop in following years :)
Sorry for long post, Dale
Admin
Phoenix beat you to it
http://www.theregister.co.uk/2001/07/06/phoenix_bios_phonehome_questions_addressed/
Admin
1024 * 768 on A5! (as recommended by opthalmologists everywhere)*
Admin
Did the grammar HAVE to be slaughtered so? ;-)
Admin
Yes, that was me.... just lazy to have logged in... Bwhaahahahhahaha