Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Is there really any reason to program for NS anymore?

Status
Not open for further replies.

mopacfan

Programmer
Oct 30, 2000
190
0
0
US
Just in looking through my web logs, the number of netscape users is so miniscule, that it seems like a waste of time to spend resources developing code, whether it be html or javascript, for anything but IE. Now before you start flaming and labeling me a ms lover[neutral], I am not beholden to ms products. It's just the way the world works, everything runs on ms. So the question is valid; why should a programmer develop code specifically for other browsers when IE makes up over 98.7% of all of our web traffic?

I'm really interested to hear the good and bad on both sides.

Mopacfan
 
mopacfan: It's just the way the world works, everything runs on ms.

I this statement is incorrect. Microsoft has a large piece of individual users, but "everything" would include a lot more than that, such as backbone, server, etc.

So the question is valid; why should a programmer develop code specifically for other browsers when IE makes up over 98.7% of all of our web traffic?

Your traffic as determined from your logs, perhaps. My logs indicate approximately 40% (it's been a couple weeks since I checked) of my visitors are non-IE users.

Question: Why alienate people unnecessarily just because you cannot be bothered to code against well-documented usually-fairly-simple public specs. (and I don't mean you personally, but you as in Generic Web Wanker)?

Question: Is the large percentage of IE users to your site due to some other factor than what you think? For example, if Netscape cannot access anything past your front page, or if your front page has a huge "This page best viewed with Internet Explorer" sticker on it, or if your page appears totally black in Netscape, then browser-data is automatically suspect. Such things become self-fulfilling prophecies: You decide that there aren't many Netscape users out there based on the fact that so few Netscape users visit your Netscape-disabled website, so you stop bothering supporting Netscape, making your site even less friendly to Netscape users and so on. See?

Question: Do you care about your site being located in search engines?

Question: Do you believe it is possible to write a site that can be viewed/used by any browser?

Reference:
Reference: dlib.computer.org/conferen/hicss/0981/pdf/09815026.pdf

Reference:
The trouble with statistics is that they can mean whatever you like and be Ashcrofted until they serve any purpose whatsoever. Making decisions on small datasets can also lead to trouble and most folks consider an n of 1 to be pretty small. [smile]

There's some grist for the mill.

Cheers,


[monkey] Edward [monkey]

"Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!" -- inventor of the cat door
 
i think it's good to develop for netscape still. my reasons...

- i think its a better browser. webpages appear clearer.
- apple is getting better and better. everyone knows that they're the graphic gurus, and the digital industry is making a huge push towards the multimedia. netscape and mac are elite.
- why cut people out just cuz of laziness?
- the feeling you get when you actually get a cross compatible code to work.

and thats my two cents,
.me.
 
Did you know that Netscape is owned by AOL? I get the idea that sooner or later, AOL customers are going to be seeing more of a traditional browser and less of the proprietary one they are using now. AOL reperesents about 28% of the total internet market - a figure that I'm not willing to exclude from any site I work on.

There's always a better way. The fun is trying to find it!
 
tviman,

I gave that consideration until they dumped ns for IE for the next seven years. Seems to me that even aol has no use for ns. That's just my opinion and I'm trying to find a compelling reason to code specfically for ns. Don't get me wrong, all my code is viewable in ns such as including all closing table tags, etc. It's the javascript where I'm really wonding is it necessary to determine the browsers and write separate js versions to do the same thing?
 
mopacfan: It's the javascript where I'm really wonding is it necessary to determine the browsers and write separate js versions to do the same thing?

Oh.

Well, don't code specifically for any browser. Code for the web!

It is rarely, if ever, necessary to write browser-sniffing code. Most of the time, what you want to do in JavaScript can be done in such a way that browser-sniffing is unnecessary. It requires learning more and better than to just program for IE, but if you're going to just program for IE, you might as well whip out your VB and just write a program and have people download it.

There are some instances when people believe they need a routine to sniff for browsers. Most of the time, they can simply rewrite the function or reexamine the desired functionality and find a solution that doesn't require browser-sniffing.

In rare occasions, you find a function that behaves differently under different browsers (pretend there are more than two). In those cases, do an on-the-spot comparision of that situation -- don't do a browser-sniff.

For example, I have a function in JavaScript that splits a string on a character into two different variables. For most things, this works great. However, when the character isn't in the string, results vary. Some browsers make an empty variable. Some browsers make a Null variable.

At this point, if I were lazy or stupid, I'd write a browser-sniffing function. And I would spend way too much time debugging it for all the different browsers that come along (because I like a lot of browsers).

Instead, I wrote a little conditional that simply checks the types of the resultant variables. This way, the solution pertains to the actual problem, plus if Joe Bob's Crazy Wild Browser changes how it handles that split function, my app doesn't break.

So.

Last night I checked my site stats. I have about 70% or so IE browsers and the rest are a bunch of different browsers (including a lot I'd never heard of!). I see a few hundred visitors a day (and ran across a couple of wankers stealing a little of my bandwidth). So, now you have an n of 2.

You can write whatever you want to write, of course. There are really excellent reasons for writing good code that works under any browser and it's not that difficult.

Cheers,


[monkey] Edward [monkey]

"Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!" -- inventor of the cat door
 
For us, with a limited audience (2,000 est), its quite simple. IE or forget it. Our Netscape users are <1% because we tell them up front to use IE.

We are programming in the new dot NET (VB) -- which is ms.

So, it can boil down to practicality.



 
I agree with EdwardMartin and Sundemon. The main reason javascript works in IE and not in NS is because IE attempts to find your programming mistakes and fix them for you. Netscape doesn't attempt to read the programmers mind or propagate poor programming practices.

I've been writing javascripts for the web since it's inception and have never had the problem of scripts working in some browsers and not others. (Assuming, of course, that they support javascript).

Yes, you have to think a little differently and, as EdwardMartin says, program for the WEB and not for a browser. Programming, or writing scripts, is about finding solutions to problems. Ignoring other browsers (platforms) because your script doesn't work with them is not a solution, it's a cop-out. If you do this, you're doing your clients (and/or your company) a grave disservice.



There's always a better way. The fun is trying to find it!
 
Isadore: For us, with a limited audience (2,000 est), its quite simple. IE or forget it. Our Netscape users are <1% because we tell them up front to use IE.

It's not exactly an either-or choice. [smile]

Even my in-company websites are written for the web and validated against the w3c. When I start developing, I usually run the pages and scripts under IE and Mozilla, to keep my brain sharp and to keep the code clean of proprietary stuff.

I also know that there is some slim chance the scripts might end up being shared outside.

This employer insists that all their client boxes use IE, but they can't insist that all their clients use IE. Fairly recently, we had an emergency website we had to build for a multimillion dollar client, as in screw-it-up-lose-the-account-lose-my-job type client. I did the usual thing and tested it under those two browsers and validated it against the w3c tool (which was frustrating to the other two guys working on it because they were both exclusively IE guys and had never heard of the w3c). Turns out the client also used IE, but their client (whom they were representing) were an exclusively Netscape house.

We came out smelling sweet, were we would have otherwise looked like dumb bobble-heads. Our client, however, had to make a few changes to the way they formatted their own documents. We received several phone calls and a letter from the client complimenting us on the speed of development, the speed of loading (the pages were just rockets 'cause they were small), and the fact that their client was immediately happy that our work looked good on their machines.

So, if you think &quot;web&quot; instead of &quot;<insert favorite browser type here>&quot;, then you'll always do fine.

We are programming in the new dot NET (VB) -- which is ms.

Well sure, you're basically writing and serving a Microsoft application at that point, through a Microsoft browser. It's all proprietary technology and you're up to your elbow in it, so trying to whangdoodle your code at that point to run on anything but the proprietary browser is going to seem pretty dumb. Like I mentioned above, at that point, you might as well write it in VB (or .net, as it were) and just serve the app.

For you, the &quot;do I include Netscape functionality&quot; question isn't really an issue at all.

So, it can boil down to practicality.

Well, you're running all internal and you probably have MS server tech, and if you're using .net, then you're probably dinkin' around with a SQL database or two and stickin' web-like applications onto people's desktops, so you're clearly in for a penny in for a pound. At that point, yes, it become very practical to keep doing it the way you've been doing it. [smile]

That is the cleverness of Microsoft technology/marketing.

Cheers,


[monkey] Edward [monkey]

&quot;Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!&quot; -- inventor of the cat door
 
from another thread someone suggested this site:
I haven't had much of a chance to look at it, but basically they have written some javascript that should let you ignore crossbrowser stuff - ie it handles everything as if it were using the DOM, and behind the scenes gets the references etc.

Anyone used it? Looks pretty interesting.


Posting code? Wrap it with code tags: [ignore]
Code:
[/ignore][code]CodeHere
[ignore][/code][/ignore].
 
The problem with BOTH IE and NS is that neither is FULLY compliant (no browser truly is, though there are some projects out there trying to make one that is - if anyone knows where I can get hold of those, by the way, I'd LOVE to take it/them for a test run). The situation you run into is that those two really are the &quot;biggies&quot; as far as waht the clients are running right now. If you're coding for the internet at large then, yes, you really should code for both of them. Having said that, it's a tremendous hassle to do so, because IE and NS:

* represent some graphics differently
* implement the Document Object Model differently
* layout things on a page (with the EXACT same compliant HTML code) differently
* implement various other javascript code (for example, the event model) differently
* have different &quot;bugs&quot; that may cause one to crash, even with fully compliant HTML code (I ran into this at my old job - it was a browser bug, yet it caused me to completely rewrite some code because we had an internet audience and couldn't &quot;offend&quot; our clients by saying &quot;it's your browser - talk to them&quot;)

Because of all those things, you see more and more (and by that I mean pretty much EVERYWHERE, but I figured I wouldn't use the absolute) that companies require a certain browser for at least their intranet. That greatly simplifies the development process for in-house web pages and intranet applications. If you have the luxury of an environment where you can do that, that is definitely the way to go. If you are programming for the internet &quot;at large&quot;, be ready to spend a LOT of time writing different sets of code for the different browsers.

One more suggestion that has worked for me in the past (though it may sound like more work). Rather than try to &quot;handle&quot; in one page doing things differently for the different browsers, just have two sets of pages. Your index document can then check the browser and direct the user to the appropriate page set, and relative links will keep them in that page set from there. I used an IE subfolder and a NS subfolder to accomplish this - the relative links let me just create one document and copy it to both directories, then only make modifications for a specific browser if it's necessary. That way if one page happens to work the same on both browsers you only have to write it once (and even for the ones that don't you only have to change what doesn't work on one or the other).
 
Finding alternate browsers is easy. Look through your logs for the names and then search on Google.

Most of the time, the sorts of things that cause hassles when running across different browsers are the sorts of things that aren't very important anyway, or that can be easily worked around, or that reveal a programmer trying to pound &quot;web&quot; into a &quot;TV&quot;-shaped hole or a &quot;print&quot;-shaped hole or some other hole that isn't &quot;web&quot;.

The only reason I've seen that a company will require a particular browser for their machines is to relieve their SysAdmins of the headaches of supporting half a dozen different browsers. Most of these folks have to build a machine from scratch in a matter of hours and at that point, they're just going to fire a disk image at it and shove it into production.

Maybe there's a difference in paradigm or something. I find it pretty easy to code for the web. I validate stuff at w3c and I keep my dancing baloney to a minimum. When I run into technologies that are browser specific, or really vary greatly from browser-to-browser, I tend to not use them -- they're headaches. I've always found a better way to accomplish the task.

Like I wrote earlier: You can write whatever you want to write, of course. There are really excellent reasons for writing good code that works under any browser and it's not that difficult.

Cheers,


[monkey] Edward [monkey]

&quot;Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!&quot; -- inventor of the cat door
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top