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
All the way!
...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.
The only way that anyone does proper printing of web documents is as PDFs, and to hell with the browser. This is for very good reason.
If your system absolutely must print from a web page, use Flash. Yes, I know. But it will print from within the page, it produces identical prints in all browsers/platforms, and everyone already has it installed.
How about this then? What fucking printing bug?
"rich internet application"
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.
Palm trees and 8
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 not sure what's "offline" about Java"
Not that I disagree with you, but there are plenty of offline applications written in Java, using Swing. Java is not limited to applets and application servers, there is a mature library for standalone/offline application development. As I remember things, the reason we do not see more desktop applications written in Java is the bad reputation Java had in the 90s for taking a long time to loa, and to some degree the fact that Swing does not integrate with the desktop look and feel (or at least it did not the last time I checked, which was admittedly years ago).
Palm trees and 8
>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!
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.
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.
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.
Sure... because CSS always formats uniformly across different browsers and platforms. And browser detection never fails or degrades over time.
These kinds of issues are what Flash excels at-- uniform output. Why dont'cha push your final, scrubbed and parsed user data to a Flash widget to print? I believe there are all kinds of native PDF and print controls in the Flash API anyway.
To alll you HTML5 kool-aid drinkers, flame away. Tell me how the canvas tag will fix all the OP's woes.
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...
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).
You should not care about bugs in the browser. Use frameworks (sometimes with workarounds) or standard HTML4/HTML5/Javascript1.x code. File bug reports for whatever you find in browsers. The rest is just wasting your time and you might end up in the deadend as it happened with ie6.
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.
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.
Write boring code, not shiny code!
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.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
The big difference is that all the browser has to do for java is host the runtime. For javascript, the browser has to support the entire instruction set. Java takes longer to start. But once it has started, it gives you much more control.
I could say I didn't want to burst your bubble here, but I do. Pop. Consider it burst.
Try to do what most software developers do once. Go into a company that has very complex requirements for their application. Try to do it in any of the more popular web-technologies today, Richfaces, JSF, Struts (you can see where I am coming from I guess) and develop this vertical LOB app. Sorry to tell you, you will spend at least 5-10 times as much time to get it to work than if you use something like Silverlight or Flex and put a SOAP interface on your server. Not only that, but it will easily scale 100 times better than you can possibly manage with an app that keeps all state on the server including conversation state.
In typical LOB apps you can easily cut network traffic and server hits by 50-90% over an Ajax solution by going with Flex or Silverlight. In most cases such things matter. Not for toy applications though.
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...
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? 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. 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.
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.
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.