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.
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.
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.
When information is power, privacy is freedom.
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.
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.
"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
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.
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.
AccountKiller
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?".
Greylisting is to SMTP as NAT is to IPv4
>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.
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.
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 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.
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...
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.
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?
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.