Best Browser For Using Complex Web Applications?

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."

Comments

Re:but I thought HTML was supposed to fix all that

[FuckingNickName]

Maturity isn't defined by the number of years since conception, but by its origins and the development and engineering which has gone into it since. HTML/Javascript has only comparatively recently been considered as a serious app development platform to contend with native apps, still building on the hypertext + scripting language paradigm. Even Google knows what a pain it is to work with HTML/Javascript directly and has developed a translator from Java to implement their web apps.

What's more, there are very few use cases where an offline application (I assume by that you mean "not HTML/Javascript" - I'm not sure what's "offline" about Java) isn't an option. The basic selling point with HTML apps is that you don't have to spend 30 seconds downloading and installing a small binary. When you're writing for a corporation, that's reduced to insignificance because it'd be installed as part of the deployment procedure.

Re:Punch in the eyeball

[Qzukk]

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.

I bent and bent, then cried and gave up and I had to tell my users to use IE. There's a table printing bug from 2005 that is still open, though fortunately my specific flavor of printing problems (entire rows of data going missing at page breaks) eventually went away several versions after firefox 2.

Nowadays I use PDF, though several PDF generation libraries I've tried had serious deficiencies like being unable to tell me how much space a block of text will take before it places it on the page, or being unable to override Acrobat Reader's default printing settings, which fuck up anything you're trying to print onto an existing form. (I hacked it into fpdf once, but it was essentially a copy-and-paste of a command from another pdf that was able to force me to print with auto-fuckup-and-center turned off. It worked for me and my version of reader, but I didn't dare put it into production since I had to change the spec version fpdf inserts into the header (1.3) to one that supported overriding the printer options).

If your reports don't need anything too fancy and they already pop out in HTML, you can use html2ps | ps2pdf to get something kinda resembling the original webpage. You can't make it look pretty and I'm fairly certain it's text only, but it'll print out exactly as it appears no matter what browser you are using.

For printing use PDF via LaTeX

[corsec67]

I also develop for Ruby on Rails, and we have to support IE 6-8. (Of course the developers all use Firefox for Firebug)
For printing, I switched to using LaTeX, and returning the PDFs.

HTML just doesn't give you the kind of control that you need on a piece of paper.(Try having custom page headers/footers, for example) I ran into the bug in firefox where it would skip rows of a table going over a page boundry, and then there was other issues with it dropping images on other pages.

Plus, LaTeX just looks better. HTML is great if you don't know what it is going to be displayed on, but when you do know what kind of paper it is going to be displayed on, HTML isn't the best choice.

(Specifically, I used the rTeX plugin, with pdflatex)

Re:but I thought HTML was supposed to fix all that

[koreaman]

I would say about 75% of my time at work is spent working around inconsistencies and bugs in Silverlight. To be fair, I've only tried 3, not 4, but they really should have called it "Silverlight Beta 3", not "Silverlight 3". It works flawlessly cross-browser (with a few odd, rare exceptions), and it seems like a big leap forward from HTML/JS for this sort of thing, but I have to say it's not quite ready to compete with desktop solutions.

However, if you absolutely must have it run in a browser and don't want to use hokey Java applets, Silverlight is something you should really look into.