Well, that's a reliefe. You had me worried that my sense of perception was getting bad. I'll admit that I'm not someone who notices 5% differences, or even something less that 50% when we're talking about 2 second webpage loads. I will be content to supply pages to most people who don't notice these small differences. However, if these differences are a nusiance to you, by all means turn off JS until you need it for something important.
That's a good point about letting the new bank know. But if your goal is to expand the use of standards and not to blast fools from existence, then let the old bank know as well.
I hate to keep beating this drum, but JavaScript iself is just text. Granted it has to be interpreted by the browser, but that happens with HTML as well. The advantage though is that I can now control the text of the site dynamically, respond to users form entries, and even give them clarification without leaving the page and breaking the user's thought flow.
I can see that some of you will not be convinced though. If you're comfortable with 90's technology, please continue to use it, but know that your keeping your clients behind the times and limiting your job possibilities. I've already spent too much time defending what is obviously here to stay, so unless someone can come up with a new argument against JS, I'm finished here.
Clarification: Please don't take this Pro-JS talk as a slam against server-side processing. As I said in one of these posts, server-side is the place to go for heavy processing, but it must be used alongside JS. As someone else said, use the right tool for the job.
I'm beginning to see a recuring line of thought in this thread.
1) I used JavaScript once a long time ago and it didn't work becuase the coder was an idiot 2) ??? 3) JavaScript is bad and must be abolished.
If you want to keep using a static web that doesn't respond quickly to your actions and can catch stupid mistakes before making a slow trip to the server have at it. And please stop thinking that beefing up your server with extra power is going to speed up the user's machine or their connection any. It doesn't work that way.
I'm curious, what type of machine are you running? It must be awfully slow if you are noticing 4 or 5 seconds to render javascript, (assuming that the average server trip over 26k takes at least a second and that's being generous). Have you run this "test" recently? On a decent machine (less than 5 years old)? Also, if my code is not using the standards put out by ECMA, then shame on me, but if your *preferred* browser does not support the ECMA script standard, than shame on you. I'm tired of the people who want to get rid of JS basing their decision on old data and poor coding. This is not your father's JavaScript people.
This is a very good point. If you want to do heavy number crunching, do it on the server. If you want to make a useable app that responds quickly, do the UI with JS on the client. Bandwidth may be cheap on the server side, but it is definetly not cheap on the client side and often times not available at all. Applets are definetly not the answer for web applications since you have to download this big application each time you visit a page. Again, maybe in a bandwidth rich world this will change, but not soon. _I'm_ amazed at the number of people who learn how to code web pages on the server and refuse to learn anything else. If you want to expand your audience and improve the user experience, you need to add some interactivity to your page. You have two choices as I see it: flash and JS. I think we all know who wins in that battle.
Two quick points: 1).asp's don't break in Mozilla. ASP is strictly server side. However,.asp is often occompanied by FrontPage and IE specific code. Just wanted to make sure no one was confused on that.
2) Good for you for switching, but make sure you let the old bank know that they lost a customer and why.
Repeated trips to the server are fine when you've got a broadband connection, but the majority of users do not have that yet. The best way to provide the user with the fastest pages possible is to include the logic in the pages themselves to react to the user immediatly. Believe me, I've coded server side for a long time, and continue to do so. But no language (Perl, JSP, ASP, PHP, ColdFusion) and I've used them all, can provide the kind of response times that you get from code running on the client. You've got 3 good points, here's how I handle them.
1&2) The new versions of browsers are coming closer and closer to a standard implementation of JavaScript (ECMAScript if you must) and more importantly, the DOM. By building a framework that can be used repeatedly, you can build code that runs on all browsers with little headache each time you develope a new page. This not only allows you to get around older browser's problems, but lets you create new functions that are available to you each time you code by storing them in the library.
3) JavaScript vulnerabilites are exploited by malicious pages, not by hijacking the javascript that I've coded. The places where javascript causes problems is where it's been written to do that. Coding good, clean javascript will _not_ introduce vulnerabilites into your page. Bad coding and bad people is where vulnerabilities come from.
I think you need to take another look at the types of things that you can and can't do with serverside languages and start to open your mind a bit about what JavaScript's role is in webpages. It has definetly changed from 5 years ago when it was very immature and very unpredicatable.
I think that you're shutting yourself off from a large, and growing, number of sites that will use javascript to create a real application out of the browser that won't require repeated trips to the server for trivial information. I have found countless places where I can greatly enhance the user experience by using DynamicHTML, which requires JavaScript or some other scripting language. I'm not talking pop-up windows, put help boxes that can show up in screen next to the item the user is on, dynamic tree menus that don't require Java, forms that hide fields you don't need to fill out, tabbed forms that don't require a trip to the server to change tabs. These types of user interface enhancments are neccesary to keep bringing the web to a larger novice crowd. It must be easy and it must be fast. Needless trips to the server break that. Javascript can be abused, but if used right, it can make the web more useable. I hope that you'll reconsider you're campaign to destroy JavaScript.
There also would need to be laws to prevent 1984-style monitoring of everything you do.
There is a huge leap to be made from assigning everyone a number and "1984-style monitoring". They really have nothing to do with each other. If someone wanted to monitor you, they would assign you their own ID.
I am a proponent of personal privacy, and I don't have a problem with this system - probably because I can't think of a single intrusion into my privacy caused by it.
And yet you won't give us your number. Why is that? Just curious what your thought process was.
For example if youwere a 2 dimensional being(thats not possible coz 3 is the minumum number of dimensions to sustain life) and a 3D sphere passed through your space, you will see a point, growing into a circle and then again into a point.
Actually, all you would see was a line that got bigger and then smaller. That assumes that you are a 2D being living in a 2D world. In that world, you would only be able to see things from along the plane that you live in. However, if the sphere passed through a plane that was perpendicular to yours, you would see what you describe. For more info on this, read the book Flatland. An interesting read for stretching your mind and pretty funny in parts. At least for a/. crowd.
I'm not sure where you shop, but if you pay $2-3 for twenty sheets of regular paper and $1 for photo paper, I have some ocean front property in Arizona to sell you.
Office Depot sells 500 sheets on inkjet paper for $5 and copier paper for $4. I bought 75 sheets of Premium Kodak Photo Paper for $20 at Sam's. Lasers may give better quality, but you'll pay for it.
If a border has been agreed upon for 160 years it should be left alone. The markers their basing the new lines on seem to be doubtful and sometimes movable! Wouldn't it be better to use the established borders? It sure would save a lot of headaches and "wasted" tax payer money that would be spent straightening this thing out.
In an unsuccessful attempt to find the real story link, I searched the Des Moines Register for "cow power". I ended up with over 50 hits. Not many news sites can say that!
Does anyone know when it will become the official release? My Hosting company won't upgrade until it's marked stable, understandably, but I'd love to know when that will be.
Slashdot Mirror
Well, that's a reliefe. You had me worried that my sense of perception was getting bad. I'll admit that I'm not someone who notices 5% differences, or even something less that 50% when we're talking about 2 second webpage loads. I will be content to supply pages to most people who don't notice these small differences. However, if these differences are a nusiance to you, by all means turn off JS until you need it for something important.
At first I thought that read "Autonomous Robots Leave Race". LOL at the actual story then.
That's a good point about letting the new bank know. But if your goal is to expand the use of standards and not to blast fools from existence, then let the old bank know as well.
Well, I can't explain that. I run a P3 700 with ME and Moz 1.0 and can't say that I've noticed much difference between JS or not.
That's my whole point. Client side code makes for a much more pleasent user experiece.
I hate to keep beating this drum, but JavaScript iself is just text. Granted it has to be interpreted by the browser, but that happens with HTML as well. The advantage though is that I can now control the text of the site dynamically, respond to users form entries, and even give them clarification without leaving the page and breaking the user's thought flow.
I can see that some of you will not be convinced though. If you're comfortable with 90's technology, please continue to use it, but know that your keeping your clients behind the times and limiting your job possibilities. I've already spent too much time defending what is obviously here to stay, so unless someone can come up with a new argument against JS, I'm finished here.
Clarification: Please don't take this Pro-JS talk as a slam against server-side processing. As I said in one of these posts, server-side is the place to go for heavy processing, but it must be used alongside JS. As someone else said, use the right tool for the job.
I'm beginning to see a recuring line of thought in this thread.
1) I used JavaScript once a long time ago and it didn't work becuase the coder was an idiot
2) ???
3) JavaScript is bad and must be abolished.
If you want to keep using a static web that doesn't respond quickly to your actions and can catch stupid mistakes before making a slow trip to the server have at it. And please stop thinking that beefing up your server with extra power is going to speed up the user's machine or their connection any. It doesn't work that way.
I'm curious, what type of machine are you running? It must be awfully slow if you are noticing 4 or 5 seconds to render javascript, (assuming that the average server trip over 26k takes at least a second and that's being generous). Have you run this "test" recently? On a decent machine (less than 5 years old)? Also, if my code is not using the standards put out by ECMA, then shame on me, but if your *preferred* browser does not support the ECMA script standard, than shame on you. I'm tired of the people who want to get rid of JS basing their decision on old data and poor coding. This is not your father's JavaScript people.
Is this stuff done by hand? It seems awfully realistic. That guy either has a lot of free time, a cool ASCII art tool, or a lot of talent.
After giving his comments, the Jupiter analyst was crushed to death by the immense gravitational pull of that planet. Sorry ...
The right tool for the job.
This is a very good point. If you want to do heavy number crunching, do it on the server. If you want to make a useable app that responds quickly, do the UI with JS on the client. Bandwidth may be cheap on the server side, but it is definetly not cheap on the client side and often times not available at all. Applets are definetly not the answer for web applications since you have to download this big application each time you visit a page. Again, maybe in a bandwidth rich world this will change, but not soon. _I'm_ amazed at the number of people who learn how to code web pages on the server and refuse to learn anything else. If you want to expand your audience and improve the user experience, you need to add some interactivity to your page. You have two choices as I see it: flash and JS. I think we all know who wins in that battle.
Two quick points: .asp's don't break in Mozilla. ASP is strictly server side. However, .asp is often occompanied by FrontPage and IE specific code. Just wanted to make sure no one was confused on that.
1)
2) Good for you for switching, but make sure you let the old bank know that they lost a customer and why.
Repeated trips to the server are fine when you've got a broadband connection, but the majority of users do not have that yet. The best way to provide the user with the fastest pages possible is to include the logic in the pages themselves to react to the user immediatly. Believe me, I've coded server side for a long time, and continue to do so. But no language (Perl, JSP, ASP, PHP, ColdFusion) and I've used them all, can provide the kind of response times that you get from code running on the client. You've got 3 good points, here's how I handle them.
1&2) The new versions of browsers are coming closer and closer to a standard implementation of JavaScript (ECMAScript if you must) and more importantly, the DOM. By building a framework that can be used repeatedly, you can build code that runs on all browsers with little headache each time you develope a new page. This not only allows you to get around older browser's problems, but lets you create new functions that are available to you each time you code by storing them in the library.
3) JavaScript vulnerabilites are exploited by malicious pages, not by hijacking the javascript that I've coded. The places where javascript causes problems is where it's been written to do that. Coding good, clean javascript will _not_ introduce vulnerabilites into your page. Bad coding and bad people is where vulnerabilities come from.
I think you need to take another look at the types of things that you can and can't do with serverside languages and start to open your mind a bit about what JavaScript's role is in webpages. It has definetly changed from 5 years ago when it was very immature and very unpredicatable.
Yeah, :-)
I thought of that after I posted. I was hoping no one would see the hole in my logic, but I was wrong. Damn!
I think that you're shutting yourself off from a large, and growing, number of sites that will use javascript to create a real application out of the browser that won't require repeated trips to the server for trivial information. I have found countless places where I can greatly enhance the user experience by using DynamicHTML, which requires JavaScript or some other scripting language. I'm not talking pop-up windows, put help boxes that can show up in screen next to the item the user is on, dynamic tree menus that don't require Java, forms that hide fields you don't need to fill out, tabbed forms that don't require a trip to the server to change tabs. These types of user interface enhancments are neccesary to keep bringing the web to a larger novice crowd. It must be easy and it must be fast. Needless trips to the server break that. Javascript can be abused, but if used right, it can make the web more useable. I hope that you'll reconsider you're campaign to destroy JavaScript.
It's my birthday in DDMMYY form, ...
Doesn't that format start to cause problems with anyone over 100 years old?
There also would need to be laws to prevent 1984-style monitoring of everything you do.
There is a huge leap to be made from assigning everyone a number and "1984-style monitoring". They really have nothing to do with each other. If someone wanted to monitor you, they would assign you their own ID.
I am a proponent of personal privacy, and I don't have a problem with this system - probably because I can't think of a single intrusion into my privacy caused by it.
And yet you won't give us your number. Why is that? Just curious what your thought process was.
For example if youwere a 2 dimensional being(thats not possible coz 3 is the minumum number of dimensions to sustain life) and a 3D sphere passed through your space, you will see a point, growing into a circle and then again into a point.
/. crowd.
Actually, all you would see was a line that got bigger and then smaller. That assumes that you are a 2D being living in a 2D world. In that world, you would only be able to see things from along the plane that you live in. However, if the sphere passed through a plane that was perpendicular to yours, you would see what you describe. For more info on this, read the book Flatland. An interesting read for stretching your mind and pretty funny in parts. At least for a
I'm not sure where you shop, but if you pay $2-3 for twenty sheets of regular paper and $1 for photo paper, I have some ocean front property in Arizona to sell you.
Office Depot sells 500 sheets on inkjet paper for $5 and copier paper for $4. I bought 75 sheets of Premium Kodak Photo Paper for $20 at Sam's. Lasers may give better quality, but you'll pay for it.
I thought earth was getting Fatter.
To confuse matters, there is also Kansas City, KS right accross the river!
If a border has been agreed upon for 160 years it should be left alone. The markers their basing the new lines on seem to be doubtful and sometimes movable! Wouldn't it be better to use the established borders? It sure would save a lot of headaches and "wasted" tax payer money that would be spent straightening this thing out.
In an unsuccessful attempt to find the real story link, I searched the Des Moines Register for "cow power". I ended up with over 50 hits. Not many news sites can say that!
Does anyone know when it will become the official release? My Hosting company won't upgrade until it's marked stable, understandably, but I'd love to know when that will be.