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!
I welcome a calm, reasoned discussion of the topic's many nuances.
Dewey, what part of this looks like authorities should be involved?
Generate a pdf for the user to download and print instead.
Its the only reliable method.
Also, why are you asking Slashdot what browser to use? Do you expect to have any say in the browser your end users have?!
How complete is the system at this time? Has it been used in production or is it still in development. If so, how many hands have been involved and how old is the original work? You may have bit off more than you can chew unless you can customize your own browser and code to use only it and its descendants.
If your application really needs to print something ill recommend you to create a pdf server side and offer it to the client.
you can transform your current html templates to pdf once they are filled with data with:
dompdf: http://www.digitaljunkies.ca/dompdf/
which uses tcpdf, aslo Free software: http://www.tcpdf.org/
or some commercial reporting tool, but pdf is the way to go.
you can even embed the pdfs inside the html, see http://blogs.adobe.com/pdfdevjunkie/2007/08/using_the_html_embed_tag_to_di.html
...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.
Parent is onto something. The web is fundamentally the wrong approach. Just because you're familiar with hammers doesn't make them the best tool for all possible jobs. Sometimes you would be better served by a saw.
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.
It sounds like the web-app you're using isn't coded well. Hate to put it that way, but if you're having this many problems with it, it's probably true. As for browsers to use - just switch until you find one that works. Try each of the rendering engines and browsers that use them (trident, webkit, gecko, presto, etc). Find one that works, use that.
Next time around though, write the app better. Export to PDF/PS if you need formatting to be absolutely preserved.
What are the "printing problems" you're having?
If the problem is that you're having trouble making things look the way you want to (you mentioning printing bookings, which I suspect might need a very rigid format), you're not going to get away from that. HTML is designed to allow variation by browser implementation and by user preference. It's not supposed to look the same everywhere.
If you need accurate, precise print reproduction everywhere, your best bet is to generate some kind of PDL (Page Description Language) on the fly. PDF is the common choice here, and prolly your best bet, since most people are used to it and already have software. Other choices would be PostScript and XPS, but those are much less commonly available in the user community.
Note that "PDF" doesn't have to mean "Adobe"; there are tons of third-party PDF tools out there, including free and FOSS.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Best PDF Viewer For Printing Complex Documents?
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
/ducks
The wheel is reinvented in computer science every so often.
Palm trees and 8
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.
yea...there's a reason why there's a media type definition for CSS.
Plus using javascript to load browser specific CSS so I don't have to rely on CSS hacks and also keeps things "valid"
Oh, and I dropped support for IE6.
IE7 is going soon too as IE8 becomes mainstream among IE users.
Still, I hate IE with a passion.
My main browsers are FF3.0x+/3.5+, Chrome/Safari, and Opera 9/10....in terms of testing.
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.
As many have suggested look at outputting your data in a format that allows it to be used in another application. I typically allow for CSV or PDF output. There are libraries out there to do that within your app. The path of least resistance is your friend. I have seen developers spend an age trying to replicate the functionality of excel for a web view when a CSV export would've been much more useful, cleaner and far easier to code.
When in doubt have something else handle it!
jaymz
I don't think this is particularly insightful advise. A web interface works well, but regarding printing is a sore point. If they need particular printing enhancements, having a network accessible printer and the printing driven from the server may be better. Having the server issue a .pdf, or .ps set for the client to print would work too. Hell writing an extension for formatted printing would probably be ideal and I'd be surprised if nobody has an ns* extension for such a feature already written (though most will simply use PDF or PostScript directly).
.Net for this type of application myself. There are advantages to the centralized environment that browser based applications bring, namely a much lower cost for deployment.
Beyond this, having a web interface allows you to switch client architectures fairly easily as long as you aren't too tied to one, which is the path many internal development efforts went towards in the later 1990's and early 2000's with IE5 and IE6. Frameworks like ExtJS offer a lot of rich functionality in web based applications. I would even suggest going with XUL over Java or
Michael J. Ryan - tracker1.info
"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
You can use an alternate stylesheet for printing as opposed to mobile or screen. The browsers automatically select the print css and render accordingly when you print. You can use this to strip out things like navigation (which is hard to do on paper ;) ) that aren't relevant in that medium and optimize text styles so they are optimized for a nice printout.
This tends to work best if you've laid out the site using CSS instead of tables.
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
I wouldn't use the browser for printing. I would render the document to an RTF on the server, then hand it over to the client for printing.
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.
that isn't clear from the description: Is this a tool meant to be used internally by the company or is it meant to be used by the general public?
Because if it's the latter, whatever your solution, it better work in every browser and not just specific older version of Opera.
Use a print stylesheet, swap body classes to mask unwanted rules from the main stylesheet, then set key sizes in percentages so that it has some adaptability to different page sizes. I've seen it done correctly as long as you can assume a specific installed font or something with identical glyph bounding box sizes. Seriously. What print bug does Firefox have that's not actually just expected behavior if you know CSS?
Here I was, thinking that reinventing the wheel was a requisite part of developing a web app. Are you really trying to suggest that we leverage an existing and mature codebase for rendering and printing documents or processing data tables?
Now, if only more people thought this way.
Palm trees and 8
The "Best Browswer" is the one your paying customers use. For better or worse.
This issue is a bit more complicated than you think.
"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
Or we can go with the simpler answer, exporting a format that will render and print correctly regardless of which browser (or browser version) or operating system is in use. Why waste time getting a stylesheet to work, when you could just render a PDF instead, especially considering the number of PDF authoring tools and libraries that exist?
Palm trees and 8
Generate PDF tickets on the fly. There are plenty of open source and commercial libraries to help you out.
As for a "major" Firefox printing bug etc: you're doing something wrong. I presume that's since you're new. I have an in house monstrosity that prints invoices (think tables, lots of lines and tight alignments) fine across the spectrum: from IE6 to every contemporary browsers. All using CSS and HTML. So it can be done, and I've yet to run into any printing bugs, major or otherwise. There are hacks to be sure, but nothing I consider to be browser bugs, more like specification bugs.
A successful API design takes a mixture of software design and pedagogy.
If you want to do quick cross-browser testing, try Browser Lab.
Java's dead because people can never stop bringing up Applets.
Be sure to report bugs to their Desktop Team, the devs there are crazy when it comes to releasing builds (seen a few weekend releases). From my experience, they were able to solve my issues within 2-3 builds (a work week, give or take), whereas my Firefox bug reports take months (not to mention my pet peeve - Aptana bugtracker).
They're currently preparing the next big version (10.60), so I believe they would be interested in fixing any important problem.
>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!
Lol yes, because if you ever happen to find a client-side Java application, the first thing that goes through your mind is how "advanced" and "mature" it is.
Reality is that users hate that gray dialog window shit. Make it look like facebook and they won't care if it's slow/buggy/can't print right. The Web Won.
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.
Output to a PDF document and have them print it out.
PDF is an open format. Go for it! Enjoy.
Flash is an OKAY solution, but the printer support is hopeless unless your users have downloaded and installed an AIR application.
You'd best cover IE, Firefox, and Safari at a minimum. I've been using the Google Web Toolkit (http://code.google.com/webtoolkit/) for the past 3 years and have been very happy with it.
"Love is a familiar; Love is a devil: there is no evil angel but Love." --William Shakespeare ('Love's Labors Lost')
Ok, I'm presuming that the problem is native browser printing. The printer section of CSS is the red headed stepchild of the spec with only Opera getting it remotely right. That leaves PDF which has been discussed. Given your description of the situation you might have a third option.
If you're building this for an in house company as it sounds and the server is onsite consider creating a Postscript file and then commanding the OS to print the file normally. This cuts the browser out of the equation entirely and lets you get very specific with the printer since you can use system commands to control it fairly directly (or even cURL to it if the printer runs a webserver - some do). This solution is only viable if you have a specific printer or printers you're using regardless of the location of the computer that is commanding the print job be done.
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.
Forget the comparison of years of age. "Javascript" and "mature" are not words which in any sense could ever be considered compatible. After one hundred years, Javascript will still not be a mature language. It is crap by its nature.
Forget about trying to make HTML into dependably formatted print output. Just use a library like Cairo to render what you want into a PDF and provide that to the users.
I am becoming gerund, destroyer of verbs.
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
In the variety of web-based (or web-frontended) systems I've seen, it is somewhere between common and ubiquitous for any serious printing(ie. where fidelity matters, not where somebody just needs a bunch of text to scribble on or take to a meeting) to be handled by having the server spit out a .PDF, as you suggest.
HTML, by design, Is Not a fixed-layout page description language. This is one of its great virtues. Assuming the designer doesn't muck it up, it should reflow nicely, or at least adequately, onto a variety of monitor shapes and sizes, and browser capabilities. However, that makes it a pretty terrible substitute for PDF in any situation where you want to spit stuff onto standard sized paper in a precise way.
Use third party options for consistency.
For webapps: Flash or SilverLight (I'd include Java, but I've been burned too often with version upgrades causing bugs)
For printing: PDF
By the way: Why don’t we replace the browser with a window containing tabs of virtual machines that un-freeze a tiny local memory image containing common libraries (also for backward compatibility) that can run remote executables, either as a thin client or as a real application.
Then we only have to have the ability to separate tabs our to being their own windows and having the ability to have an icon in your start menu.
And suddenly we have the best of both worlds: Complete encapsulation, simple development for simple projects with XHTML/CSS/JS/..., and the ability to run full applications.
Done right, it should also be faster than JS or a VM running a full OS.
Maybe I should talk to the Firefox team about it. Or the VirtualBox guys?
Any sufficiently advanced intelligence is indistinguishable from stupidity.
I wrote a web-based certificate issuing app. The layout of the certificates was mandated by law. I have found that creating PDF's is the best way to ensure that printed output stays consistent with the report design requirements. Plus you can easily save them locally or email them with the assurance that the recipients will see the same report you designed.
$sig not found
Don't even bother trying to use HTML to make printing work. Generate something else (pdf is good.. consistent, widely supported.. evil) and have the user print that.
had to write to or (in b2c) the website is expected to handle any browser the user might reasonably have, starting with IE6.
It was only relatively recently that some hacker has designed their whole website (can't find it now) in a pretty impressive javascript mock-up of GEOS for the C=64.
:-)
Maybe we'll hit MacOS classic type web-interfaces sometime in the next 5 years
I, for one, am looking forward to the inevitable
Most place I've worked at recently have firefox installed, except for that one pesky intranet webapp that only runs in IE6 (and higher if you're lucky!)
I'm not advocating the tie-in to a specific version of Opera. However, with an army of IT support personnel keeping things real, I don't see it should be a huge deal, given whatever other cruft they routinely install and maintain in an SOE.
(Assuming of course this application is locked down to an internal network)
HTML should render adequately in any browser - or your doing it wrong. In print I thoroughly suggest very literal html/css as in absolute measurements for everything. Or if warranted pass the HTML through princeXML on its way to becoming a PDF, you will have much more consistent results that you can count on.
If your end users are known (Internal Customers) then what I do is use IPP to print direct to known printers using postscript. This is a rare situation though, but the plus is that it works across all platforms/browsers and you can guarantee consistent output.
Look here, son.
I've dealt with myriads of printing problems over the years on every fu****g imaginable browser.
I'm having a hard time believing you're having a hard time because of firefox.
Give examples or be laughed at.
now... if you can correctly diagnose why a PHP script gives "Cannot send session cache limiter - headers already sent" with a one liner <?session_start()?;>, I'll give you some credit.
"If I have been able to see so far, It is because I went out and bought a damn binoculars" - Ze da Esquina
This guy just seems clueless and skilless to produce high quality web applications. ie. he has just bitten too big of a bite for his level of skills.
Most web developers are actually quite unskillfull, he apparently is more than the average joe there, but by no means good.
Printing problems wouldn't exist if he'd just use his brain... For example, there is a method to load CSS just for printing, and only for printing ...
Especially without examples, it's highly likely he is confusing his own ineptitude with system/platform problems.
Pulsed Media Seedboxes
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.
This is just soooo wrong. I don't know if your kidding about the MacOS 20 year ago thing or if your just really ignorant about web development. I suggest u look at - Bespin IDE (http://mozillalabs.com/blog/2009/02/introducing-bespin/) - Apps like MET (http://www.picnet.com.au/met/) - Google Apps - YouTube To the original question asker. There has to be huge reasons to abandon web for native development. And as for Java, sheesh really? Java lost the applet battle about 5 years ago. JavaScript is now a powerful full fledged language that is FAST!!! (Ofcourse not as fast as native languages, but you will not notice this unless you are doing bad things) Html5 + CSS 3 is an incredibly powerful, flexible and extremely easy to use UI platform. Do not underestimate these 2 ladies. So Ignore what idiot poster posted above and use cross browser html with PDF for printing as suggested by many more knowledgeable people in this thread. Guido
Java's dead because people can never stop bringing up Applets.
Say what???
In this developers opinion, don't use a browser for anything beyond printing a simple receipt. If you need to serious layout use something like PDF or if you relay like to abuse your self and want to drop some cash, Crystal Reports.
...which was when I started the trend whereby webmasters would badge their sites with "This site best viewed in MY browser"
Say it right: "Nuc-le-ah Powah".
"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).
The problem is that most Java green horns have never seen anything other than webbie Java applications. Actually, most Java developers (be it junior or uber-senior) have never seen anything other than that (or back-end/workhorse systems not directly connected to web back ends).
So, it is not surprise people have no clue as of Java desktop application. Even now it is still of a bitch to write them, even with designers like Matisse, JBuilder's GUI designer or the Eclipse Rich Client Framework.
I would not be surprised if the percentage of non-thin-client Java development (including but not limited to Swing thick clients) is less than 0.01% - there are literally thousands of Java shops where I live, but I'm only aware of three/four (mine being one) that are not web-client-related.
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.
Uh, newsflash. It's not about JavaScript, but about the medium JavaScript operates: HTML. The only viable version of it for RIA with consistent behavior *might be* HTML5... and newsflash again, that's not a mature technology.
Java is significantly better now that it was years ago. It's not slow anymore, and I can make Java look exactly like any Win XP or Linux native app in just a few lines of code. Granted, I'm not aware of any easy way (if any) to make it look like a Win 7 native app, but it's looking like it will just be a matter of time before that happens. We are writing a Java Desktop application at work, and we are even doing things like allowing the user to select the theme of the app. Java has very much improved over the last several years.
WebKit is Firefox compatible, is the platform on which Safari is built, as soon also will KDE's Konqueror which is prided for its ACID 3 compliance. The downside of that is that most of the web is not so compliant. There are many sites which Konqueror still has problems displaying correctly. However, for a stable, standards compliant rich application platform its a good choice.
Java may end up dying, but the JVM will not, because it is very low level, and deployed almost everywhere. Languages are popping up all over the place.
Is SVG a practical option yet, or is it still not supported by enough browsers? Without a special plug-in, I mean.
Slashdot entertains. Windows pays the mortgage.
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...
Because "mature" or not, Java is a resource pig and inherently unstable. The "Wrote Once, Run Anywhere" model has never worked for Java.
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've read through just about every post, and I see lots of good advice, but it seems like nobody has actually answered the first question - of which browser to use. So, to answer a question with a question - have you even tried Safari? My experience is that it handles printing and standards based web sites better than any other browser I've tried (yes, on Win & Mac), although it has numerous issues with sites that were developed specifically with IE6 in mind (of course maybe that's because it tries to adhere to standards and puts no effort into supporting IE hacks).
I agree with the majority of posts here - printing should be done with PDF, so have your server cough up PDF files when users generate reports. Development - AJAX, HTML5, CSS3. In any case you really do need to test and support 3 or 4 major browsers (but not IE6). You don't want to fall into the trap of developers past - completely dependent on one single browser, like the poor folks who wrote exclusively for IE6, and now all their work is broken (just ask the folks in my company who have spent the past 2 years and hundreds of thousands of dollars fixing the back end systems that don't work anymore). Wow, I just read all the stuff I just wrote, and it sounds like I really have a thing against IE6... uh, yea.
Why not generate PDF for printing purposes?
Unfortunately, in my experience, you can't really control the software used by the client (if you can, you are either on a very locked down intranet, or very lucky indeed).
The web browser you search for just doesn't exist. Not only do all browsers have their own quirks, what's worse is that not all users have your eventually selected favorite.
It sounds like you're a part of a company that's been around for a little bit before you dove into this project. Do they have some information on your client base? If they've been writing web applications before this point, I would hope they would have *some* statistics. If not, Google Analytics can be your best friend - drop that into some existing sites used by the same client base and see what OS/browser/version they're all using. It's not perfect, but what is?
At my current job, we have GA tagged on nearly 80% of the site. We get a pretty good view then of the browser demograpics of our users through GA, and then we can set some nice, number-driven goals. For example, "Our site will look and behave consistently for 95% of our users". Then, to meet that goal, we choose the top browser/version until we get enough coverage.
So really, trying to find a web
If you are a one man show developing for a large company, I'm afraid the choice of browser is not yours to make. While compatability is nice, the common case that will use your application is the company standard browser so you better make sure your code runs really well on that.
Use a library such as ExtJS (or something similar) for the web-based UI combined with server-side PDF generation for printing. A library such as ExtJS will shield you from much of each browser's CSS quirks while providing a consistent user experience and look-and-feel.
Hey KID! Yeah you, get the fuck off my lawn!
To the OP:
Have you considered handling printing with an applet to minimize browser cross-compatibility issues?
Sorry to plug my own (FOSS) software, but you can't simply pick a browser to code to, you can only pick a minimum supported browser version to code to, and you ALWAYS have to support the big names, and the big versions so your customers are happy.
Printing with jZebra might solve your main printing issues, especially if they're set up on the OS as Generic/Text printers. -Tres
Well, like any Gnome app. There's no “native” LAF for KDE yet.
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.
It's easy to huff and puff with righteous indignation at poster's not getting it re web app development. However, I can easily imagine a scenario in which users are told: Install Google Chrome v.X.X. Use it to access this site: http://xxxxx./ Do not use it for anything else. Do not update it. If my users were a captive audience, as might easily be the case, I see no reason to spend big bucks debugging 10 browsers. Just tell them what to do. Make it simple and unambiguous. Problem solved. In other words it all depends on which is the tail and which is the dog.
Social Credit would solve everything...
>> Don't shoehorn
Parent speaks the truth. At a certain level of complexity, write an app that runs on the local OS. Save the web based bits for focused applications.
No offense to the OP, but even considering forcing a change of browsers on your users rather than learning to make the code work indicates he is in the wrong role.
The best browser?
"ANY"
Forcing a captive audience to use browser 'X' may prevent them from upgrading in the future.
If it means anything, I work for a multi-billion dollar company. My (mostly web-based) apps are used enterprise wide.
But only a certain number of people can fit into your cubicle, and they may be stingy.
There will be many that will laugh at my suggestion, but take a look at FileMaker. You can interface with the database via PHP if necessary and also export to XML.
You can script the database to print and email a PDF to customers or wherever it may need to go. I realize that you have a plethora of options besides FileMaker, just an idea
Women and Alcohol are good seperatly, but mix 'em and they turn you into a dumbass
and no, my suggesting using Flash on a /. thread is not intentional flamebait.
I am presuming from your explanation that:
A. You can't just serve up a PDF directly (have to print from page)
B. The fact that you are trying to force users to use any specific browser, let alone Opera, means you are desperate enough to do anything, even use Flash
Truth is, if you want to render accurately from the browser, I don't think anything gives you the accuracy and simplicity of Flash. However, given that you went with ruby/rails means you are probably also the type of person who goes out of their way to make things harder than they need to be, so maybe simplicity isn't what you are looking for. Anyway, I would probably do something like this:
1. Generate an XML feed with all the printing info, etc (optional but this is nice for structuring in Flash and gives you a nice feed to easily render to HTML if needed)
2. Read that into a little Flash app that renders it in the page exactly like you need it to look
3. Let them print it from the page or use AlivePdf (http://code.google.com/p/alivepdf/) to let them print/download a PDF
That said, I am a Flex developer so I obviously have some serious character flaws and my advice should probably just be ignored.
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?
You are basically describing Silverlight. (Or maybe, you are describing what Silverlight will look like in a few years, and what it almost is like today). Shame it's currently a buggy piece of shit.
Le français vous intéresse?
You'd think that, but in practice, it turns out that it's significantly easier to deal with the headaches of different browsers talking to one server than it is to deal with the headaches of supporting different client pcs. Figuring out, fixing, deploying and validating the fix for why Mary Sue in accounting has an app run not quite right is just harder than figuring out why IE6 doesn't render something right. You can just play 'count the support staff' to tell this - a server based app with 1000 clients can get by with one or two support people, while the same thing on 1000 desktops will need a whole team to troubleshoot and address individual problems.
"Plenty of offline applications?" Try almost all of them. People tend to associate Java with web applets, but that's never been more than a tiny percentage of Java applications. There are too many platforms that are better suited.
Do you or do you not have a hammer?
This is the kind of crap the IE excels at. Because you can ignore the browser, write a native APP and call it an ActiveX control. Of course, you'll probably be tied to IE because Microsoft are trying to kill ActiveX and IE version N+1 won't support it. Their current flavour is DotNET (silverlite) but that has built in obsolescence so you'll have another big upgrade in a couple of years. You might try Flash if you want native in a browser.
If you want completely native in a browser and you can choose the browser you're better off using the Citrix client (probably in seamless mode) as your browser analogue. You could also roll your own pseudo browser if you have a mind to, it can be far far simpler than a real web browser because it only has to understand one language not the ten to twenty plus variations that are needed for a real web browser.
Assuming you're fixed on a real web browser, the best one for applications is Google Chrome, that is what it was designed for after all (G-Mail, G-maps, G-Docs, G-ood, G-od). Printing may still be an issue as HTML can't do it, you can't even choose a proper CMYK print colour. A good solution would be some form of PDF download, possibly with an enhanced dialog giving the options 'Save, View or Print' so you can get 'single click'.
Stick with a web application. As someone who worked in shipping, it is much easier to do your work. I'm just confused what this ticketing system is about? Unless you can do an AS/400 app (which is what I prefer).
and you're basing this on what exactly? Java enabled me to write an application that, except for a couple of issues over SWT, did indeed run as expected on multiple OSes, something that I seriously doubt would have happened without Java (based on the funding and manpower this project had). As for being a resource pig and unstable - if it's good enough to run bio-chemical simulations in I think it's good enough for the average user.
Not able to print is no reason to reject a browser. For Web based applications, Firefox, Explorer, Chrome must be supported.
Have a look at Apache FOP or something to get the right print outputs.
I think the point he was trying to make is that Java's biggest selling point is that Sun really worked hard to make working with the network feel the same as working with the file system.
(Not commenting on the relative merits, here. Too many underestimations in every technology I've ever worked with. Java is good for consistency, if you can put up with the overhead of detail.)
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
That is precisely what the problem is.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
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...
If your interface is complex, why are you using HTML/CSS/Javascript/etc?
A better question might be, why is your interface complex?
I do think HTML/CSS/JavaScript can handle complex interfaces, but I also think a complex interface is its own form of code smell. Sometimes you really need it.
Why not take advantage of a more advanced and mature UI widget set, such as that provided by Java
The JVM is a bitch to install, compared to a browser. (I know, it's easy. It's still a ridiculous number of steps compared to the "Get Firefox" links.) More users are likely to have a working browser already than a working JVM, let alone the widget set you want. And with a browser, you can gracefully degrade to whatever denominator makes sense, giving your users the ability to access the application from anywhere that has a decent browser (or not-so-decent, depending what you support).
But both Java and browsers have an advantage over native (compile-once, run-anywhere) -- and the native widgets themselves, whether or not you're in a portable language, are not portable, so you'd want an abstraction layer (Qt, WxWidgets, etc) at some point, if you want a portable app.
The web is about where MacOS was 20 years ago in terms of ability to deliver a rich application UI experience.
Depends what you mean by "rich".
In what other platform can you open multiple screens of an application in tabs, just by middle-clicking on the buttons (or 'links') to them? Or bookmark a chunk of the application (possibly application state, also)? Or script the application's UI, easily, even applying arbitrary customizations which apply to all applications?
And that's just scratching the surface -- I'm not counting what you can do with APIs and "widgets" in the Web sense, or mashups, or feedback and real-time collaboration...
Now, yes, you can add Web-like interfaces to native software -- the browser is, after all, a native app. But as you said, "don't shoehorn." At the end of the day, you may well have reinvented the wheel of the back button, forward button, hyperlink/tab UI, collection of bookmarks, easily zoomable text, etc... And don't get me wrong, that's not necessarily worse than reinventing GUI concepts like context menus (or lack thereof), keyboard bindings, menu bar, etc...
But which of these is it going to hurt the most when it doesn't feel "right" and "native"? That depends -- I can see a Mac user being frustrated by something which doesn't use the system's menu bar. But I can also see a native Web user being frustrated when their Greasemonkey script won't run, or that they have to send a screenshot if they want to show something cool to their friend...
I don't know that it's necessarily a step forward. I think it's a step forward for some things, a step back for others, and not entirely clear for most things.
Don't thank God, thank a doctor!
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.
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
Why don't you offer your own browser to your complex web application to your customers?
I'd like to buy homeland for our 10 million people. http://twitter.com/mahadiga
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!
Java got a bad reputation, sure, but for good reasons. We used to deploy software to schools and it was a java web start app. If you had the right runtime, and you could deal with the mess of downloads and potential instability even in a compatible runtime, you'd get by. We finally decided to rewrite it in PHP and MySQL with Javascript for simple dynamic abilities and the process went pretty well, save for the XMLRPC calls that were dead integrated to the system and the poorly architecture'd database...but...
Even at work now I have to do some work with Java apps - not developing, just using - primarily Eclipse. It's slow, bloated and just not what I'd prefer, but Salesforce offers that or in-browser editing - ewwww.
You're an idiot, the only thing Java and JavaScript have in common is the word 'Java'.
The The HTTP/HTML model is the worst thing that happened to GUI design since.. GUI design exists. It was designed to deliver documents with live links between them.
Anything else is jury-rigged, shoehorned into a concept that doesn't support it at all, and therefore unwise.
It's not a C/S platform! It's a document-delivery platform!
I've done the Java thing, creating largish applets that *had complete client I/F*, the users didn't know what happened to them. They thought they were using a native app. I'm sure of this because the most frequent request I got for years, was to get rid of the "annoying extra border with the browser menus". But we wouldn't. because we'd have had to deploy the clients in a more old-fashioned way and the customer didn't want that.
If you need to ask "What is the best browser for using complex web applications?", you're doing it wrong. Especially in "simple" business automation, any browser should be fine for any web application, the rest is done on the server side.
Now that doesn't help you much, but you haven't given a lot of detail on the printing. I assume the thing you want to print is fairly complex. Browsers traditionally are more suited for on-screen rendering than creating print documents. If you really need fancy client-side printing capabilities, consider generating a PDF on the server side, then send that to the browser. Which one the client uses should no longer matter (much) then. Even Lynx is capable of receiving PDF documents.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
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.
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.
Sheesh, this kind of attitude makes it pretty difficult for us Linux users. IE, Silverlight. C'mon guys, show some team spirit.
I would not be surprised if the percentage of non-thin-client Java development (including but not limited to Swing thick clients) is less than 0.01%
My app is written entirely in Java (MFG/Cust Service/Cash), 1.1 million lines of code. It is true that GUI bulders aren't very good compared to, let's say, Delphi, but Java lends itself well to code templates, which eases the burden, especially for an application where consistant look and feel is required.
I agree, and utterly disagree with you. You have to use the best tool for the job, and for complex applications, the browser simply is not the tool for the job. People advocating using Javascript, should be flogged and dragged backwards into 1972 and shown how a BASIC interpreter beats the living daylights out of the junk that is Javascript, mostly because BASIC of 1972 is honest about what it is and what it is not, whilst Javascript advocates actually think that horrible piece of junk is useful for anything real.
Java applets and Silverlight are the - IMNSHO - real alternatives. Flex is OK, but it is still just Javascript on steroids, and that simply won't do for complex applications.
One could argue that if you need the power of a real programming language you should not try to develop for the browser, but the browser is still a rather wonderful application delivery method.
To the OP, go for Silverlight. There is nothing like it in the market today. Not even close IMNSHO. And that is from someone who is not particularly fond of Microsoft.
t's slow, bloated ...
Gotta disagree with you there. It used to be but not any more. It's no slower than any other app with the same complexity.
If you had the right runtime
If I'm not mistaken, can't you tell JWS to download and install the correct runtime if it is not installed?
Anyone stating that the whole point of something is one particular thing needs to grow up a little. The whole point of the web is nothing at all. The whole point of software development is to use the best tools for the job at hand.
If you, for example, are creating an app that is to be used by a select group of people unknown to you, on unknown networks all over the place, then the web is a great app delivery platform. Say for instance that you need to distribute an app to all of your dealers, none of them actually owned or managed by you. Then Flex, Silverlight etc are excellent alternatives and generic web apps are an insane alternative. You are not trying to reach the population in general, you are trying to reach a select few of them with a very, very specific need, they need to be able to use your particular application. You'd be insane not to distribute it over the web and you'd be equally insane trying to develop it using "standard" web tools, since they are anything but.
The idea that everything you do on the internet has to be available to every possible thing that can interface with said internet is absurd if what you are doing is only meant to reach a small subset of the internet population.
Should have used Adobe Flex, its way ahead of Silverlight and much more stable. It also has much better cross-platform support.
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.
I have written a large leisure centre management system entirely in HTML, CSS and Javascript . This included multi site, touch screen tills, booking sheets, member managment etc. They system was very customizible and could be applied to any* leisure centre. The inital client was a very busy leisure centre with 30 people coming through the door every 10 mins at peak time. The tills section had to be able to pop the money drawer, read from a swipe card reader and print to a receipt printer. I found Firefox excellent for this purpose. It's about:config section allows you to specify a separate default printer for the browser (by name string) and manage a huge number of variables (borders, paper size etc.) You can package the whole lot up using MCD (see https://wiki.mozilla.org/Deployment:Deploying_Firefox#Firefox_Customization_.28CCK_and_Repackaging_Tools.29). All that was required for IT support to set up a new point of sale terminal was to go to a URL, download the customized Firefox, set a shortcut on the desktop and voila, new POS terminal (nearly, but from a printing point of view it was good to go).
Popping the money drawer required printer specific drivers capable of this (the drawer is linked through the receipt printer). And reading the swipe card reader required middleware to pass the COM port data into a hidden field on the page, which would work with any browser, however I found firefox the best for printer customization and repackaging customized printing options.
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...
Handle printing server side if you can, assuming your printers are all networked this shouldn't be difficult - especially if this whole thing is running inside of a closed network... The server can render the content appropriately and feed it to the appropriate network printer...
I've never really tried printing through the browser much, what problems does it have?
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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.
Many posters here are criticizing you for building a web app in the first place. Don't let them get you down. Doing this for the web is a great choice. Access from anywhere, cross-device compatibility put of the box, are just two advantages. And RoR is a great choice too, ignore the haters here who are afraid to think outside their comfort zone.
Printing however is a different thing altogether. Browser support is pretty poor and inconsistent. Most browsers include header and footer, and you have limited control over the layout. So my advice would be to dynamically generate PDFs. I have done so myself and the results have been great. You can control every aspect of the print and a bonus is that the printout can be retained for later reference.
A good library for Rails is prawn.
I am sure you will enjoy this Ruby-based, server-side PDF generator based on the Webkit rendering engine used in Chrome and Safari: http://thinkrelevance.com/blog/2010/06/15/rethinking-pdf-creation-in-ruby.html
If you're going to print, use princexml.com's app. Create HTML documents which are converted to PDF on the fly.
Finder of the any key.
So for your web app it's necessary to deploy with a customised configuration of a particular browser, eliminating one of the few advantages of web app development?
Also, "30 people [making a simple purchase transaction] every 10 minutes" is not busy by computer or UI standards. People were interfacing their 2MHz BBC Bs (or substitute local 8-bit computer as appropriate) to tills and barcode readers in the '80s for this sort of thing.
I'm not knocking your implementation, which might be very much fit for purpose, but I don't think it's an argument for web apps.
The basic selling point with HTML apps is that you don't have to spend 30 seconds downloading and installing a small binary.
A user might not be on a machine where he can install arbitrary binaries downloaded from the Internet. Either the user isn't the owner of the PC, in which case the user lacks administrative privileges and may be subject to Software Restriction Policies, or the machine has mandatory verification of digital signatures.
If I read those requirements, it looks like you absolutely need some kind of desktop functionality on the web. Well, the real answer is... to step away from HTML.
HTML is great for websites - the kind that offer a lot of data for reading purposes: blogs, newssites, ... but HTML was never intented to be used as a bases for web applications - and shouldn't be.
If you're building an application, you need a framework/set of tools/language that was meant for building applications with. That means: no HTML-based stuff. So: no PHP, no ASP .NET, no JSP, ...
So, what are your real options then? In todays' world of Rich Internet Apps, it comes down to either Flash (Flex) or Silverlight. Main advantage? STATE.
So HTML/Javascript is a good way of subverting "don't run your software on my computer without my permission" policy?
Or is there some argument here that a browser environment is safe but any other virtual machine sandbox and the local user permissions system for restricting binaries are horribly insecure?
I've found using the PHP GD Library to generate an image for printing is about the same amount of work as generating a PDF.
The advantage is you don't need a plugin to print a JPEG, or deal with browser printing bugs.
If you are going to use Silverlight, why use the web? Silverlight is not cross-platform. If you need all the things you say, native app is the only way to go. I do not consider a Mac port to make it cross platform. Mono is garbage. No Linux, No iphone, no iPad, no Android, etc... Silverlight is nothing but Microsoft's proprietary, patent encumbered play for the web. Many idiots such as your self are playing right into their super expensive, proprietary grip.
I'd rather someone use Javascript than infect yet another site with Silverlight.
Intended link to UK mobile coverage maps unmangled, sorry.
I'd rather take 5-10 (even 20) times longer than use Silverlight and happily know it will work pretty much every browser and device.
you might want to give serious consideration to creating an application that uses the web engine itself, directly, rather than relies on the broken-ness of the web browser "applications".
two possibilities for you where you can start: http://wiki.python.org/moin/WebBrowserProgramming if you prefer python, or if you truly prefer ruby, try http://github.com/ppibburr/rbwebkitgtk which is ruby bindings to webkit *including* direct access to the 2,000+ functions of the DOM model.
in this way, you can set up an application (ruby-gtk+ app) where you will be able to have your *own* menubar at the top - not the stupid web browser's one; on it, you would have a "Print" option which went and accessed the DOM model's "innerHTML", and you passed it to a *decent* printing system under *your* control, using whatever printing methodology is accessible to you via ruby, running on the user's machine.
or python, if you prefer.
this type of methodology seems to have been entirely forgotten about, as people scramble for conversion of complex apps to "entirely web-based" because they were convinced that "web 2.0 is Good and is God", and then run head-long into exactly the difficulties you're encountering, by which time it's too late.
advice: bypass the web browser as a de-facto application, and create your own application still using the incredible power of web browser *engines*.
My shop runs a webapp that has various printing requirements, for which I've variously taken two competing approaches.
1) HTML with all the CSS in physical units of measurement (cm/mm), or percentages where permissible. Work out page sizes that fall comfortably within the printable margins of whatever printers are used. Make sure content is constrained such that it won't overflow its containers. As an added bonus, I found an extension called jsPrintSetup for Firefox that lets you specify print settings (orientation, margins, zoom etc) in Javascript within the document - very handy if your colleagues like dicking around with these settings in the browser.
2) Generate OpenDocument content when HTML's presentational capabilities aren't up to the job (especially when it comes to multi-page items). There are a few OSS projects kicking around for this, but none suited me so I did a fairly simple hack-job of creating template documents with placeholders for content, then running find-and-replace on the content XML file, zipping the document back together, and serving it up either as-is or via OpenOffice's own PDF converter (look for an app called jodconverter on sf.net).
Hope this is some help.
I'd rather take 10,000 times longer to make sure it works on every computing platform back to the hypothetical machines in Leibniz's 1666 De arte combinatorica. And don't get me started about difference engines! My team are working on porting and testing a cogs-and-gears implementation of Firefox right now - it'll take longer than just implementing the damn writeln('Welcome to the future!') natively but think of all the development time I'll save on future code.
With regard to Google marketing HTML as capable of delivering a rich application UI experience, take a look at their Google Docs application. With the tremendous resources at their disposal, Google still cannot provide functionality present in the simplest of word processes (e.g., WYSIWYG printing). How do you think a small team with limited resources is going to fare when attempting to develop a rich GUI with HTML?
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.
Thanks for the suggestion. I'll look into it if we start a new project, but I have a feeling my boss will want us to stick with what we know, which is Silverlight.
Le français vous intéresse?
It works flawlessly cross-browser (with a few odd, rare exceptions)
Silverlight is cross platform? You forgot Linux. Fancy web developers always "forgot" linux. Haters.
"So what!", you say, "Microsoft will throw a bone to Linux, sooner or later.".
I have to boot my Wii, every time I want to watch movies with Netflix. Boot My !@#$%^ Wii.
You don't know pain!
No need to get angry!
And as a response, I'll leave you with this quote, that I ripped off from the sig of a fellow Slashdotter:
"If I'd asked my customers what they wanted, they'd have said a faster horse." ~ Henry Ford
Le français vous intéresse?
Why don't you stop worrying about browsers issues and design the UI in Flex and use something like AlivePDF to create simple PDF documents that you can print where ever and whenever. Flexible Rails implementations are quite easy to maintain and provide a rich feature set right out of the box. Also, both the Flex SDK and the AlivePDF API are open source.
As much as the Apple Fanbois want to beat the Flash Platform down because Steve says so, it still is the only tool you have for consistent display and functionality across various browsers and platforms.
Only home users should be printing (usually PDF) via the browser. This is usually just some really big barcode where it doesn't matter if the layout changes.
If you are trying to print precise documents then you will need to develop a printout direct to the printers. If you are issuing passenger tickets then I'd recommend an industrial printer like a Zebra. The printing language is not that difficult to learn and those printers will just keep printing for years day-in day-out.
You'll notice I said "cross-browser", not "cross-platform".
I'm not a "fancy web developer" -- just a student with a temporary job doing some web development work. I use Linux every day in my free time. I know the limitations of Silverlight on Linux, but it sounds like the OP is in a locked-down environment where he gets to dictate even the browser version, so saying "hey, you can use whatever browser you want, but you still have to stick with Windows" seems like an improvement on his current situation.
Le français vous intéresse?
The question then becomes : will the customer / client be willing to pay 5 to 10 (let alone 20) times as much so it runs on hardware he doesn't care about ?
If there is one thing to be learned on slashdot, it has to be sarcasm.
Deliver WebKit rendered PDF for print (http://github.com/jdpace/PDFKit) and make the rest run in every modern browser.
Also GWT is another alternative to plugin-dependent and OS-dependent solutions like Flex and Silverlight. It has great development support, even down to WYSIWYG design using Eclipse, and has the benefit of code written in Java compiled into Javascript/DHTML to work across modern browsers.
Also, I'd recommend Chrome for testing. It's very fast and has a nice profiling extension available for it, as well as a GWT-specific development extension.
"He may look like an idiot, and talk like an idiot, but don't let that fool you. He really is an idiot." - Duck Soup
You could probably use NoScript or its equivalent in other browsers to keep web-based application from running on your machine based on domain.
"He may look like an idiot, and talk like an idiot, but don't let that fool you. He really is an idiot." - Duck Soup
Yeah because obviously the current web standards are working pretty well for this guy when no browser can figure out how to implement the same functionality across versions. What web standard should he use? While the W3C dick around negotiating with the community over codecs Microsoft defined and released 4 versions of Silverlight.
WRONG. The WHY question was answered. To run Complex Web Applications. Your analogy would only work if the initial question was very general: "which browser is best for me to use the Internet with?" "What are you trying to do on the web?" "Use/run complex web apps."
I have developed an application with lots of jQuery on the browser and Java (Stripes) on the server. I use JasperReports to generate a PDF on the server and then send that to the browser with a Content-Disposition header to cause it to download. Browsers typically offer to save or open it. Once open in an application (example Acrobat Reader) it is simple to print.
I'll see your senator, and I'll raise you two judges.
did anyone answer this guys question?
if you manage to see this.. check to see if your client has logs (and browser usage stats). cater to the largest segment.. maybe the top 3
unless your client is ok with forcing a browser on their customers.. it's your job to make the site work in the ones that are used the most.
since you said freight and passage, I'm thinking your client is a commercial shipper moving bulk freight.. not tins of cookies for the grandkids.
that said, the browser distribution will probably be narrow (corporate clients) vs. every grandma's browser. unfortunately.. commercial clientele probably means ie6 is going to be in that top 3.
You apparently can't see the forest for the trees. Car analogy: What is the best car for me to use to go pick up a newspaper 15m down the street? None of them. It would be better to walk. The OP is asking which car to use, and everybody else is suggesting that the OP uses the footsmobile.
I am not sure why this was modded funny in such a serious debate over sensible browsers *s*.
If your web page does not work in Lynx, perhaps you should reconsider your basic assumptions, including using the web to deliver the user experience for this application.
Cheers.
Because these days 1) I can and 2) it works.
1) Ever tried to get a user to use Java apps? Ever been a user trying to get different Java apps to work? App1 requires your system's Java be version 2.5, no higher or lower. App2 requires your system's Java be version 2.6, no higher or lower. And don't get me started on load times.
2) Java apps look a lot less advanced and less mature than what's on the Web these days.
3) I do not want to write 200 lines of code in an API I'm not familiar with to only start up the program.
1) My native environment is not the native environment of my entire customer base, and I do not feel like porting apps between Win32, Cocoa, and GTK.
2) I do not want to write 2,000 lines of code in an API I'm not familiar with to only start up the program.
...that you are also versed in using a "Manchester Screwdriver".
As mentioned above - you should be coding your web application, preferably using validated web standards, so that the application works with the broadest set of browsers possible. Not optimising for a single browser - you are lowering the number of potential customers before you start. No, most people won't start installing old versions of some obscure browser to try your application, they'll just use your competitors product that doesn't have such ridiculous limitations.
For printing, use a format that is optimised for printing rather than displaying information in randomly sized browser windows, such as PDF.
Silverlight may just be that.
BUT* that is not what this is all about. There is a reason we're cramming EVERY GOD DAMN THING into a browser. I regular forget what that reason is, however i think its something about akin to javas write-once-run-everywhere, where your fine silverlight is quite the opposite, write once & submit your soul to microsoft. Anything "standard" coming out of MS is a contradiction period. The whole concept of silverligt is stupid beyond beyond.
Generate PDF with something like HTML2PDF, print PDF.
In ruby, there's sublog, easy pdf, prawn, whatever.
rewrite it in PHP? That's retarded. Masses of web developers are flocking away from php, because it's code is unmanagable, inherently insecure and lacks bunch of enterprise features. Sure you can have nice productivity in PHP, but that's effective only for small enthusiasts projects and not full-blown web application.
He's Doing It Wrong. If your application only works when the user is using WhiffleBrowser Version 4.2.1 Patch Level 3, then it's not useful unless the user installs that exact browser. The point of developing web-based applications is that your users don't have to install and maintain *your* software on their desktops, you display your material using a common standard interface, and the user displays it the way they want, whether that's on a desktop just like yours or an iPhone or a 1080p TV screen, and whether they're using the same fonts you've got or using 36 point font because they've got vision problems.
So you need to support the browsers your user base uses, whether that's (arrrgh!) IE6 (which is still the only browser my corporate IT department supports) or Firefox (where you should be able to expect a recent version) or Safari (because almost every company has Mac users even if Corporate IT doesn't support them) or whatever, and it should work on all of those browsers.
If you really need to produce a precise image usable for printing ink marks on dead trees in a particular layout independent of printer resolution, you need to output your image in a language designed for that, which is Postscript; if you don't need to be printer-resolution-independent, you could also do PNG/JPG/etc. HTML isn't designed for that, it's designed for letting the user present the information content any way they want to.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
If the browser has to display your content, you need to hand it content in a format your user's browser can display. Use whatever language you want on the back end (as long as it's supported on the servers you'll be running on), but you need to be aware that the user isn't necessarily sitting at a desktop with a big screen and the browsers you're supporting.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Yes, I know, my corporate IT department should be supporting something much newer than that, but they don't. So if I were being a good boy and not installing Firefox on my machine (so I can get some actual work done), or Safari and Chrome (to play around with) I'd be using it right now. I think it has CSS, but certainly not HTML5.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
No, that's analogous to answering, "Because I live on a farm," to the question, "Why do you need a tractor to drive to the office?" So you've invested in farming equipment already; this doesn't mean you need to use farm equipment for everything.
The submitter is complaining that he can't get printing working as expected, or even uniformly, across browsers. Yet his request includes unexplained constraints which severely limit possible solutions: IOW, he's asked, "best browser?" rather than asking, "best solution?" Moreover, since he's omitted the information which explains why nothing can be changed but the browser we would be foolish to think we have a sufficient picture to recommend a particular browser.
Maybe there's no budget to re-architect your whole system, but perhaps the correct solution is to stop making yourself a slave to the limitations of HTML/Javascript and HTML/Javascript clients? PDF has been suggested, as have various other plugin techs which may interact better with the printing environment.
If you're going to be a slave to religion, at least let it be based on morality rather than tech marketing. Or maybe this sort of devotion is more benign ;-).
Ever tried to get a user to use Java apps?
I could be a smartass and just link you to a page with a Java applet. What's that? not everyone has downloaded a JRE? Well, the majority of the world haven't downloaded a decent browser either - and at least the Sun JRE has official MSI support for enterprise deployment.
If you're looking for app installation via the web, the Sun packaging system is Java Web Start, and has been since 2001. Oh, which automatically installs a JVM if you don't have one...
App1 requires your system's Java be version 2.5, no higher or lower.
...and supports multiple JVMs, for those cases where - like the article submitter with Opera - later versions of the platform don't work. You do realise that "your system's Java" just means a few environment variables to point to the default JVM, yes? You can have every JVM version ever built installed simultaneously on your machine if you want.
2) Java apps look a lot less advanced and less mature than what's on the Web these days.
You don't know what you're talking about, sorry. Java can use native UI widgets via SWT (or AWT, but that's old) or be skinned in a couple of lines with Swing to appear as whatever widget set you enjoy. So, unless you're claiming that the web somehow deploys a richer set of UI widgets than native mainstream clients - are you? - no.
Hardware-accelerated 3D on top of OpenGL or DirectX has also been a feature of Java for a good decade now. Nice to see that's just appearing in experimental nightly builds of web browsers over the last few months!
1) My native environment is not the native environment of my entire customer base,
Why does it matter what your native environment is? Is this the same argument Microsoft used to get people to switch to NT in the '90s? "Oh all your lazy developers/IT staff will already know it. No need for expensive Unix guys etc."
and I do not feel like porting apps between Win32, Cocoa, and GTK.
Well, we wouldn't want to hurt your feelings. Writing a presentation layer which fits in nicely with the user's environment is surely something for liberal-arts types. What was Kay even thinking?
2) I do not want to write 2,000 lines of code in an API I'm not familiar with to only start up the program.
I'm almost wondering whether you've ever written a single GUI program for a modern platform at this point ;-).
While I agree with you that the point is to get the best tool for the job, I think you got it backward.
Say for instance that you need to distribute an app to all of your dealers, none of them actually owned or managed by you
If they are not owned nor managed by me, the worst possible solution is to commit myself to one technology which I have no idea if they're equiped with. The best I can do is to cater for the lowest common denominator: Pure HTML+CSS+JS, retro compatible down to IE6. That way, I have a good confidence in the fact that they will see what I have to show.
As a general rule, if the job is to deliver an app to people I don't manage, then I cannot make any assumptions about the technology they have at hand.
Now on the other hand, if I am sure my users are under windows with an up-to-date system, then I can use Silverlight. If they all have Macs, I can cater to Safari. And when I have multiple choice, then I can find the best tool for the job.
If I have to serve all my partners, all my clients or any other group of people/companies that may change over time, IE6+/Safari is pretty much my only choice.
The idea that everything you do on the internet has to be available to every possible thing that can interface with said internet is absurd
Google pretty much does it. Is Google absurd?
Not every app has to be about bells and whistle. HTML 3.2 and a good network pipe can do many many things.
Write boring code, not shiny code!
Or better, use any browser you like. Don't depend on the client side for anything. Create print views by generating PDF files on the fly, use no javascript (or minimal and verify it works in all browsers that support js), and do everything server side.
Then the browser I would recommend is a John Deer.
Google pretty much does it.
No - only Google search just about works on every device. Gmail, for example, degrades ungracefully and doesn't work on my old Nokia. Their Apps degrade pretty much not at all.
Google know that they'll not be able to deliver their products to all devices, and this is why they very publicly denounced IE6. Indeed, it'd fly in the face of rampant progress for its own sake to worry about compatibility with something too small or too old (MS and various Unixes are stuck with that pesky and necessary job).
Their business goal is to get as many people as possible to hand control over to them: they'll pay precisely as much lip service to universal availability as convinces the guy who might be foolish enough to move from MS Office to Google Apps, but there is neither philosophical nor deployment proof that they're aiming for it.
If your problem is with the way the browser lays out the print, how about using a server side library to translate the reports to pdf, png, svg, or some other predictably printed form? If the prior is not a possibility, then there is always the option of a separate print stylesheet which uses nothing but absolute values, such as mm, in, or pt. Be sure to use the same measurement system for ALL components, and do not rely on margin, border or padding. Also, stick to only known and common fonts likely Times New Roman, Helvitica and Courier New. This will make your print outs fairly consistent between browsers (at least those which support the separate print stylesheet).
Totally disagree. Using Ruby and Rails (or one of the other popular frameworks, depending on the specific task) you will get more done a lot faster than with Flex and its javascript-like syntax.
Aside from my personal experience, there is that (by now years-old) video where a guy builds a complete database-enabled blog using RoR, from the ground up, in 15 minutes. Do that (or something like it) with Silverlight? Flex? No way.
Having said that, and given that I don't know any more about this guy's requirements than anyone else here, I still think Flex might be a viable option.
You really should read what you respond to before making a fool out of your self.
You really need to read what you respond to. Who cares which browser it works with if you are building a vertical LOB app?
Only an utter fool would let religious views like this come between him and the timely delivery of the application the client needs.
But of course, you see, all clients are infected with exactly the same absurd religious views that the poster you responded to. The client couldn't care less what it costs as long as it works well in Lynx.
Google has a lot more time and money than 99.9% of companies in the world. Saying "Google does it -- why can't we" is ludicrous.
Le français vous intéresse?
If you are developing a complicated LOB app you can more often than not define as a requirement which browser the user is to use. These applications, though available over the net, are not meant for general consumption.
99% of the time however you will be faced with the: "It has to work in Internet Explorer 7 and also maybe in Firefox. It has to run on Windows". Again, we are talking about LOB apps here, the bread and butter of the vast majority of software developers out there, and those are not for general consumption by the internet population at large.
If they are not owned nor managed by me, the worst possible solution is to commit myself to one technology which I have no idea if they're equiped with
Actually. No. It is not. If, as is the case for most of these situations, they need to use your app to get access to a service or product you deliver and they depend on, then you can easily determine what they need to run the app. This has always been the case, but before the net the usual method was to ship them a CD (or tape if you are as old as I am) and have them install it. Having a requirement like: "A Windows or Mac computer with 1G of memory and a 1024 by 768 display possibility" is not a problem.
The purpose of the net here is the delivery of the app and the fact that you do not have to become their IT manager just to make it run. I have worked for companies who had 5-10 dedicated engineers who spent all of their time supporting the dealer chain maintaining the supplier provided software. That is not an issue when you can deliver using a browser, and "Windows or Mac bought some time in the last five years" is not a requirement you have to worry about.
then I cannot make any assumptions about the technology they have at hand.
Sure you can, you can even put it in as a requirement. Something like: You wanna sell Ford cars, you need a Windows or Mac computer bought later than 2005 with Windows XP, Mac OSX or better.
Google pretty much does it. Is Google absurd?
Google has to cater to more or less everybody. An LOB app developer doesn't care about anyone except the small group of people who are to run his app. That group of people can be given a set of requirements and then all is well.
The system that these Silverlight or Flex apps are replacing are custom solutions on, for example, Sun or IBM hardware that previously had to be managed by this client. Using Silverlight or Flex he can now keep all his engineers in-house working on real solutions rather than run around his dealer network managing the AS/400 systems he previously had installed with them.
The fact that Silverlight in the long run keeps his network traffic and server load at about 10-20% of what a standard Web app would do is just an added bonus.
Write a lightweight desktop application that uses a browser component / rendering engine of your choice. Encourage your users to use this application when they hit areas that aren't cross-browser compatible.
Most web browsers offer the browser as a component that can be embedded into a traditional desktop application. For example, in C# / .Net, there is a WinForms web browser component that uses IE. (The same program will use Mozilla when run under Mono on Linux.)
No, I will not work for your startup
Aside from my personal experience, there is that (by now years-old) video where a guy builds a complete database-enabled blog using RoR, from the ground up, in 15 minutes. Do that (or something like it) with Silverlight? Flex? No way
No problem. Have done it several times. You can watch the following set of videos where the guy creates a SOAP enabled server app with a relational database, including what amounts to a reservation system, a management system etc, in what amounts to far less than an hour of work.
The videos are somewhat longer than 15 minutes, but they are educational not demonstrations.
I agree that RoR is a great tool and I have done a lot of work with it. I have even done quite a bit of work with Flex on Rails which I would heartily recommend (I didn't do any of what's on the site, just used their excellent book) - apart from the fact that Flex is not 100% appropriate for REST apps (at least not the previous version, I have not tried the latest). Until earlier this year, for complex business apps, Flex and Rails was in fact my tool of choice for such apps. The reason I used Flex was that it gave both an advanced UI (of the type that can not be accomplished with Javascript) and it dramatically reduced network and server load. AJAX-based Javascript apps hit the server way too much.
With the release of Silverlight 4 Microsoft leaped far past Adobe though. C# is a much better environment than is Actionscript.
I still think Flex might be a viable option
If you think Flex might be a viable option, give the videos above a whirl. Make sure you get the MVVM video too and compare the utter simplicity of Silverlight compared to a Flex app with Cairngorm. If you have any experience with delivering LOB apps where integration is paramount (think SOAP) the videos above should perhaps not blow, but seriously rattle your mind.
So HTML/Javascript is a good way of subverting "don't run your software on my computer without my permission" policy?
The effective policy is "You are permitted to run any software as long as it's HTML/JavaScript." This is the policy in a lot of Internet cafes, and it was the policy on iPhone OS 1.x.
Yeah, when you start doing a Jobs and making software execution policies purely based on language / API rather than some administrative principle, you're either a petty bureaucrat or have some ulterior motive. The correct place to do business is elsewhere, and developers should avoid tying themselves to your rules.
For example, Google ostensibly blamed IE6 for its data leak and its moving away from Windows is nothing but PR. But what it should be (and is, I'm sure!) doing is looking at its gateway boxes to find out why the leak wasn't picked up before it left Google's network. A client PC is always going to get compromised if someone tries hard enough, but the same does not apply to transparent traffic sniffers at the border.
My "web page" "works" just fine in Lynx, there's a helpful message telling the user about the technologies needed to use the application hosted there.
Surely you're not under the assumption that there exist people out there who use no browser other than Lynx?
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
Exactly. If you start developing for and/or specifying a browser, let alone ridiculous point versions, you're doing it wrong. Just look at what has happened with organisations needing to keep IE6 running so they can continue to access their intranet. No. Just don't do it.
If you absolutely have to control how it looks when you're printing, get your server-side application to spit out an image or a PDF.
But something about this sounds like you're doing it wrong on a more fundamental level. It sounds like this is for a closed corporate network? If that is the case, and you're trying to build something that looks like a desktop application, that feels like a desktop application, and which prints like a desktop application, maybe you should actually be building a desktop application?
Indeed there are such people who will only resort to an outdated version of Firefox when lynx fails. I used to think that this was misguided or Luddite. Though I have come to appreciate the simplicity of user interfaces, especially those that work with lynx. The basis for my appreciation stems from technical uses of the web, typically involved in some sort of literature search, which were faster and easier to do using the lynx/telnet interfaces.
Someone above has been posting about focusing on the best user experience as opposed to just using web interfaces for everything. I am not a web developer but this intuitively makes sense to me as a web user and hardware developer. If we use the right tool for the job, it shows in the end via ease of use and quantity of use. Cheers
You're entire story reeks of amateurish unprofessional childish behaviour.
Ruby On Rails? Seriously? Who the fuck uses RoR for anything at all, at any level, ever?
In fact, I strongly suspect RoR was created by an epic troll just so he can lol @ slashdot posters who claim to be building serious projects in RoR.
Next, it seems like you are relying on html for printing? Can you spell FAIL? This is often the mistake of someone who comes from a non computing background or completely misses the point of html. html is a pile of shit designed to make your computer display look pretty. It has zero (YEs, really, ZERO, none, nothing zip, zilch) use when dealing with paper formats. Anyone who tries is showing how fucking incompetant they are.
In fact, why the fuck are you even implementing this in a web application? Is it that you are full of shit, and you aren't a programmer nor an analyst, and can't design a computer program, but you can fudge your way through a web application?
To me, you are like this group of "people" i used to know around a decade ago. Linux "experts". sold crappy bug infested unscalable php apps to businesses under the guise of the web/intranets etc. Migrated to RoR.
Complete amateurs the lot of you.
In future, ignore what language slashdot tells you to use.
In a previous job we developed an online ticketing system and discovered the same issues.
We solved the problem by breaking it into two scenarios:
1. "Official printed ticket" - Tickets printed by the Promoter were done on the local system and directly spooled to an appropriate printer, which is in a well controlled environment. "Official tickets" were then all consistent and could be easily identified.
2. online tickets, where we couldn't even control the browser, let alone printer settings, paper etc we did via PDF. We also supplied a simple HTML alternate with a barcode in a graphic image for those who couldn't/wouldn't use PDF. It wasn't pretty but was able to get through just about any browser printer combination out there.
Applets are fast? Once they're running, they're adequate, but waiting for Java to actually start up on any machine I've tried it on is one big 30 second turn-off. JS has its limitations too, but startup time is not typically one of them.
There was a time when software development was more than just 'coding' and somehow independent from the programming language eventually used. Following that idea it was possible to develop and design software that actually was portable (*gasp*!) and to a significant degree independent from the platform/OS/framework it was programmed on (*gasp*!).
The idea was to first design the software following conceptual patterns (e.g. object oriented, service oriented, functional, procedural, separation of data dn presentation) and then write the code. Imho this still is a brilliant idea if the software is to survive longer then three years or you are liable to bugfixes/uptime... And it also would allow you to skip the incompatible browsers and switch to a 'offline' concept w/o huge cost.
Just because you're familiar with hammers doesn't make them the best tool for all possible jobs. Sometimes you would be better served by a saw.
The poster said he's fairly new to web applications development, so I wouldn't even say he's familiar with hammers.
Printing on the web is not really that bad, unless you need pixel perfect accuracy.
To the poster, if you need that kind of control and "CSS accuracy" then you're SOL as all browsers have their own CSS/printing quirks and you'll be in a world of hurt going down this path.
I think your best bet is to do this on the server side and serve something more appropriate like say a PDF. There are libraries out there that generate PDFs from HTML/CSS (dompdf in PHP for example).
They have their own shortcomings (e.g. dompdf doesn't respect vertical-align on table cells and even crashes when you have a table element that spans more than one page), but at least you'll know that the output will be consistent across all browsers/platforms and will be printed as such.
You could of course go gung-ho with postscript and create PDFs without the HTML/CSS translation mess. Your data and application logic are separate from presentation, aren't they?
If you can't mod them join them.
IE6 FTW or your fired. Seriously. Thanks, Your CIO
I'm basing it on the last 5 years of very painful experience with unstable "Java" graphical applications. I suspect, and observed in two cases, that the developers were excited and believed that it worked. In most of these cases, the actual clients became increasingly unhappy, and I'm working with two major projects right now to throw out the Java client and make it a clean, web-based interface.
And before you applaud its use for bio-chemical simulations, I strongly urge you to speak to some of the programmers who actually understand programming, not merely biologists who took a course in programming, to find out what sort of absurdities are occurring. There's a tremendous amount of biological number crunching for with software that cost incredible hardware and computing time resources to run, but are so buggy that they should never have been released. There are numerous reasons for this, but the essentially mistaken or sometimes even fraudulent claim that Java run on two different machines or on two different days with normal Java updates will produce the same data is at the root of much of it.
Java's multiple layers of inheritance and localized re-interpretation of basic functions creates a stunning stability problem for reliable number crunching, one which I just don't see as addressable.
If you write any web application and any of the above 4 fail you fail. There is absolutely NO excuse for any application to fail due to a browser. 99% of the problems are CSS related and you doing something that isn't supported in slightly older browsers.
If you want to do the latest and greatest techniques for a system many people will use either do it in flash, or make sure your techniques work in all browsers. What you are doing should has no reason to be complex. Remember your audience, remember your users... I hate base text stuff... but flash and "neat" looking techniques are not needed in any ticketing system.
KISS - Keep it simple stupid.
Like others have pointed out: You're screwing around. If you have to develop an internal rich client, chose one (1) cross-plattform browser to develop against and go for it. Whenever the app breaks, fix it, so that it smoothly runs in said browser. And I really would recomment Firefox, as Opera is closed source. If you want pixel-perfect printing you're outa luck. This is the web, n00b, and 1on1 dynamic clientside printing can only be done relyably with Flash. Which even I, as a very experienced full time Flash developer, wouldn't recommend! It's overkill for what you're doing, and actually quite restricted in its results (precompiling of templates required, for instance).
Use OpenOffice and the CLI connector on the serverside. Build some Templates in RTF, using OpenOffice, load the generated outputs in OO and export PDFs from that. Send those to the client. That sounds like a bizar hack, but it actually is the smoothest way to takle this problem and your customers will be happy to be able to edit, change and add printing templates later on. And you can actually test your print layouts and generators manually, as it is, well, OpenOffice. Duh.
Otherwise quit screwing around and stop chasing waterfalls. One browser, one Ajax Framework and Printing via Serverside PDF Generation. For Ajax check out Tibco GI if this is a non-trivial Business Web Application. GI is basically Swing Components in Ajax on Crack, and thus only runs on current versions of I.E. (juck!) and Firefox. Very restricted in that way, but very powerfull and extremly fast to develop business frontends in. The IDE & drag'n'drop Builder are actually written in Ajax themselves - you launch the IDE by loading a html page from your local GI Builder directory into Firefox (No joke!). And since you're going for a single browser anyway, you might aswell reap the benefits. No more fiddling about with jQuery or other x-browser Frameworks. Not the worst Idea for building complex Inhouse Apps, imho.
Good luck. Sounds like you've bitten of quite a lot. Hope you can chew and swallow. ... And that your customers are paying a fair price.
My 2 cents from a professional Rich Client developer.
We suffer more in our imagination than in reality. - Seneca
tl;dr, but: No browser today does printing really well. If you want to accurately get out of a web browser what you see in the web browser, your best bet is to effectively generate documents that are native to paper, like PDF. Tell your devs to look at PDFKit. It uses WebKit to generate PDFs on the backend. Built in Ruby and includes Rails integration and a Rack Middleware. Works as advertised.
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.
just keep in mind that this argument sounds a lot more convincing in the back seat of your car than it does when employed by your public defender
how many pairs of boxer shorts should you own?
l admit I'm having a hard time fully understanding the question, but if this is an internal app for a single (small sounding) company, presumably on a web server on the LAN, could you just print from the server directly to a printer and not have to screw around with any of this web stuff?
So far as what browser, pick either Firefox or IE (or Safari if it's an Apple shop, which seems unlikely) and make it work there.
If this is a big company, pick IE, because they're not gonna let you install Firefox on all their workstations.
The preferred solution is to not have a problem.
If the app runs inside a controlled environment, use Firefox, the only true cross-platform browser (Chrome is there too these days).
for totally controlled printed output go LaTeX, buy the books, read the tutorials, invest the time. It is worth it.
I didn't use the rTeX plugin due lack of certain features, (double parsing for pagination, etc). I just went wit flat Erb templates evaluated on the fly, yes, using RoR too, and I am very happy with the results (it's used for a medical application that produces thousands of complex documents per month).
I got to pick a browser too, the only one that run everywhere was Firefox at that time, thus saving resources in thinking only about compliance with standards.
All browsers have inconsistencies, and all of them have good points and bad points, there is no Best browser, as least from a developers perspective. As a few users have mentioned pdf's, etc. are consistent, but using DOCTYPE and having a simple variant of the page for printing is also a viable option, and test, test, test!
Expect to become an expert on browser inconsistency and a CSS guru; the situation hasn't changed in the past 15 years, it's not going to change soon.
About 80% of web interface design work is finding workarounds, it's the nature of the beast.
GWT has no free WYSIWYG editor and Chrome development plugin is available only in Windows, but a plugin for Firefox is available too.
For the rest I agree, GWT circumvents very well some bugs/restrictions of specific browsers. It's funny to see what kind of hacks it does for IE6, but it works!
Please do not force your user into using whatever browser you can get your application to run correctly in. Your application should work in whatever browser(s) your target uses. If it's IE6 (I'm really sorry if it is) then it needs to work in IE6. Here's a list of browser statistics from the W3C. http://www.w3schools.com/browsers/browsers_stats.asp Typically I would recommend all IE versions as well as Firefox (Windows & Mac) and Safari. Good luck.
I disagree. If money is no concern, Fendt offers a more advanced tractor in the same price range as a Deere. If you are budget consious a CIH/New Holland or Massey will get you more tractor for your buck.
There is nothing wrong with Javascript per se. Look at the work the Cappuccino guys are doing, for example. The problem is the browser: Why do we think deploying applications on HTML/CSS is a good idea?
Really? There is nothing wrong with Javascript per se? So all the language advancements that we have had in computer languages since 1976 are irrelevant? Get real. Javascript is a horrifying joke of a software development nightmare.
Why do we think deploying applications on HTML/CSS is a good idea?
We don't.
Well, what, exactly, is wrong with Javascript as a language? Like every other language, I do not believe it is the right tool for all jobs, but it is fine for some jobs.
I'd just like to point out that if you have to restrict your web app to one browser for it to work properly, you might be using a web app where a non-web app would be more appropriate.
The whole point of the web is to be platform independent. If you end up requiring a particular browser to use the app, then why clunk around with web technologies in the first place?
I half suspect this reaction is what is underlying some of the comments.
Mod points: Guaranteed to remove your sense of humor.
Side effects may include gullibility and temporary retardation
Actually there were 2 questions.
The first (general) question was about browsers. The folks with some experience seem to be answering that the first question is the wrong question to ask (ie. the question assumes the solution is to write something specific to one browser and force your users to use it, but that is not the best solution).
The more important (ie. the is the actual specific problem) question was about printing functionality and how to make that work well in all browsers. This is the question the experienced folks are answering. No need to bust their chops for providing a better solution...
Javascript is certainly the right tool for some jobs. Any scripting language is the right language for small automation tasks. Anything that requires a few lines of code.
Once you are to develop any serious application, typically those run into thousands, tens of thousands or more lines of code, a toy scripting language will not do. There are for example no OO features in Javascript (really, none) which makes it an absurd choice for anything serious. In the same way that you would not use C today for an LOB app, you would not use Javascript. Basic from 1985 is better than Javascript.
If Henry Ford asked his customers what they wanted, "a faster horse" would have been a relevant answer, as it is at least what they wanted. The OP asked a very specific question, with more than enough detail for any reasonably intelligent person with experience to answer it, and instead he gets a torrent of irrelevant bullshit. If we're making comparisons, it's like if a customer asked Henry Ford what fuel he should put in his employer's Model-T, to be told that he should instead buy a new Model-A. Anyway, Ford refused to update the Model-T for years. Before finally relenting, and ceasing production, Henry Ford ignored what his customers actually wanted and decided that the model T was all any person should ever want or need, and that's what allowed other car manufacturers to come along and eat his lunch. They actually listened to their customers and realised they wanted improvements on "bare minimum" and that influenced their manufacturing processes.
Anyway, rather than contribute any more to the noise, I'll be off, but since you're such a fan of quotation I'll leave you with this:
Better to keep your mouth closed and be thought a fool than to open it and remove all doubt.
Javascript most certainly is an OO language.
Granted, it is not a Class-based OO language, it is a Prototype-based OO language. A different approach to OO, sure, but that does not exclude it from being an OO language.
Basically all aspects of the above "OO" can be replicated, almost line for line, in C. That doesn't mean C is an OO language, it means you can develop OO code with C. You do the above with a struct and a function pointer. The fact that you can create a "class" or a prototype in a language doesn't make the language as such OO.
Things like inheritance and polymorphism can essentially be done in Javascript, but there are several differnt ways of implementing them. Douglas Crockford advocates one way, Kevin Lindsey a different. This is because the language as such is not OO. That I can do OO in assembly - again, I have done it with the appropriate libraries - doesn't mean that it is supported in the language.
Hell, the easiest way to create OO Javascript is to use GWT and write in Java. This is by the way the only way a sane developer would do Javascript.
If a developer is going to put together a complex LOB app, one that maintains state, does wizard-like stuff and so on, and said developer suggests Javascript as the language, he should be fired on the spot. It will take far more effort to do it in JS than in the alternatives, and as it is an LOB app, there is no need to consider which browsers "everybody" is running. A Javascript app will also be a nightmare to maintain compared to something running in a plug in. Even Google can not make apps look the same in IE and Firefox except in the most simple of cases. Anything semi-advanced with GWT and it will look different in IE and FF. No such worries with a plugin.
You're right, I only showed the simplest case. If you would like to learn more about why prototype languages are OO languages: http://en.wikipedia.org/wiki/Prototype-based_programming
Also, if you really want class-based OO in Javascript, there is always Objective-J, which is fully supported by browsers.
He is having problems printing. In this case Java may be the best solution to the problem. Given a choice I really do prefure java to java script but that is just me.
In this case he was asking for the best browser to solve his problems.
I would suggest using Chrome since this seems like an Intranet app and not an Internet app.
To solve the printing issue I would suggest going with a PDF output. That will bypass all the issues with browser printing and will give the developer a good print out. Hey PDF really is a good solution for printing.
But yes there seems to me a lot of ways to skin this cat. You could write a Java app or applet. You could do a classic client server solution in any number of languages, you can do a browser based solution.
Since the author posted that he is writing in Rails he is probably committed to a web based solution. A popular but I feel over hyped solution. However if that is where his skills lie might I suggest that he look at http://www.rubyinside.com/prawn-ruby-pdf-library-987.html and http://ruby-pdf.rubyforge.org/pdf-writer/demos/index.html
Since this is a ticketing system for a shipping he may want to think about things like interfacing with RFID and barcode readers. Not to mention generating barcodes.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Well I can't speak for your 5 year's worth of painful experience - all I can say is this hasn't been mirrored in my use of the language.
As for the insinuation that I'm biologist speaking our of my depth. I will have you know that the code I am referring has been tested against many other simulation packages in the same area, with no discrepancies (beyond the typical bug) discovered. I won't even bother to inform you of my background as there is clearly no point.
It's obvious you don't like Java and your clients are welcome to listen to your advice. I for one believe some of that is probably down to the skill of the supposed developer. Stick to what you feel comfortable with - html.
Macromedia tools are free?
Also, I haven't had any trouble running the chrome plugin on my Linux machine ...
"He may look like an idiot, and talk like an idiot, but don't let that fool you. He really is an idiot." - Duck Soup