For anyone who was wondering whether the DMCA, or DRM, had anything to do with piracy, look here:
Glider violates the provision of the DMCA that prohibits "trafficking" in software that is "primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work" protected by copyright.
Sounds pretty open and shut for Glider...
But unless I'm missing something, that's a valid interpretation of that language -- any technological measure which controls access to a work.
Not "prevents piracy", or "prevents duplication", or even "prevents already-illegal stuff that we didn't need a new law for anyway."
No, it's all about control. It's about preventing you from using stuff you legitimately bought in new and interesting ways, so they can sell it to you again in those new and interesting ways. Or it's about preventing you from doing something that damages them in a completely unrelated way, if they can.
It's about taking control away from the consumer, and putting it back in the hands of the publisher.
If it stops piracy, great. But I don't think that they could've come up with something this devious by accident, especially when it's clear how ineffective the stuff is at its supposed purpose (preventing piracy).
For Vista it's "some of my apps will not work". The majority still does.
I've found that, in practice, the experience is often similar migrating to Linux, or to a greater extent, OS X.
What's more important is that, as time goes on, more and more do work, and it happens much more quicker than, say, ports of those same (or functionally equivalent) apps for Linux
Well, those ports (or functionally equivalent) apps...
Hold it, hold it, hold it. Did you actually say, "more quicker"? For serious? You might have a good point, but it's hard to see it when your grammar makes me wince.
(To the grammar pedants about to mod me hypocritical: "For serious" is a Zoolander reference.)
Ahem. Those ports, or functionally equivalent apps, could well have a much longer lifespan on Linux, especially if they are functionally equivalent open-source apps. There is no such thing as end-of-lifing a sufficiently popular open source product.
Microsoft can pull the rug out from under you and tell you that.NET is the new way to do it now, and you're still going to have to port that buggy app every release cycle. Port it to an open system, and you've taken back control.
Because it's not always the app that's buggy.
it's much easier to port a broken app to Vista than it is to write a new one for Linux.
Is it easier to port a broken app to Vista than to port the same app to Wine (or Winelib), though? I guess that depends on the app...
Short answer: Not yet. But given at least the simpler server-side validations, I see no reason you can't use those to generate javascript on the client side, for validations which are simple regexes, length, etc. And for those which aren't -- uniqueness, for example -- it's even easier, and I wrote a method to do that myself -- just have the client request that the server run the same validation code it would if you submit the form.
Or, javascript engines aren't hard to run by. Just take the client-side code and run it on the server, too.
Either way: Really not a hard problem.
The point here was the extra development time required to do the validation upfront.
No, the point being made was that it was somehow impossible, or that most web apps wouldn't do it.
I think they didn't mean technically advanced, just ones that can do their job & end up waiting for post responses, switching between keyboard and mouse and tabbing through unnecessary fields.
Probably. But I am basing this around the assumption that there will be at least one technically advanced user in the office -- there are tons of personal-itch hacks in VBA, even among management types. I expect there would be personal-itch Greasemonkey scripts, as well, and there probably are already.
Poor design is not unique to the web, but some consistent keyboard shortcuts aren't much to ask for - eg Enter for form submission anyone?
Just so. And there's no particular reason you can't add keyboard shortcuts to a web app, also. Depending on the browser, there's no reason you can't do do stuff like this, which I know to work on Firefox, at least.
And none of this is standing still. It's already to the point that even if you accept all of these arguments at face value -- you say, yes, validations are going to be duplicate code, and cross-browser headaches, and so on. Even if all of these are valid, there are still pretty compelling reasons to build it as a web app.
But I think most of those, even if they're an issue today, won't be a year from now. The form validation, if it's not already done, I could write myself.
makes Javascript form validation pretty worthless from a data standpoint.
Absolutely, I didn't mean to imply otherwise. People could always use browsers that don't support Javascript, or just POST directly without a browser, using tools like Curl.
But I was replying to someone who claimed that you can't validate instantly, and that's simply not true, even if you still have to revalidate it once they submit the form.
I don't mind it -- going to continue using quote tags, if you don't mind. Raw habit.
Column names scroll up out of range
Easy enough to keep them in place, or even rip the whole row out and put it outside of the container, with a little CSS.
you cannot widen or narrow columns as needed by dragging the borders.
And a little Javascript fixes that.
many may not work when IE 8 comes out, for example.
If this is a huge problem, force your users to install Firefox. I don't see why that would be harder than forcing them to install your random little app.
The author didn't have IE8 around when they developed it because it didn't exist yet.
And as IE8 betas start to show up, the authors add support in that library.
In that way, it becomes exactly as boring and transparent as what parts of OpenGL are implemented in software or in hardware, and what parts of the driver are in kernel space or the GL libraries. I just tell the library to draw a triangle, and it draws the triangle.
They often rely on poorly documented or undocumented features of DOM/CSS that could easily go away or not work in future browser versions.
Not the ones I use, certainly not what you just described about an HTML table. Mouse events, resizing elements, and floating elements on top of a scrolling window -- or, alternatively, a div set to add a scrollbar on overflow -- are all well understood, well specified, and well supported.
Browser add-ons defeat part of the purpose of using web-apps instead of desktop installs.
You're missing the point of addons, then.
I'm not saying an app should require addons. It should work well enough on a standard browser.
I'm saying addons are a way for a user to script that app -- without which, you'd have to embed a language like Python or Lua and develop your own scripting framework.
For example: Slashdot works well enough without addons. However, there is a Greasemonkey script which provides a quick confirmation system for moderations. And Slashdot didn't really have to do anything, other than be a website, to enable that scriptability.
The biggest problem/risk is Microsoft sabotaging JavaScript/DOM/CSS. They can and will if web-apps take up too much desktop sales.
The way I see it, they tried and failed. There's too much chance now that, if Microsoft actually does break the Web sufficiently, large sites that people rely on like Google, Myspace, etc, will start forcing people to switch. If you can't get onto Facebook from IE, that's easily over a hundred million IE users Microsoft just lost.
So, they have been dragging their feet, because they don't want to make the problem worse, and because they do want it to still be sufficiently painful that people want to use Silverlight.
But they've also been making real progress so that people won't abandon them entirely.
Oh, and again, Javascript frameworks mean we don't really have to wait for Microsoft. I use CSS2 properties every day, probably even some CSS3, via jQuery -- if run on a browser that supports these natively, it Just Works. If run on IE, a workaround is applied.
Microsoft has already realized this, and that's why it started over with.NET.
Which, again, presents the problem of, why bother?
If you're going to be learning a new platform anyway, and forcing users to download a whole runtime anyway, why not build it as a web app, where you can completely control the platform on the server side, and the client is at least mostly going to be running standards?
And once you're on the Web, even if you're doing it with ASP.NET (which does run under Mono, by the way), you're yet another reason desktop Windows doesn't matter.
You're probably wondering why there's not a project of Firefox or OO.o quality for experimental physics but I'll tell you why: it's too specialized and your user base is ridiculously small. You're not going to find a company that is going to benefit greatly (or at all maybe) by releasing their product into the wild for a community to grow.
That raises another question: Why isn't there, then, a Linux or Apache of experimental physics software? Not ever open source project was born in the belly of a corporate beast which later got the Free Software Religion.
I would also say that this is exactly the case where having source code available should be a requirement. Even if it stays a commercial program, and even if you have to pay to see the source, this is exactly the kind of specialized niche which is only likely to get more specialized, where chances are, for many things you want to do, you're going to want to customize the software in order to do it.
I would hope, at the very least, that if one of those commercial versions fails, that the corporation releases it to the community before bankruptcy. The smaller the niche, the more harmful abandonware is.
Unfortunately, there is no way to "fuck DRM" other than to release a triple-A game without it, and watch it become a success.
If you purchase the games, you're showing them DRM doesn't impact legitimate sales. The best you can do at this point is complain loudly to their support department, which will tell them that either their customers are whiners, or they need to invest in a better (easier-to-use) DRM scheme next time.
If you pirate the games, you're a statistic for how rampant piracy is, which means they'll feel the need to invest in better (stricter) DRM next time, to prevent you from pirating it.
And no, they will never make the connection that the ease-of-use of a product is inversely proportional to the strength of its DRM.
If you buy it on consoles, you're a statistic for how the PC industry is dying in favor of consoles, which have even tighter DRM -- and which will have people trying to make PCs more like consoles, and make more PC games which have been dumbed down to appeal to console gamers.
If you simply don't buy the game, you're a statistic for how the economy is sucking, and maybe for how the PC industry is dying in favor of nothing in particular -- which will tell them they'd better tighten the DRM or those filthy pirates will eat even more into their dwindling profits.
There is simply no way to send the message by voting with your dollars, because they will always find a way to twist it into more DRM. There are companies whose sole reason for existing is DRM, and thus, people in the marketing departments of said companies have made it their job to twist any statistic into a reason to sell their product.
Note: I didn't say "good", or "the right way", or even "useful". Just OK.
First, let's consider:
Steam is just the same as the rest, it's just that Steam is blatant about it's constant need to authenticate
Yes, that is true. That already makes it far more honest than most of the other systems out there -- you know, ahead of time, that if a game requires Steam, it will insist on being connected. If you can verify that it only uses Steam's own DRM, then that's all it requires. With systems like, say, SecuROM, you never know if it requires a CD check, whether it's 5-installs-then-you're-boned, or whether it's rape-and-pillage-your-system-for-anything-resembling-daemontools.
So, it's up front, right there in the open. About the only thing they could do to make it more clear is start disallowing DRM other than Steam on Steam games.
And once we have that all out there on the table, it honestly seems like a fair trade to me.
In general, it leaves the rest of my system alone. All it needs is an Internet connection, a username, and a password -- which I'll want anyway for a friends list, to play multiplayer games, to download something else in the background, maybe I want to play Pandora while I play a game. (I simply don't lose Internet for a week.)
In return, there's the friends list, achievements, community, and the ability to download any game I own on any computer, as many times as I like.
So, what they've managed to do is at least make the legitimate version, DRM and all, competitive with the pirated copy. That's why people are so excited about it, because that's the part most DRM schemes completely miss -- they make the legitimate copy worse than the pirated copy. Steam makes it as good or better.
Could it be better? Sure! Take any MMO -- then the above network effect is real, not artificial. You could have a friends list that was optional, and an offline mode in Steam that worked forever. But you couldn't have offline World of Warcraft -- it just wouldn't make sense.
I think that's as good as it's going to get without going completely DRM-free -- which I do support -- or open source, and free-as-in-beer, and somehow come up with a business model around that -- which is awesome, if you can do it.
So yes, I do like Steam. I don't think it's the Savior, or the last word, or anything like that. I do think it's a damned good compromise.
(For GAMES. Don't even think about using it for movies or music.)
They are not going Mac or Linux. The apps are not there.
They are not going to Vista or Windows 7. The apps are not there, either.
Here's the essential problem: Microsoft cannot simply keep trading on backwards compatibility alone. Sooner or later, despite their best efforts to sabotage standards, the Internet will come along and eat their lunch.
In order to keep that from happening, they need new Windows-exclusive apps, not just legacy ones. Which means they need to make Windows actually an attractive platform to develop new stuff on. Which is kind of hard, when despite IE, the Web is such an attractive platform already.
For me, personally, it's bad enough to have to deal with IE. I really wouldn't look forward to fighting the Win32 API.
But at the same time, their biggest selling point to all their existing customers is, "It's what you're used to!" and "It'll run your old apps!" In order for either of those lines to work, they would have to make as little progress as possible -- the best strategy, from that point of view, would be to sell XP SP3 as a new OS, instead of writing Vista.
So, looking at that, they do seem pretty screwed. They have to innovate or the new kids will all start using Linux and OS X. But they can't innovate, because the more dramatic the improvement, the less they can use their 800-pound-gorilla of compatibility, and the more they'll have to actually compete with Linux and OS X on a level playing field.
I don't think they can. If I was a Windows user, looking at the Vista situation, I'd think "I can use Vista, and none of my apps will work. Or I can use Ubuntu, and none of my apps will work, and the OS won't suck as much."
And I don't really see how they can resolve this situation. It truly seems like a catch 22 -- every step forward is nearly guaranteed to break compatibility, and every effort to preserve compatibility is likely to prevent a step forward.
So, why aren't they dead? Well, to quote Joel Spolsky:
Microsoft has an incredible amount of cash money in the bank and is still incredibly profitable. It has a long way to fall. It could do everything wrong for a decade before it started to be in remote danger, and you never know... they could reinvent themselves as a shaved-ice company at the last minute.
He wrote this four years ago, so the recession may have changed things, but not by much.
* Edit Grid - A standard editable "grid" control to provide a spreadsheet-like data grid (AKA "Table Browser"). Extra points for allowing different widget-types in the grid, such as combo-boxes, check-boxes, etc.
I don't get how this is hard. You might even use actual HTML tables (gasp!) to lay it out. What is it that's not working about these?
As this seems to be a theme, let me summarize:
* Combo Boxes (hybrid text and drop-down list) * Tabbed sub-portals or sub-forms * Collapsible tree/outline browser * Formatted Masking and/or Validation - Example: Date entry
These are not only done in Javascript/CSS/DOM, but they have been done so many times that you can pretty much pick up a jQuery plugin, throw in a one-liner on the client and maybe five or ten lines on the server, and you're done.
This is also not valid:
Many of these can be emulated via JavaScript+CSS/DOM, but the results tend to be unpleasant and browser-version-sensitive.
You'll have to be more specific about "unpleasant" -- I find them quite pleasant. And the browser-sensitivity is hidden away in a library somewhere, where I don't have to care about it.
* Menus (menus in JavaScript+CSS/DOM with frames are a nightmare)
So don't use frames. (Seriously, who uses frames?)
I'll amend that: Use iframes if you must. Otherwise, stick to emulating them with CSS, maybe even AJAX -- that way, your users get bookmark-ability.
* Pop-up Dialog Boxes - (Tabbed browsing and IE's security prompts have made the traditional "target=_blank" solution less desirable.)
That's most often a UI mistake, IMHO. It's much cleaner and friendlier to put the options in that "dialog box" in some expandable/collapseable block next to the element it affects. A notable exception might be editing a spreadsheet formula, which has a dedicated area elsewhere on the screen.
Popping something up, if it's done right, means you've now covered up what the user was doing -- which might include information that goes in that dialog box -- and you've restricted their navigation, and you're adding modality to the application which doesn't need to be there.
However, I got overruled at work because of how trivial the jQuery Boxy plugin makes it to throw up a dialog box -- within the same page, of course, not a popup, but it can be made draggable, so not as obnoxious.
* MDI-style Interfaces
The browser is your MDI-style interface. A properly designed app, and you should be able to middle-click on any link and have it open in a new tab. Depending on your browser, you should be able to pop tabs out of the window, move them between windows, or split a tab into panes.
Bonus: Having done it this way, the whole issue of which features to include inside that MDI window is completely removed. It supports whatever the browser supports. If the user wants something you didn't think of, they can just use a different browser, or install a browser addon. How were you going to make your desktop app that extensible?
* Right-Click Features or Menus
Apple has a point -- while right-clicking is great, you shouldn't rely on it.
That said, Google Docs seems to do a decent job of that. I can't imagine how it would be hard -- what is it, an "OnRightClick" event?
I would say, if you're still in doubt, go look at some of the things that have been done with, for example, EXTJS. I hate to mention that library -- the developer did a pretty shitty thing with his license, and we dropped it like a rock for jQuery -- but it has some pretty impressive demos.
The only problem I see with the "webby workarounds" is that you can get them wrong (which is true of anything), and that they are technically slower than a native widget library -- but that will only improve, and performance is already more than "good enough".
From what I remember, the Thai king often pardoned people for that. If so, good move -- harder to say bad things about someone who just saved you from 15 years in a Thai prison.
Also, I seem to remember hearing how much the Thai love their king.
If these are true, I wouldn't say they're less attuned to the "sentiment of their populace", but to the rest of the world, and to the realities of an information age.
That "rising tide" of anti-monarchy sentiment would be, at least at first, no more and no less sentiment than was already there.
The thing is, most browsers display stuff differently because they're not adhering to a common standard.
Thing is, there are always going to be variations. Sometimes these are bugs in a browser. Sometimes they're bugs in the standard -- places where the standard left some ambiguity.
Point is, the best way to find these is to have multiple browsers -- so, multiple browsers is a Good Thing. However, it also means just a bit more work testing your app.
There is less reason for me to develop for IE if they're going to belligerently never fix a compatibility issue with their browser.
Agreed. I only do that if I'm being paid, and even then, depending on the app, I may simply insist that people upgrade.
In short; you easily could be relying on a common bug, but you just as easily might not be. There is no reason to second guess yourself for such a small return.
I only disagree that it's a small return -- or at least, relatively.
Once or twice a week, fire up a VM and test it in IE. There is at least one case where IE is stricter -- a few places other browsers will let me forget semicolons in Javascript, while IE will blow up.
And you need at least two browsers anyway. Most often, you need IE -- if you're lucky, you might be allowed to nag users, but you're still talking about a huge install base, most of whom will just leave if it doesn't work. You also need Firefox, because Firebug is awesome -- nothing I've seen on another browser even comes close.
The few cases where I find a bug in a browser -- especially one other than IE or Firefox -- there's the much greater return of helping the cause of web standards by reporting that bug. Everyone except Microsoft and Adobe, I'm sure, will find that supporting those standards is in their best interest -- that bug will likely be addressed.
I'm posting this from Konqueror, for what that's worth.
Also, If most servers you connect to are no where near that it's a waste.
I have 100 mbit, and I can tell you that while most servers aren't anywhere near that, it's not a complete waste. I can run torrents without even thinking about whether I'm lagging others in the house -- I'm not. Ditto for YouTube, or just about anything else.
And, plenty of sites will let you download as much as you like.
And then with Charter hating P2P people, you wont get any faster Torrents.
Yeah, there is that. And with Charter actively inserting ads, it won't be much good for legit surfing, either.
$65/mo, 100 mbit, seems to be down and up. It's just shameful -- I can scp files between home and work faster than I used to be able to scp them around a LAN.
I live in a small town in Iowa, and $65/month gets me 100/100 + phone. (They refuse to unbundle it completely -- it's that or pay more and get TV instead of, or TV with, that phone.)
Actual, real Internet connectivity may be less than that, I'm not sure. However, I have gotten sustained 11 megabyte per second transfers between home and work, with both on the same ISP. That's video data, over scp -- so while there is compression happening, I doubt it's doing much.
Doesn't seem quite full-duplex -- I'm getting about 7 megabytes each way, transfering files both ways over SCP, as I type this. But that should be plenty for video. It usually ends up being about 4 to the actual Internet -- again, plenty.
So I'm feeling pretty smug, reading this. Also a bit saddened -- all that happened here is, the ISP in question got a grant, so installations are free instead of many thousands of dollars, and they're in the habit of actually buying more bandwidth, rather than hassling high-bandwidth users. WTF is the problem with the rest of the country?
While I think the arguments against web-apps are valid, it is the newest trend and people will not listen.
There are also very good arguments for web apps, particularly for cross-platform ones. However, there is an equally rising trend of people who hate the Web, or at least hate it being used for applications, for no rational reason.
I, too, think "Web 2.0" is a ridiculous term. But that doesn't mean everything done in its name is wrong.
And then people will still not undterstand what the problem is, just that there were expensive catastrophies.
That's almost a certainty.
I was reading earlier, and someone was commenting on how web apps are inferior to traditional fat clients because a fat client can validate instantly, whereas a web app has to wait for you to submit the form.
Fact is, if people do blame it on web apps, it almost certainly won't be rational, and I can pretty much guarantee the reactionary trend will be even less rational, or practical. Think back to the days of VBA being used for critical apps, and thousands or millions of dollars being lost because of a misplaced Excel spreadsheet -- was that really better?
What I think he is really saying is that data validation is better handled by traditional desktop apps a lot better than web apps.
Javascript was created specifically for the purpose of validating forms. I think it still does fine at that.
In most web apps a user puts in info, presses next and then when something isn't right they be punted back to the same form with maybe a message explaining why.
Bad app, not bad platform. In my web apps, you will often be punted back (because I'm lazy and haven't finished it), but there will always be a message explaining why. And in the fields which you might have to try frequently, like username, it will do that validation in realtime.
But there's no reason you can't validate everything immediately. The main reason you see it done that way is it's more important to validate it on the server, so that's what gets done first. In far too many apps, desktop and web alike, it's done in the other order, so if you sniff the network traffic, you can do anything you want.
since most are just glorified wizards, web apps quickly become a productivity bottleneck for advanced users.
Again, that's a symptom of "most" web apps, not a warning away from the platform as a whole.
For that matter, what kind of "advanced users" are we talking about here? A well designed web app will be RESTful, meaning it's trivial to develop a script that talks to it, or any kind of frontend you want. The savvier users might start developing and sharking Greasemonkey scripts. How, exactly, were you proposing to add scriptability to a desktop app?
why bother with it in enterprise applications? A company can require the install of anything they want in their required configuration, so why not a rich client that follows UI standards?
First, the browser is going to give you a lot of UI standards, nearly for free. Users used to web apps will start wanting things like a tabbed interface, a back button, bookmarks...
Second, because you get some of the more important advantages of a thin client. If everything your users need to do is in a web app, this has several important effects: You're free of Microsoft (you can just give them a bare-bones Linux box that boots to Firefox), the machine is interchangeable (if it fails, just replace it with a fresh one and the user can simply login again), telecommuting is easier (just grab whatever you trust and open the app via SSL), and maintenance is much easier, just upgrade the app in one place and everyone gets the upgrade. As for upgrading the clients, much easier to push out a browser update and a few OS updates than all that plus a half-dozen custom application updates.
Sure, it's easier in an enterprise environment, because you can mandate a browser. If your developers like Firebug, your users will use Firefox, end of story. But your comment assumes that there are advantages to a rich client...
Speaking of which, the browser is much smarter than a VT or an X server. Just about anything you'd need to do in a business app -- especially a simple form-type interaction -- you can do client-side.
Basically, you get all the advantages of a thin client, and all the advantages of a rich client, except for a few areas (extremely high-performance, 3d, or needing a lot of local disk storage) -- and those are being worked on (JS keeps getting faster, Flash supposedly has 3D now, and things like Google Gears and Adobe AIR are providing ways to access the local disk.
For the vast majority of enterprise apps -- the kind that would work just fine as thick clients on 10-year-old computers, or even as DOS apps when that was the new thing -- the Web is pretty much all upside, if done right.
...and so on. Same for client-side code -- 99% of what I want to do Just Works with jquery and a little careful CSS. The other 1%, I fill either with plugins or with
if($.browser.msie()) {... }
However, the latter is rare -- I find that, for the most part, I have a small-ish ie.css and ie.js.
I've recently started playing around with Adobe's Webkit-based AIR framework for this reason. It lets me interact with the local file-system, have a data store that's not reliant on a network, and above all, has a consistent UI environment.
I see the appeal, but I'd still lean towards something more open -- like Firefox with Google Gears. You can always mandate a consistent UI by forcing a browser (which is essentially what AIR does), but that way, you can avoid Adobe pulling the rug out from under you.
While I don't think the current system is ideal, I also don't see why we can't also build open source web apps, even variants which can be downloaded and run on the client, if you're wanting control.
If you're just wanting to be able to work without a connection, well, Google Gears.
My main motivation for going with web apps is, there's a ton of great tools, it's GUI programming I know how to do, and it works almost everywhere, without forcing users to install software.
It's also easier to deal with browser differences than OS differences. I can develop and test on Linux, occasionally fire it up in IE, and be reasonably confident it will work. Contrast this with when I was trying to use Perl on the client, and, well, I had to go set it up manually, download CPAN modules, etc.
Slashdot Mirror
For anyone who was wondering whether the DMCA, or DRM, had anything to do with piracy, look here:
Glider violates the provision of the DMCA that prohibits "trafficking" in software that is "primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work" protected by copyright.
Sounds pretty open and shut for Glider...
But unless I'm missing something, that's a valid interpretation of that language -- any technological measure which controls access to a work.
Not "prevents piracy", or "prevents duplication", or even "prevents already-illegal stuff that we didn't need a new law for anyway."
No, it's all about control. It's about preventing you from using stuff you legitimately bought in new and interesting ways, so they can sell it to you again in those new and interesting ways. Or it's about preventing you from doing something that damages them in a completely unrelated way, if they can.
It's about taking control away from the consumer, and putting it back in the hands of the publisher.
If it stops piracy, great. But I don't think that they could've come up with something this devious by accident, especially when it's clear how ineffective the stuff is at its supposed purpose (preventing piracy).
For Vista it's "some of my apps will not work". The majority still does.
I've found that, in practice, the experience is often similar migrating to Linux, or to a greater extent, OS X.
What's more important is that, as time goes on, more and more do work, and it happens much more quicker than, say, ports of those same (or functionally equivalent) apps for Linux
Well, those ports (or functionally equivalent) apps...
Hold it, hold it, hold it. Did you actually say, "more quicker"? For serious? You might have a good point, but it's hard to see it when your grammar makes me wince.
(To the grammar pedants about to mod me hypocritical: "For serious" is a Zoolander reference.)
Ahem. Those ports, or functionally equivalent apps, could well have a much longer lifespan on Linux, especially if they are functionally equivalent open-source apps. There is no such thing as end-of-lifing a sufficiently popular open source product.
Microsoft can pull the rug out from under you and tell you that .NET is the new way to do it now, and you're still going to have to port that buggy app every release cycle. Port it to an open system, and you've taken back control.
Because it's not always the app that's buggy.
it's much easier to port a broken app to Vista than it is to write a new one for Linux.
Is it easier to port a broken app to Vista than to port the same app to Wine (or Winelib), though? I guess that depends on the app...
Not so. All of your apps that worked on XP also work on Vista and will continue to work on Windows 7.
For some value of "all".
Making it run the same validation code isn't trival
Here's a starting point...
Short answer: Not yet. But given at least the simpler server-side validations, I see no reason you can't use those to generate javascript on the client side, for validations which are simple regexes, length, etc. And for those which aren't -- uniqueness, for example -- it's even easier, and I wrote a method to do that myself -- just have the client request that the server run the same validation code it would if you submit the form.
Or, javascript engines aren't hard to run by. Just take the client-side code and run it on the server, too.
Either way: Really not a hard problem.
The point here was the extra development time required to do the validation upfront.
No, the point being made was that it was somehow impossible, or that most web apps wouldn't do it.
I think they didn't mean technically advanced, just ones that can do their job & end up waiting for post responses, switching between keyboard and mouse and tabbing through unnecessary fields.
Probably. But I am basing this around the assumption that there will be at least one technically advanced user in the office -- there are tons of personal-itch hacks in VBA, even among management types. I expect there would be personal-itch Greasemonkey scripts, as well, and there probably are already.
Poor design is not unique to the web, but some consistent keyboard shortcuts aren't much to ask for - eg Enter for form submission anyone?
Just so. And there's no particular reason you can't add keyboard shortcuts to a web app, also. Depending on the browser, there's no reason you can't do do stuff like this, which I know to work on Firefox, at least.
And none of this is standing still. It's already to the point that even if you accept all of these arguments at face value -- you say, yes, validations are going to be duplicate code, and cross-browser headaches, and so on. Even if all of these are valid, there are still pretty compelling reasons to build it as a web app.
But I think most of those, even if they're an issue today, won't be a year from now. The form validation, if it's not already done, I could write myself.
makes Javascript form validation pretty worthless from a data standpoint.
Absolutely, I didn't mean to imply otherwise. People could always use browsers that don't support Javascript, or just POST directly without a browser, using tools like Curl.
But I was replying to someone who claimed that you can't validate instantly, and that's simply not true, even if you still have to revalidate it once they submit the form.
I don't mind it -- going to continue using quote tags, if you don't mind. Raw habit.
Column names scroll up out of range
Easy enough to keep them in place, or even rip the whole row out and put it outside of the container, with a little CSS.
you cannot widen or narrow columns as needed by dragging the borders.
And a little Javascript fixes that.
many may not work when IE 8 comes out, for example.
If this is a huge problem, force your users to install Firefox. I don't see why that would be harder than forcing them to install your random little app.
The author didn't have IE8 around when they developed it because it didn't exist yet.
And as IE8 betas start to show up, the authors add support in that library.
In that way, it becomes exactly as boring and transparent as what parts of OpenGL are implemented in software or in hardware, and what parts of the driver are in kernel space or the GL libraries. I just tell the library to draw a triangle, and it draws the triangle.
They often rely on poorly documented or undocumented features of DOM/CSS that could easily go away or not work in future browser versions.
Not the ones I use, certainly not what you just described about an HTML table. Mouse events, resizing elements, and floating elements on top of a scrolling window -- or, alternatively, a div set to add a scrollbar on overflow -- are all well understood, well specified, and well supported.
Browser add-ons defeat part of the purpose of using web-apps instead of desktop installs.
You're missing the point of addons, then.
I'm not saying an app should require addons. It should work well enough on a standard browser.
I'm saying addons are a way for a user to script that app -- without which, you'd have to embed a language like Python or Lua and develop your own scripting framework.
For example: Slashdot works well enough without addons. However, there is a Greasemonkey script which provides a quick confirmation system for moderations. And Slashdot didn't really have to do anything, other than be a website, to enable that scriptability.
The biggest problem/risk is Microsoft sabotaging JavaScript/DOM/CSS. They can and will if web-apps take up too much desktop sales.
The way I see it, they tried and failed. There's too much chance now that, if Microsoft actually does break the Web sufficiently, large sites that people rely on like Google, Myspace, etc, will start forcing people to switch. If you can't get onto Facebook from IE, that's easily over a hundred million IE users Microsoft just lost.
So, they have been dragging their feet, because they don't want to make the problem worse, and because they do want it to still be sufficiently painful that people want to use Silverlight.
But they've also been making real progress so that people won't abandon them entirely.
Oh, and again, Javascript frameworks mean we don't really have to wait for Microsoft. I use CSS2 properties every day, probably even some CSS3, via jQuery -- if run on a browser that supports these natively, it Just Works. If run on IE, a workaround is applied.
Except, he isn't. His lackeys are.
Microsoft has already realized this, and that's why it started over with .NET.
Which, again, presents the problem of, why bother?
If you're going to be learning a new platform anyway, and forcing users to download a whole runtime anyway, why not build it as a web app, where you can completely control the platform on the server side, and the client is at least mostly going to be running standards?
And once you're on the Web, even if you're doing it with ASP.NET (which does run under Mono, by the way), you're yet another reason desktop Windows doesn't matter.
You're probably wondering why there's not a project of Firefox or OO.o quality for experimental physics but I'll tell you why: it's too specialized and your user base is ridiculously small. You're not going to find a company that is going to benefit greatly (or at all maybe) by releasing their product into the wild for a community to grow.
That raises another question: Why isn't there, then, a Linux or Apache of experimental physics software? Not ever open source project was born in the belly of a corporate beast which later got the Free Software Religion.
I would also say that this is exactly the case where having source code available should be a requirement. Even if it stays a commercial program, and even if you have to pay to see the source, this is exactly the kind of specialized niche which is only likely to get more specialized, where chances are, for many things you want to do, you're going to want to customize the software in order to do it.
I would hope, at the very least, that if one of those commercial versions fails, that the corporation releases it to the community before bankruptcy. The smaller the niche, the more harmful abandonware is.
Unfortunately, there is no way to "fuck DRM" other than to release a triple-A game without it, and watch it become a success.
If you purchase the games, you're showing them DRM doesn't impact legitimate sales. The best you can do at this point is complain loudly to their support department, which will tell them that either their customers are whiners, or they need to invest in a better (easier-to-use) DRM scheme next time.
If you pirate the games, you're a statistic for how rampant piracy is, which means they'll feel the need to invest in better (stricter) DRM next time, to prevent you from pirating it.
And no, they will never make the connection that the ease-of-use of a product is inversely proportional to the strength of its DRM.
If you buy it on consoles, you're a statistic for how the PC industry is dying in favor of consoles, which have even tighter DRM -- and which will have people trying to make PCs more like consoles, and make more PC games which have been dumbed down to appeal to console gamers.
If you simply don't buy the game, you're a statistic for how the economy is sucking, and maybe for how the PC industry is dying in favor of nothing in particular -- which will tell them they'd better tighten the DRM or those filthy pirates will eat even more into their dwindling profits.
There is simply no way to send the message by voting with your dollars, because they will always find a way to twist it into more DRM. There are companies whose sole reason for existing is DRM, and thus, people in the marketing departments of said companies have made it their job to twist any statistic into a reason to sell their product.
Note: I didn't say "good", or "the right way", or even "useful". Just OK.
First, let's consider:
Steam is just the same as the rest, it's just that Steam is blatant about it's constant need to authenticate
Yes, that is true. That already makes it far more honest than most of the other systems out there -- you know, ahead of time, that if a game requires Steam, it will insist on being connected. If you can verify that it only uses Steam's own DRM, then that's all it requires. With systems like, say, SecuROM, you never know if it requires a CD check, whether it's 5-installs-then-you're-boned, or whether it's rape-and-pillage-your-system-for-anything-resembling-daemontools.
So, it's up front, right there in the open. About the only thing they could do to make it more clear is start disallowing DRM other than Steam on Steam games.
And once we have that all out there on the table, it honestly seems like a fair trade to me.
In general, it leaves the rest of my system alone. All it needs is an Internet connection, a username, and a password -- which I'll want anyway for a friends list, to play multiplayer games, to download something else in the background, maybe I want to play Pandora while I play a game. (I simply don't lose Internet for a week.)
In return, there's the friends list, achievements, community, and the ability to download any game I own on any computer, as many times as I like.
So, what they've managed to do is at least make the legitimate version, DRM and all, competitive with the pirated copy. That's why people are so excited about it, because that's the part most DRM schemes completely miss -- they make the legitimate copy worse than the pirated copy. Steam makes it as good or better.
Could it be better? Sure! Take any MMO -- then the above network effect is real, not artificial. You could have a friends list that was optional, and an offline mode in Steam that worked forever. But you couldn't have offline World of Warcraft -- it just wouldn't make sense.
I think that's as good as it's going to get without going completely DRM-free -- which I do support -- or open source, and free-as-in-beer, and somehow come up with a business model around that -- which is awesome, if you can do it.
So yes, I do like Steam. I don't think it's the Savior, or the last word, or anything like that. I do think it's a damned good compromise.
(For GAMES. Don't even think about using it for movies or music.)
They are not going Mac or Linux. The apps are not there.
They are not going to Vista or Windows 7. The apps are not there, either.
Here's the essential problem: Microsoft cannot simply keep trading on backwards compatibility alone. Sooner or later, despite their best efforts to sabotage standards, the Internet will come along and eat their lunch.
In order to keep that from happening, they need new Windows-exclusive apps, not just legacy ones. Which means they need to make Windows actually an attractive platform to develop new stuff on. Which is kind of hard, when despite IE, the Web is such an attractive platform already.
For me, personally, it's bad enough to have to deal with IE. I really wouldn't look forward to fighting the Win32 API.
But at the same time, their biggest selling point to all their existing customers is, "It's what you're used to!" and "It'll run your old apps!" In order for either of those lines to work, they would have to make as little progress as possible -- the best strategy, from that point of view, would be to sell XP SP3 as a new OS, instead of writing Vista.
So, looking at that, they do seem pretty screwed. They have to innovate or the new kids will all start using Linux and OS X. But they can't innovate, because the more dramatic the improvement, the less they can use their 800-pound-gorilla of compatibility, and the more they'll have to actually compete with Linux and OS X on a level playing field.
I don't think they can. If I was a Windows user, looking at the Vista situation, I'd think "I can use Vista, and none of my apps will work. Or I can use Ubuntu, and none of my apps will work, and the OS won't suck as much."
And I don't really see how they can resolve this situation. It truly seems like a catch 22 -- every step forward is nearly guaranteed to break compatibility, and every effort to preserve compatibility is likely to prevent a step forward.
So, why aren't they dead? Well, to quote Joel Spolsky:
Microsoft has an incredible amount of cash money in the bank and is still incredibly profitable. It has a long way to fall. It could do everything wrong for a decade before it started to be in remote danger, and you never know... they could reinvent themselves as a shaved-ice company at the last minute.
He wrote this four years ago, so the recession may have changed things, but not by much.
* Edit Grid - A standard editable "grid" control to provide a spreadsheet-like data grid (AKA "Table Browser"). Extra points for allowing different widget-types in the grid, such as combo-boxes, check-boxes, etc.
I don't get how this is hard. You might even use actual HTML tables (gasp!) to lay it out. What is it that's not working about these?
As this seems to be a theme, let me summarize:
* Combo Boxes (hybrid text and drop-down list)
* Tabbed sub-portals or sub-forms
* Collapsible tree/outline browser
* Formatted Masking and/or Validation - Example: Date entry
These are not only done in Javascript/CSS/DOM, but they have been done so many times that you can pretty much pick up a jQuery plugin, throw in a one-liner on the client and maybe five or ten lines on the server, and you're done.
This is also not valid:
Many of these can be emulated via JavaScript+CSS/DOM, but the results tend to be unpleasant and browser-version-sensitive.
You'll have to be more specific about "unpleasant" -- I find them quite pleasant. And the browser-sensitivity is hidden away in a library somewhere, where I don't have to care about it.
* Menus (menus in JavaScript+CSS/DOM with frames are a nightmare)
So don't use frames. (Seriously, who uses frames?)
I'll amend that: Use iframes if you must. Otherwise, stick to emulating them with CSS, maybe even AJAX -- that way, your users get bookmark-ability.
* Pop-up Dialog Boxes - (Tabbed browsing and IE's security prompts have made the traditional "target=_blank" solution less desirable.)
That's most often a UI mistake, IMHO. It's much cleaner and friendlier to put the options in that "dialog box" in some expandable/collapseable block next to the element it affects. A notable exception might be editing a spreadsheet formula, which has a dedicated area elsewhere on the screen.
Popping something up, if it's done right, means you've now covered up what the user was doing -- which might include information that goes in that dialog box -- and you've restricted their navigation, and you're adding modality to the application which doesn't need to be there.
However, I got overruled at work because of how trivial the jQuery Boxy plugin makes it to throw up a dialog box -- within the same page, of course, not a popup, but it can be made draggable, so not as obnoxious.
* MDI-style Interfaces
The browser is your MDI-style interface. A properly designed app, and you should be able to middle-click on any link and have it open in a new tab. Depending on your browser, you should be able to pop tabs out of the window, move them between windows, or split a tab into panes.
Bonus: Having done it this way, the whole issue of which features to include inside that MDI window is completely removed. It supports whatever the browser supports. If the user wants something you didn't think of, they can just use a different browser, or install a browser addon. How were you going to make your desktop app that extensible?
* Right-Click Features or Menus
Apple has a point -- while right-clicking is great, you shouldn't rely on it.
That said, Google Docs seems to do a decent job of that. I can't imagine how it would be hard -- what is it, an "OnRightClick" event?
I would say, if you're still in doubt, go look at some of the things that have been done with, for example, EXTJS. I hate to mention that library -- the developer did a pretty shitty thing with his license, and we dropped it like a rock for jQuery -- but it has some pretty impressive demos.
The only problem I see with the "webby workarounds" is that you can get them wrong (which is true of anything), and that they are technically slower than a native widget library -- but that will only improve, and performance is already more than "good enough".
From what I remember, the Thai king often pardoned people for that. If so, good move -- harder to say bad things about someone who just saved you from 15 years in a Thai prison.
Also, I seem to remember hearing how much the Thai love their king.
If these are true, I wouldn't say they're less attuned to the "sentiment of their populace", but to the rest of the world, and to the realities of an information age.
That "rising tide" of anti-monarchy sentiment would be, at least at first, no more and no less sentiment than was already there.
The thing is, most browsers display stuff differently because they're not adhering to a common standard.
Thing is, there are always going to be variations. Sometimes these are bugs in a browser. Sometimes they're bugs in the standard -- places where the standard left some ambiguity.
Point is, the best way to find these is to have multiple browsers -- so, multiple browsers is a Good Thing. However, it also means just a bit more work testing your app.
There is less reason for me to develop for IE if they're going to belligerently never fix a compatibility issue with their browser.
Agreed. I only do that if I'm being paid, and even then, depending on the app, I may simply insist that people upgrade.
In short; you easily could be relying on a common bug, but you just as easily might not be. There is no reason to second guess yourself for such a small return.
I only disagree that it's a small return -- or at least, relatively.
Once or twice a week, fire up a VM and test it in IE. There is at least one case where IE is stricter -- a few places other browsers will let me forget semicolons in Javascript, while IE will blow up.
And you need at least two browsers anyway. Most often, you need IE -- if you're lucky, you might be allowed to nag users, but you're still talking about a huge install base, most of whom will just leave if it doesn't work. You also need Firefox, because Firebug is awesome -- nothing I've seen on another browser even comes close.
The few cases where I find a bug in a browser -- especially one other than IE or Firefox -- there's the much greater return of helping the cause of web standards by reporting that bug. Everyone except Microsoft and Adobe, I'm sure, will find that supporting those standards is in their best interest -- that bug will likely be addressed.
I'm posting this from Konqueror, for what that's worth.
Also, If most servers you connect to are no where near that it's a waste.
I have 100 mbit, and I can tell you that while most servers aren't anywhere near that, it's not a complete waste. I can run torrents without even thinking about whether I'm lagging others in the house -- I'm not. Ditto for YouTube, or just about anything else.
And, plenty of sites will let you download as much as you like.
And then with Charter hating P2P people, you wont get any faster Torrents.
Yeah, there is that. And with Charter actively inserting ads, it won't be much good for legit surfing, either.
Well, I'm going to brag.
http://liscofiber.com/
$65/mo, 100 mbit, seems to be down and up. It's just shameful -- I can scp files between home and work faster than I used to be able to scp them around a LAN.
Their 20/20 plan is $65/month.
I live in a small town in Iowa, and $65/month gets me 100/100 + phone. (They refuse to unbundle it completely -- it's that or pay more and get TV instead of, or TV with, that phone.)
Actual, real Internet connectivity may be less than that, I'm not sure. However, I have gotten sustained 11 megabyte per second transfers between home and work, with both on the same ISP. That's video data, over scp -- so while there is compression happening, I doubt it's doing much.
Doesn't seem quite full-duplex -- I'm getting about 7 megabytes each way, transfering files both ways over SCP, as I type this. But that should be plenty for video. It usually ends up being about 4 to the actual Internet -- again, plenty.
So I'm feeling pretty smug, reading this. Also a bit saddened -- all that happened here is, the ISP in question got a grant, so installations are free instead of many thousands of dollars, and they're in the habit of actually buying more bandwidth, rather than hassling high-bandwidth users. WTF is the problem with the rest of the country?
While I think the arguments against web-apps are valid, it is the newest trend and people will not listen.
There are also very good arguments for web apps, particularly for cross-platform ones. However, there is an equally rising trend of people who hate the Web, or at least hate it being used for applications, for no rational reason.
I, too, think "Web 2.0" is a ridiculous term. But that doesn't mean everything done in its name is wrong.
And then people will still not undterstand what the problem is, just that there were expensive catastrophies.
That's almost a certainty.
I was reading earlier, and someone was commenting on how web apps are inferior to traditional fat clients because a fat client can validate instantly, whereas a web app has to wait for you to submit the form.
Fact is, if people do blame it on web apps, it almost certainly won't be rational, and I can pretty much guarantee the reactionary trend will be even less rational, or practical. Think back to the days of VBA being used for critical apps, and thousands or millions of dollars being lost because of a misplaced Excel spreadsheet -- was that really better?
I like C++ better than Javascript anyway :P
I can't remember if you're the one I talked to about this...
There are real reasons to prefer C++ to Javascript. The most common reason, though, is not knowing it well enough.
There are other languages I much prefer to Javascript, but C++ is not one of them.
I would humbly suggest that for the most part, you're better off working with the raw API than with MFC.
Not to say there aren't better abstractions, like the Web, or Ruby Shoes, etc.
What I think he is really saying is that data validation is better handled by traditional desktop apps a lot better than web apps.
Javascript was created specifically for the purpose of validating forms. I think it still does fine at that.
In most web apps a user puts in info, presses next and then when something isn't right they be punted back to the same form with maybe a message explaining why.
Bad app, not bad platform. In my web apps, you will often be punted back (because I'm lazy and haven't finished it), but there will always be a message explaining why. And in the fields which you might have to try frequently, like username, it will do that validation in realtime.
But there's no reason you can't validate everything immediately. The main reason you see it done that way is it's more important to validate it on the server, so that's what gets done first. In far too many apps, desktop and web alike, it's done in the other order, so if you sniff the network traffic, you can do anything you want.
since most are just glorified wizards, web apps quickly become a productivity bottleneck for advanced users.
Again, that's a symptom of "most" web apps, not a warning away from the platform as a whole.
For that matter, what kind of "advanced users" are we talking about here? A well designed web app will be RESTful, meaning it's trivial to develop a script that talks to it, or any kind of frontend you want. The savvier users might start developing and sharking Greasemonkey scripts. How, exactly, were you proposing to add scriptability to a desktop app?
why bother with it in enterprise applications? A company can require the install of anything they want in their required configuration, so why not a rich client that follows UI standards?
First, the browser is going to give you a lot of UI standards, nearly for free. Users used to web apps will start wanting things like a tabbed interface, a back button, bookmarks...
Second, because you get some of the more important advantages of a thin client. If everything your users need to do is in a web app, this has several important effects: You're free of Microsoft (you can just give them a bare-bones Linux box that boots to Firefox), the machine is interchangeable (if it fails, just replace it with a fresh one and the user can simply login again), telecommuting is easier (just grab whatever you trust and open the app via SSL), and maintenance is much easier, just upgrade the app in one place and everyone gets the upgrade. As for upgrading the clients, much easier to push out a browser update and a few OS updates than all that plus a half-dozen custom application updates.
Sure, it's easier in an enterprise environment, because you can mandate a browser. If your developers like Firebug, your users will use Firefox, end of story. But your comment assumes that there are advantages to a rich client...
Speaking of which, the browser is much smarter than a VT or an X server. Just about anything you'd need to do in a business app -- especially a simple form-type interaction -- you can do client-side.
Basically, you get all the advantages of a thin client, and all the advantages of a rich client, except for a few areas (extremely high-performance, 3d, or needing a lot of local disk storage) -- and those are being worked on (JS keeps getting faster, Flash supposedly has 3D now, and things like Google Gears and Adobe AIR are providing ways to access the local disk.
For the vast majority of enterprise apps -- the kind that would work just fine as thick clients on 10-year-old computers, or even as DOS apps when that was the new thing -- the Web is pretty much all upside, if done right.
What takes time, and what breaks, and what drives me nuts, is the UI - validation, layout, rendering quirks, etc., etc., etc.
I tend to use frameworks to eliminate a lot of that. After all, a lot of validation is very simple:
...and so on. Same for client-side code -- 99% of what I want to do Just Works with jquery and a little careful CSS. The other 1%, I fill either with plugins or with
However, the latter is rare -- I find that, for the most part, I have a small-ish ie.css and ie.js.
I've recently started playing around with Adobe's Webkit-based AIR framework for this reason. It lets me interact with the local file-system, have a data store that's not reliant on a network, and above all, has a consistent UI environment.
I see the appeal, but I'd still lean towards something more open -- like Firefox with Google Gears. You can always mandate a consistent UI by forcing a browser (which is essentially what AIR does), but that way, you can avoid Adobe pulling the rug out from under you.
While I don't think the current system is ideal, I also don't see why we can't also build open source web apps, even variants which can be downloaded and run on the client, if you're wanting control.
If you're just wanting to be able to work without a connection, well, Google Gears.
My main motivation for going with web apps is, there's a ton of great tools, it's GUI programming I know how to do, and it works almost everywhere, without forcing users to install software.
It's also easier to deal with browser differences than OS differences. I can develop and test on Linux, occasionally fire it up in IE, and be reasonably confident it will work. Contrast this with when I was trying to use Perl on the client, and, well, I had to go set it up manually, download CPAN modules, etc.
Do it with XUL, then. Or Google Gears. Don't tie yourself to such a broken renderer.