Best Browser For Using Complex Web Applications? 347
yanyan writes "I'm fairly new to the field of web application development. Currently I'm working on a big online ticketing system for passage and freight for a local shipping company. It's a one-man show and the system is written in Ruby and uses Rails. Aside from the requisite functionality of creating bookings the system must also print reports and tickets, and this is where I've discovered (the hard way) that most, if not all, browsers fall short. I've had to switch from Firefox 3.6.3 to Opera 10.53 because of a major printing bug in Firefox, but the latest stable Opera is also giving me its own share of problems. To complicate things, an earlier version of Opera (10.10) doesn't appear to have 10.53's printing problems, but I'm wary. What browsers and specific versions do you end up deploying for use with big, complex web apps that include printing? Also consider CSS accuracy and consistency."
but I thought HTML was supposed to fix all that? (Score:5, Insightful)
Hahaha, I kid, I kid. If your interface is complex, why are you using HTML/CSS/Javascript/etc? Why not take advantage of a more advanced and mature UI widget set, such as that provided by Java or *shock* the native environment?
The web is about where MacOS was 20 years ago in terms of ability to deliver a rich application UI experience. Google are excellent at marketing it as some sort of advance, but it really isn't. Don't shoehorn.
IE or Firefox (Score:5, Insightful)
Figure out what you need to do with your application to make it work in IE and Firefox is the only real solution.
Stop using the browser for print (Score:5, Insightful)
Chrome, PDF (Score:5, Insightful)
Even though I don't use it for development, I've got several of my clients using Chrome to take advantage of the Javascript engine. My applications use a lot of Javascript for the interfaces, and Chrome speeds up the rendering of large data sets compared to IE or Firefox.
For printing, the only solution to keep you sane is to export reports as PDF and let them print through their reader. That's specifically what PDF is for (consistency in displaying and printing). Depending on the report, they may also appreciate a CSV version that they can do their own filtering and sorting on.
Re:IE or Firefox (Score:3, Insightful)
The real world answer is go ignore IE and let all the people still using it go cry.
Writing to a specific browser... (Score:5, Insightful)
...is a much more serious bug than any possible printing problem.
Re:My experience: (Score:5, Insightful)
PDF gets used for all kinds of wrong reasons - I freaking loathe web designers who think a PDF is an appropriate substitute for a web page - but printing is the one place that PDF shines. Just make sure the user can easily and intuitively specify the paper size and you should be good to go.
Punch in the eyeball (Score:5, Insightful)
This is a classic example of a developer trying to tailor the user to the system instead of the system to the user.
Stop your whining and just make it work in one or more of the common browsers. I have been forced to bend crap environments to my will and I suspect that most developers around slashdot have bent bad systems until they cried; but made them work in the end.
Re:but I thought HTML was supposed to fix all that (Score:5, Insightful)
For recent programming languages, 5 years is a lifetime. Compare Java now to Java five years ago, or Javascript now to Javascript five years ago.
Re:but I thought HTML was supposed to fix all that (Score:3, Insightful)
Can you define that term? I have seen it used to refer to half a dozen vaguely related concepts so far, so it would be nice to know which one you are referring to.
"There's no shoehorn involved when it's the best tool for the job."
The web is not the best tool for every job though, which I think was OP's point.
Re:My experience: (Score:3, Insightful)
If the user is printing out standard forms to be used in shipping the last thing you want to do is let the user change the paper size.
Re:My experience: (Score:5, Insightful)
Absolutely agreed.
Anything mission-critical like printing a ticket should absolutely NOT use something that could cause the whole system to break down when a single trivial update happens. HTML wasn't designed for printing, and it never will be. The browser is just a band aid put on top of a fundamental disconnect in technology and application.
I'd even go so far as to say that unless you're outputting and printing from PDF or some other well defined and standardized print format, don't proceed any farther. You'll pay more for the problems down the road when the whole she-bang doesn't work for some dumb reason.
Re:Stop using the browser for print (Score:2, Insightful)
Re:IE or Firefox (Score:2, Insightful)
Actually, the real world answer is design it for IE. If it works in IE then it will work in everything else. Besides, the JavaScript debugger in IE (Visual Studio) is vastly superior to Firebug, and yes, I've used both... I just don't suck the open source/free software ****.
Re:My experience: (Score:5, Insightful)
He should at least make sure the form works with both A4 and Letter size papers, otherwise the company will be in for quite a shock when they decide to expand their business outside the US and find that the most common reaction to mentions of letter size paper is "Letter size? Is that what you call A4?".
Re:but I thought HTML was supposed to fix all that (Score:3, Insightful)
>The web is about where MacOS was 20 years ago in terms of ability to deliver a rich application UI experience.
Don't insult the mac like that. There were Mac apps back in 1984 that you can still only badly mimic via a web "application."
The fact is that a web browser is an application that retrieves and renders hypertext documents over a network, and nothing more. Just because it has scripting and the web can make available documents to huge numbers of people, too many people think they can shoehorn any kind of application in to it.
There is a huge demand for data entry and reporting (both viewing and printing) that web browser just aren't up to. If web browser ever get to the point where they have drag-and-drop form/report creation with a user interface that can be reliably delivered to client computers then great. Until then there needs to be something else to fill this void, and there just isn't. There used to be some very nice client/server GUI form and reporting tools back in the 90s, but most of those have devolved in to half-assed web tools with insane setup, configuration, and support requirements (and usually exorbitant enterprise pricing to boot).
Heck, the last time I checked no web browser could even reliably be told automatically to print a page landscape!
Re:but I thought HTML was supposed to fix all that (Score:4, Insightful)
I'm sorry but you have confused HTTP/HTML/Javascript with the internet.
The fact is that this trend of using the browser as an interface is nothing less than having a hammer and treating everything as a nail.
You've got it backwards. (Score:5, Insightful)
Re:IE or Firefox (Score:3, Insightful)
The real world answer is go ignore IE and let all the people still using it go cry.
That's not a "real world answer". That's an absurd geek fantasy. Love it or hate it, most people still use IE [wikipedia.org].
If you're a web developer, you cannot afford to ignore that your users will make choices about which browser they use that may be different than your own.
Re:IE or Firefox (Score:3, Insightful)
The real world answer is go ignore IE and let all the people still using it go cry.
.
No that is not the real world answer. If you don't get your application working in IE, the people will go find one that does. You might get away with not working in IE if your only designing for the tech crowd, but if your designing for business or the public, then your killing your own business before it's started.
Re:IE or Firefox (Score:3, Insightful)
I’m a long-term professional, and if you are developing for any specific browser, you are a failure, and not a professional.
The goal is to know the W3C standards by heart in every minute detail (yes, it can be done, since I did it for years without problems), and design to it. In a way that allows you to spot things where not you are wrong, but the browser is!
You only add browser-specific quirks after you’re done. Separated from the main code wherever possible.
Otherwise you end up with a huge non-working mess as soon as you notice that your nice giant backbone of your webapp only works because of a quirk/bug/weirdness of that specific browser.
Things like http://code.google.com/p/ie7-js/ [google.com] greatly help with this. :)
Re:You've got it backwards. (Score:2, Insightful)
Thank you for that insightful comment. I can't believe some of the answers here. Please mod up the parent!
To rephrase the parental answer: Your app has to work with all popular, modern browsers, and your app should be expected to change as new browsers, technologies, and browser quirks emerge. Not doing so is to build obsolescence into your app.
The moment you choose a specific browser for your app is the moment other products choose different browsers for their apps. Then the user is screwed.
New browser versions emerge, screwing you. Oh, the popular screenreader app is broken because you failed to consider it? That's YOUR problem. What, you don't support IE8 under SP4? That's your problem too. That's why web developers make good money - they do it right.
Alternatively, one can step backwards to a "client/server" app in VB or whatever and to hell with the web. Yeah, you got a huge deployment burden in front of you then, but it seems like you're going in that direction anyway.
Re:but I thought HTML was supposed to fix all that (Score:5, Insightful)
Apps like MET (link [picnet.com.au])
Yes, privacy implications are another great reason to avoid web apps.
Google Apps - YouTube
QED. All of these are pale imitations of native apps when it comes to feature sets, responsiveness and UI.
There has to be huge reasons to abandon web for native development.
Other way round, dude.
Java lost the applet battle about 5 years ago.
What does that even mean? Google Apps are mostly written in Java and translated, so clearly the largest web app producer on the planet likes the language (just not the level of control a client could maintain if Google actually deployed Java). Java is still going to execute faster than HTML/Javascript - hell, we're only just starting to see hardware 3D acceleration, something Java's had since 2001. If you're about to bitch that Swing is ugly, it can be skinned, or you can use SWT which builds on top of native widgets.
Of course, this is just an argument that Java is better than HTML/Javascript for client/server apps; the best solution is whatever gives the user the richest client experience, employing a domain-specific remoting protocol (e.g. IMAP for e-mail) for transferring information between client and server at the business rather than presentation level.
Java lost the applet battle about 5 years ago. JavaScript is now a powerful full fledged language that is FAST!!!
Your definition of "fast" is a comparison with last year's Javascript interpreter/compiler. My definition of "fast" is comparing responsiveness of a whole native app vs a whole HTML/CSS/Javascript app.
Html5 + CSS 3 is an incredibly powerful, flexible
Compared to what? HTML4 + CSS2? Yes, in theory - pity it's not actually implemented fully or stably by any browser yet, just like all recent W3C standards (whence the OP's problem).
Compared to native Windows / Cocoa / Java UI? No.
and extremely easy to use
You need to try Xcode. Or its older (and wiser) sibling, Smalltalk. That is easy to use.
So Ignore what idiot poster posted above
If I had a hammer, I'd hammer in the morning...
I think you've got it backwards. (Score:4, Insightful)
I really, really wish I could agree with you.
But there's a fundamental problem. An intractible problem, even.
Browsers simply try too hard to be all things to all people.
That's an impossible task without making all people conform to your definition of all people. Woops, totalitarian dictators and religious idealogues keep trying that one and finding it doesn't work either.
We should not be continuing to try to build or define the ultimate browser. We should, instead, be defining standards for browsers for specific application fields in specific countries.
Open standards, not standards led by any industry leader or special interest group.
Simple, standard browsers, implemented and implementable by small teams with unencumbered tools. With an overall API a single developer can grasp, and libraries that don't require teams just to find out where to find the answers.
Re:but I thought HTML was supposed to fix all that (Score:3, Insightful)
What are you smoking? The whole point of the web is that it can run on almost every platform out there. Phones, web tvs, Linux boxes, PCs, etc...
Silverlight, as nice as it may be, will never be able to compete on that front. Look at where flash is today.
As you say, if you absolutely must have it run in a browser, write it in HTML/js/css. That's what browsers understand.
Re:but I thought HTML was supposed to fix all that (Score:3, Insightful)
Don't compare the weaknesses of AJAX against the strengths of client side developments without at least mentioning the other way 'round, mmkay?
Client side applications have issues such as:
1) System requirements! You have to have the right type of computer, with the right type of processor and/or O/S, etc. Don't have one? Well you are SCREWED. Porting a client application from one platform to another, even with a decent toolkit can be daunting. Even if the programming language supports cross platform development, does that "cross platform" part include Linux? What about QNX? What about the iPad? Browser-based computing eliminates most of this problem.
2) Environmental differences! Software that works well on computer A might not run at all on computer B despite them being very similar because B installed a shareware program that updated some DLL. Good luck sorting that one out? Web-based applications don't really have these problems outside of the browser discrepancies that exist when you don't write an app with a decent abstraction API (EG: Prototype)
3) Data locality! So you are at work, you save your file, and then you leave. Over the weekend you remember some detail that you want to bang into your document quickly before you forget. Don't have your laptop with you? Well, shucks! Web-based applications don't really have these problems, either. You might have trouble with Internet connectivity, but even in very rural areas this problem is disappearing rapidly.
4) Cheap development! Web developers are easy to come by! The standards are open, the needs are many, and the work is easily commoditizable and thus hiring help isn't so difficult.
Re:but I thought HTML was supposed to fix all that (Score:3, Insightful)
Javascript is mature enough, it is the DOM that needs to evolve and be consistent over the different browsers. And CSS.
Still, I'm not always convinced making everything a web application is an efficient choice...
Re:but I thought HTML was supposed to fix all that (Score:5, Insightful)
If an engineer is asked, "What is the best tractor for me to commute to my office every day in?" one of the first questions should be, "Why do you need a tractor?"
Even if you find out that the man really needs a tractor and isn't just lacking knowledge of alternative automotive technologies, you'll have learnt more about his specific requirements in the process.
Re:My experience: (Score:1, Insightful)
You never target foreign customers, until you do. Then it's too late.
Because changing a web application to support multiple paper sizes after it is in production use would be just crazy... right?
Re:but I thought HTML was supposed to fix all that (Score:3, Insightful)
The root of this story is about a guy trying to solve a specific internal application problem – not a widely distributed and publicly available application. And, he is writing the application in Ruby, which is good for web development.
However, I think that I would have written a native application to the platform that they are using instead of a web application.