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."
Re:My experience: (Score:3, Interesting)
PDF (Score:1, Interesting)
If you're trying to print from the browser, you're doing it wrong:
http://thinkrelevance.com/blog/2010/06/15/rethinking-pdf-creation-in-ruby.html
Re:but I thought HTML was supposed to fix all that (Score:5, Interesting)
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:but I thought HTML was supposed to fix all that (Score:3, Interesting)
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."
You're right. I'm forgetting the beauty, simplicity and consistency of the 1984 Mac. I've been using the comparative UI mess that is OS X for too long.
There used to be some very nice client/server GUI form and reporting tools back in the 90s
The whole display / presentation / business client / business server / database multi-tier thing seems to have been broken horribly, so now presentation, business client and business server are merged on some cloud and delivered to a dumb graphical display. Why? Well, to take away control, of course.
Re:Punch in the eyeball (Score:5, Interesting)
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 (Score:5, Interesting)
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:For printing use PDF via LaTeX (Score:1, Interesting)
The amount of work to make LaTeX not look like an academic article is boggling. Hell, the amount of work just to figure out how the fuck you escape basic punctuation so your file compiles is boggling.
Just use a normal PDF library.
Re:but I thought HTML was supposed to fix all that (Score:3, Interesting)
after close to about 12 years of developing for the web - from perl CGI scripts to PHP, Java JSP - JSF, python, RoR and various other related things I've finally given up on browser based apps. I do use HTTP/JSON for an interface between the server side and the client side. That allows the server side to be used from AJAX frontend or from a Java desktop app or what have you. But a strict browser based software - never again.
For a 'rich' client app I would use either: Qt (python/ruby/c++ in order of preference), Java or even VisualWhatever (if I were tied to windows - I try to keep it cross platform).
Re:but I thought HTML was supposed to fix all that (Score:5, Interesting)
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.
Re:but I thought HTML was supposed to fix all that (Score:1, Interesting)
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.
Silverlight is another proprietary piece of junk...it is not a web standard
Re:but I thought HTML was supposed to fix all that (Score:1, Interesting)
It is dated technology. In much the same way as Flash. HMTL5/CSS/JS can pretty much do the job now without having to be locked into an MS/Adobe technology.
Re:but I thought HTML was supposed to fix all that (Score:3, Interesting)
System requirements! Browser-based computing eliminates most of this problem.
When degraded interface, latency of processing and (depending on who's deploying the servers) privacy aren't important... still often no. See the fine article for a counterexample.
Even if the programming language supports cross platform development, does that "cross platform" part include Linux? What about QNX? What about the iPad?
Linux - usually.
QNX - with this RTOS built for embedded apps you clutch at straws. But there's a desktop environment and QNX 6.4 included an albeit non-current Firefox 3, you'll say, then 6.4.1 decided to include a Webkit port last year, you'll point out. Well, yes - tell me, have you tested a modern web app on QNX? Now what about a Java app, or an OpenGL app?
iPad - Steve's a clever bastard, and has intentionally crippled this platform so you have the choice of either providing a degraded HTML/Javascript experience or developing for Apple's proprietary Cocoa framework. In this specific case, there's little developers can do except stop jumping on the shiny bandwagons Apple are driving toward the firing range.
Amiga - I'm including this one because I think you forgot it. A recently released Timberwolf alpha (Firefox port) for AmigaOS surely has to be an argument for web apps.
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.
Oh Christ, the horror of checking a DLL/so version and/or providing my own in the app directory! You're thinking of problems with DLL sharing and system DLL overwriting which were largely eliminated by Windows 2000. FUD is bad, ok?
the browser discrepancies that exist when you don't write an app with a decent abstraction API (EG: Prototype)
This? [prototypejs.org] It's a combined utility and occasional kludge layer, like padding for a kick in the balls. Compiling 160k of fixup source to visit a web page - that's what I want my CPU to waste time doing!
Data locality! So you are at work, you save your file, and then you leave.
Yeah, you'll have that file stored on a company network server somewhere which you can access securely from a remote location. You'll also have a locally cached copy. This will all be set up in a few minutes as part of the equipment deployment process in any competent IT department.
You might have trouble with Internet connectivity, but even in very rural areas this problem is disappearing rapidly.
Argh. Most of the world is a very rural area, and it's not disappearing rapidly because there is no profit in providing cheap connectivity to very rural areas. It's not as if you have to go to a third world country - just the most densely populated country in Europe [slashdot.org]. I'm not buying a satellite phone for your stupid web app, thanks.
Meanwhile, in the cities, (1) an business ISP can and will go down for a few hours (and routing be dodgy, and app servers have problems), and it'd be commercial suicide if your workforce suddenly couldn't do anything but twiddle its thumbs; (2) in general, disaster planning means you don't rely on global infrastructure and political stability except when you need to.
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.
Ah, the "why choose Windows" argument. This isn't 1995. There are plenty of programmers available and proficient with common APIs beyond HTML/Javascript.
Re:You've got it backwards. (Score:2, Interesting)