Slashdot Mirror
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."
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.
Figure out what you need to do with your application to make it work in IE and Firefox is the only real solution.
-- Slashdot, making the Left look conservative since 1997.
In my experience, the easiest way to get a consistent and stable printing experience is by generating PDF. I have yet to have stability problems if this is done properly. As you're working with Ruby on Rails, using Prawn and Prawnto might be useful. However, if you absolutely positively must NOT use PDF for printing, then this probably won't help you.
Export your data to XML or PDF on the fly and have something sensible print it.
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.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
...is a much more serious bug than any possible printing problem.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
If you forced me to use Opera to use your system I would demand that they find a new developer. Or as a customer I would find a new system.
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.
Why not take advantage of a more advanced and mature UI widget set, such as that provided by Java
Java is 20 years old, Javascript is 15 years old, and Java is mature while Javascript is not? Does that extra 5 years really make that much of a difference? Was Java considered not mature in 2005? There are plenty of mature Javascript UI libraries around that developers can take advantage of (ExtJS/Sencha, jQuery, Mootools, etc). There are several use cases where Java is a pain in the ass and an offline application is not an option. A rich internet application implemented in Javascript is perfectly fine for many situations. There's no shoehorn involved when it's the best tool for the job.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
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.
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.
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.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
You've got it backwards. You don't write a web application and then go around installing 9 different browsers at 20 different patch levels in a search to find one which finally doesn't break while using your app. Rather, you write an application and install 9 different browsers at 20 different patch levels to make sure none of them break while using your app. Fix the app, not the browser. And if the problem is intractable in the most popular versions of the most popular browsers, change your framework.
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)
If I have nothing to hide, don't search me
Apps like MET (link)
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 will be flayed alive, but Silverlight 4 is a "Rich Internet Application" framework and with the most recent version, they built in some very tight and effective printing functionality. That, in combination with the ability to pretty much lay things out exactly as you want, export to an image or text format, export the app to an out of browser desktop app, and print in whatever format you see fit, makes it ideal for the kind of ticketing system you're talking about.
Here's a blog on how to implement it: http://wildermuth.com/2009/11/27/Silverlight_4_s_Printing_Support
And another: http://www.silverlightshow.net/items/A-look-at-the-Printing-API-in-Silverlight-4.aspx
and here's Microsoft's page hyping it: http://www.silverlight.net/getstarted/silverlight-4/
Here's a blog on linking Ruby on Rails with Silverlight as well: http://techblogging.wordpress.com/2008/03/26/using-silverlight-with-rubyonrails/
Hope this helps.
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.
Le français vous intéresse?
NONE of you posting in this thread section can read, obviously. The question is what BROWSER is best for complex web applications. It is NOT what programming/scripting language is best for making such applications.
Heck, as wrong of an answer as it would be, "Internet Explorer would be best!!!" would be a better answer than the ones you all are fighting over. At least it's on the list of possible answers to the question.
Someone needs to mod you all to Off Topic oblivion. There's nothing "Insightful" in you all not even remembering what the question was...
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.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
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.