This question already has answers here:
Why is jQuery not integrated within the browser
(7 answers)
Closed 4 years ago.
It seems like a good idea to me. or add the additional features to Javascript itself?
Because it's just one library of many. It may be popular but it's far from being the only choice. And it would also cause it to freeze at a particular version and make improvements much slower.
Plus there is little advantage anyway. It's fairly small and you can set it to be cachable indefinably by the brower so it will only be downloaded once anyway - if you have a new version it will have a new filename, so there is no harm in making it never expire.
I think this question should be a bigger discussion, but these answers are all bogus.
This is also 2 years later of course.
"it's just one library of many" - include the top 11 then.
"couldn't agree on common standard" - Kind of making jQuery a standard of it's own at this point.
"updated more often than browsers" or "make improvements slower" - So the browser won't have jQuery-1.9.x until next browser update, just don't put it in your project yet.
"Cache anyway" - Sure, it's still a transfer that doesn't have to happen, and there are a lot of people that haven't done a lot of surfing on their new device that you still want your site fast for and so on.
The thing is it is totally doable and would be better for the internet load; by how much is debatable. I could really see chrome at least replacing any net transfer to their CDN with a local copy, but I'm sure there is some legal, security or net neutrality issues with that. Just like I'm sure the main reason has something more to do with such matters and not these lame technical excuses that are obviously not thought through.
This could benefit other libraries too if developers could rely on the speed and availability of a complete library of tools like dojo, and not have to pick and choose just to cut weight. And also as most libraries have adopted the AMD or requireJS approach to package their projects, I believe there is a good argument for the enabling the browser to at least be informed of it's dependencies.
jQuery exists just because they (browser makers) couldn't agree on common standard.
You can consider jQuery to be a JavaScript plug-in. And browsers do not ship with plug-ins, otherwise the purpose of plug-ins would be irrelevant.
Plugins get updated more often than browsers - within a week the browser version of jQuery would be out of date :)
There's also the issue of versioning. Certain sites and extensions of jQuery require a certain version of jQuery. Right now it's up to the application to decide which version to use.
Probably because browsers are hard to update. Some freature of JQuery may eventually make their way into javascript, and I believe some of it has just recently. (well the idea's anyways) It takes years to add a feature to something like javascript, where the JQuery library can just release a new version.
There is actually a firebug or firefox plug in that allows you to inject JQuery into the page.. but thats just a development tool
Adding jQuery [type] functionality to the browser's in-built JS implementation (or making it a 1st-class plug-in) would overcome one basic problem:
As many have said, jQuery is a JS library - meaning, in case the penny didn't drop - that it is written in JS and has to be interpreted at run-time.
Embedding it would mean that it could be written in native code for the OS, making it much more performant.
Related
A rookie here.
Messing with my google scripts projects I have found a strange thing, a method that I was using was strike-through in the editor and it looked like this --> substr . Researching, I found that it is because this method is being deprecated. And for people looking how to solve it look the documentation in developer.mozilla.org.
At first, I had no problem with this, but, if it was not there before, and it is now, that means that the version of javascript that my project is using is changing and I do not want that. And there is my question
Is there a way to make the version of V8 JavaScript that my google script uses constant?
Looking in to the app-scripts documentation I have found that it uses V8 and that it is defined in the manifest but the way of freezing to a certain version is nowhere to be found. Maybe there is an easy answer, but I have no clue where else to look. Any help will be welcomed.
No, there is no way to select a particular V8 version for your GAS.
That said, JavaScript engines are generally very conscious of backwards compatibility. It is extremely rare that features are removed -- there are a good number of "legacy"/"deprecated" things in JS that won't be removed for the foreseeable future, because there's too much old and unmaintained (but still used) code out there that depends on them, and browser makers don't want to break that code.
Regarding the specific case at hand, I personally would be quite surprised if String.prototype.substr ever got removed. I see its deprecation as more of a "pro tip: how not to confuse substr and substring: only ever use one of them".
FWIW, V8 itself has no notion of deprecated JavaScript features. The strike-through you see is just an editor feature. Updating or not updating the V8 version underneath wouldn't affect it.
Taking a step back: writing software once and then expecting it to work without maintenance or monitoring for decades is, unfortunately, generally not a thing. For instance, if you developed a game for Windows 95, you'd have to expect that it won't run well (or not at all) on modern Windows versions. There are countless more examples of operating systems, SDKs/toolkits, compilers/engines, and programming languages themselves evolving over time in ways that guarantee backwards-compatibility for a couple of years but not forever. This is the flip side of technological progress. Pinning yourself to certain outdated versions is generally not a viable solution, for a variety of reasons.
So actually, in comparison, when you write an app or script in JavaScript, you have a very high chance of it still working fine 20 years later. So I wouldn't worry about it too much.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I am working on my first project that requires me to worry about cross browser compatibility. Since this is my first time doing so, I dont know how to go about completing the project. I am specifically worried about IE. Should I complete my project in a more graceful browser then hack it to work in IE, or should I simultaneously build my program up in both environments?
Design your site to work in standards complaint browsers first. I always start with Firefox, even when developing on my company Intranet (where everyone uses IE). Doing so will let you focus on getting your markup and CSS correct. This is what is most important.
The important thing to note is that you'll want to "future proof" your site, and concentrating on a standards compliant browser will help you do that.
Then, once you're confident your site is looking correct (validators are your friend!), try it out in the versions of IE you want to support. In order to get your layout to look OK in IE, I strongly suggest using different stylesheets for each version of IE, using conditional comments.
Also, you should note that many others have been in the same scenario as yourself, and there is quite a bit of help available. One popular method of forcing IE to behave is the ie-7.js project.
Lastly, be mindful of the top IE bugs, such as:
IE6 Box Model Bug
IE6 transparent PNG images (I have used this fix in the past)
A few tips:
Code to Standards — Start by ensuring that what you've just developed works in Firefox and Chrome, and then verify it in IE. I'll usually then check it out in Safari. It's always better to make sure your markup/code works in a more standards compliant browser first.
Validate Early, Validate Often — You don't want your design to look perfect in one browser, find out that it's broken in another, discover that to fix the broken layout you needed to correct some invalid HTML/CSS, only to find that now the first browser looks wrong.
Progressive enhancement — will be your friend. Start basic, with simple HTML and simple CSS, and no JavaScript whatsoever. Repeat tips #1 and #2, then move on to more complex styles and layout. Contiue this iterative process until you are happy with the design in all browsers. Only then should you consider JavaScript to polish the site.
Check each browser often — Don't develop the entire website in a single, compliant browser like Firefox, and then decide to "see what's broken" in IE. If you've got a complex, dynamic website, there could be MANY problems in Internet Explorer. Trying to decipher each one when they are compounding on each other is a nightmare.
Reset Stylesheet — As #Eir mentioned in the comments, find a good reset stylesheet. Although, they have fallen out of favor for some people, I find putting every browser on the same footing from the start helps tremendously.
Use a Framework — I find CSS Frameworks to be excessive, but some people swear by them, so to each his own. On the other hand, as soon as you have made it to the JavaScript phase of development, I highly recommended using jQuery or MooTools. They are very focused on circumventing cross-browser inconsistencies.
Let JSLint hurt your feelings — Even when using a JavaScript framework, there are certain standards of coding to which JSLint will help you conform. Some of the options are a bit overly strict, but I promise that if you clean your scripts through this tool often enough during development, you will almost never encounter those strange times when everything seems to work in all browsers except IE.
And some great tools! Everything in the above list you should consider mandatory practice. The following can spice it up for you in a pinch, but is optional:
CSS Browser Selector — it is rare that you will need this, but if all else fails, it's way cooler than using a separate stylesheet just for one browser (I despise conditional comments). It basically adds classes to your <html> tag, so you can do things like the following in your main stylesheet: .ie7 #header {/*stylese here for IE7 only*/}. It supports a lot of browsers on many operating systems. And it's fast.
Browsershots — Nothing beats the real thing, but if you can't install a suite of browsers, this and other tools like it can help.
IE6 CSS Fixer — I outright refuse to debug my designs in IE6. I coerced my company (via many chagrin-filled meetings with IT and management) to drop support for it (thank god). It's just counter-productive to waste so much time forcing this pile-of-ahem... Anyway, if you aren't like me and need to support IE6, this tool can help.
Also you should focus on resetting css like this
OOoooo, good question:
here's my take:
Decide which browsers you are supporting. I suggest IE 7 + 8, FF, Chrome and Safari as in order of importance. (only support IE6 if you absolutely have to!). It helps if you know your userbase here.
Use a css reset. Different browsers have different default styles. a css reset gives you a consistent base.
Keep your markup as simple as possible. Follow Standards (and see progressive enhancement on Stephen's answer).
Test every step of the way on your target browsers. That way you can correct problems right away. http://crossbrowsertesting.com/ is the best resource for this, but there are free ones for screenshots as well.
Avoid Hacks as much as possible. Most cross-browser issues these days can be solved without resorting to hacks.
Ask questions here when you get stuck. If this is your first project dealing with browsers, you will get bewildered by inconsistencies. We all face these issues, and are glad to help.
Be ok with the fact that webpages are not going to look exactly the same in all browsers. (once again, see progressive enhancement).
Good luck coding!
I develop for Firefox first, and then work out the IE buggery. Rarely do I "hack" it, rather find something that works in both, or at worst use IE conditional comments. Just one coder's preference. Always a good idea to test with Safari, too.
Two big advantages of Firefox are: the Error Console, and the Firebug plugin.
there is alot of greate tools that makes life alot easier for you there is for example a
css framework called blueprint you could use, it has already everything set for every specific browser so that you get the same outcome in all browsers. And using jquery as your javascript framework does add an extra insurance that you'll have it working in most browser.
but remeber there is no such thing as 100% cross browser compatibility for all the browsers and all the versions in world.
In theory would be best to develop for all browsers at once, always testing for every browser...
Realistically, that rarely happens... I typically develop/test with firefox. when I introduce complex javascript or css, I check in ie... this tool is incredibly handy for checking all versions at once... google ie tester.
By checking all browsers at regular intervals, and when you make complex changes, you ensure that major features are compatable :)
Also, ensuring that all of your code is valid is not only good practice, but helps identify cross browser issues.. google w3schools validator :)
Using javascript libraries such as jquery also aid in cross browser compatability, and some even come with css libraries as well. These libraries are purpose built for quick, reliable features that are typically cross browser guaranteed.
Finally, before launching, use launchlist to check that all works: http://lite.launchlist.net/
Hope all that makes sense and helps with your first project :)
what basic tips should we observe in design web pages(html/css/javascript) for having highest compatibility with most browsers(IE-firefox-opera-chrome-safari)?
thanks
Validate often and squash all validation errors by the time you make a public release. The purpose of validation, after all, is to parse the html as a standards-compliant browser would and then avoid the errors that a browser's parser would find.
Apply progressive-enhancement techniques. Often that means moving some of the complexity of dynamic pages to the back-end (e.g. php, django, what have you) so that you can have complex functionality that doesn't break in one of the thousands of different client environments in which a page's javascript will run. jQuery is excellent for narrowing the focus of your javascript development towards feature enhancement instead of open-ended features-in-javascript, and it'll help with cross-browser compatibility as well.
IE - Test in at least one live version of IE 7 or 8. Unfortunately, there really isn't any way around this, because even IE8 misbehaves like no other browser. If possible, limit your goal of support for IE6 to html/css (i.e. don't promise support for user-enhancement-features via javascript in ie6). If possible, drop support for IE 5.5 and below.
For Javascript, use libraries that are intended on being platform-independent (ie: JQuery, Prototype). Not everything will be, but it'll make your life much easier.
For CSS, I'd say follow standards, but IE tends to cause problems across the board.
Which means, you need to test, and test often. Selenium is awesome for automated functional testing, and it works with pretty much every browser. We use a Selenium RC server on a Windows machine to test IE and Firefox, which are then controlled from our standard Java JUnit tests.
Keep things simple.
The simpler your markup, CSS, and JavaScript, the easier it will be to track down incompatibilities. Try to limit yourself to CSS1 for as much as possible. Only use more modern CSS2/3 features when there is no easier way to accomplish your task.
Don't use tables, they just add extra complexity. Using semantic markup not only makes things maintainable, but also gets you the best cross browser support if done properly.
Keep in mind that floats are evil, but are also very powerful. Use them generously, but avoid trying to clear floats. Use overflow instead.
Use a JavaScript framework. Framework developers have smoothed out most of the cross-browser bugs for you. I recommend jQuery, but you can choose any framework your developers feel comfortable with. My advice is to:
Use a JavaScript framework that doesn't alter the prototypes of native objects (like Prototype JS does)
Doesn't introduce many global variables. Most frameworks follow this rule.
Aside from those 2 rules for JavaScript, try using closures to encapsulate code so you don't introduce your own global variables.
One strategy I use is to start my CSS with a set of rules that blank everything out. Each browser may have different values for element attributes so ensuring that everything is consistent from the get-go can be handy. Here is an example reset.css
http://meyerweb.com/eric/tools/css/reset/
Take a look at this great article: Browser Compatibility Tutorial
Remember: something won't just work for a specific browser (mayble a left dotted border won't show in Chrome). Do not be upset about that if you can! :) Cross-compatibility is an art that takes a lot of time.
I was wondering why JavaScript has such a confusing API. It is not consistent across browsers, there is a different way to get the value from each type of form input, and it is unforgiving of mistakes. jQuery has changed my life because its API is so much easier. Why did the creators of JavaScript not set up the API like that in the first place?
The JavaScript API, itself, is consistent between browsers (and is defined by ECMA, though originally developed by Netscape). The difference between browsers is the document object model (DOM). The DOM was developed independently by the different browsers, originally IE and Netscape, but now IE, Mozilla and others. The W3C has joined to try to consolidate the differences and create a common standard. For backward compatibility, the old differences remain. And, yes, jQuery has gone a long way toward making the DOM easier.
Creators of Javascript did not setup the API, since Javascript is a language, not an API.
What you are refering to is the Document Object Model (DOM) which is the document manipulation API. It is a standard specified by the W3C and its behaviour should be consistent among browsers.
Unfortunately, some parts were badly specified, some other parts are badly implemented by browser vendors. Additionally, vendors extend this API with proprietary extensions that may never be added in the standard but that are very popular (like document.all in its time).
That's why today's API in browsers are so inconsistent.
I think most of it is the remnant of the browser war. Javascript had a very troublesome history, made of a total war between microsoft and netscape, with Sun involved as well. Javascript is actually a very nice language. It has some critical design mistakes, but you can work around them. As for the API, you can use a good wrapping library that hides all the complexity and uses the most appropriate API.
One important suggestion, if I may. Don't fight it, nor try to use it masked as something else. Embrace it even with its defects. Once you know them, you won't step on them anymore, or if something is fishy you will find the problem easily.
I'll bite. Check out Douglas Crockford's videos (http://javascript.crockford.com/), he does a good job explaining why some of JavaScript is in the situation that it's in. (http://yuiblog.com/blog/2007/01/24/video-crockford-tjpl/)
This doesn't directly answer your question, but:
A lot of people are bothered by the between-browser inconsistencies. While a few folks become really good at ironing out the differences in their own JavaScript code, most can't afford to spare the time. This is why there is such a profusion of frameworks available to do the dirty work for you. JQuery is the most popular of these, I think, and I'd recommend it to you as an alternative to swallowing a lot of Aspirin for your headaches.
Given the iPhone's 25k limit for caching of files, I'm wondering if there's interest in an iPhone optimized javascript library that makes caching a top level goal. Since it'd be iPhone only it could get rid of most cross-browser cruft and rely on safari specific capabilities, hopefully cutting down some of the girth and staying with 25k.
John Resig discusses this briefly, although mostly to dismiss it, it seems. He does mention:
if you're particularly excited about
breaking jQuery down into little
chunks you can grab the individual
pieces from SVN and build a custom
copy.
Anyone tried that?
Dojo implements a 6k version that seems to rely on deferred loading. I'm mostly a jQuery user so I haven't given it a try, but it looks interesting.
Overall: what do you think about a safari/iphone specific javascript library that implements, say, the top 90% most used APIs in jQuery (or your other favorite library)?
Newer update: looks like Zepto is the way to go these days.
Found XUI, looks like what I was looking for, although I haven't given it a try yet.
You should check out QuickConnectiPhone. It may do what you want. It can be found at https://sourceforge.net/projects/quickconnect/. It also lets you write your app in JavaScript, CSS, and HTML and yet install it on a device.
There is an API that will allow you to make calls down to the Objective-C layer as well for phone vibration, GPS locations, accelerometer information, and some more. You can even extend this to other native phone behaviors as well.
The development blog for the framework is found at http://tetontech.wordpress.com
I'm experimenting with XUI as well, looks promising, seems to follow JQuery-way of doing things.
The same people also created 'lawnchair' for persistant storage of data in json format, XUI+lawnchair looks like a great combination for cross-platform (as in at least iphone+android, maybe webos, symbian, blackberry and ms as well) mobile development.
I think it would be fantastic, but it would be hard to match the testing and reliability of jquery unless someone really picks it up and runs with it. If there was a lightweight, safari only version of jquery that was completely compatible with the plugins and documented methods, it would be a godsend.
Given the increasing popularity of the iphone, I think it would be a really useful thing, it might be possible to remove the cross browser stuff and get it down to size.... however, it would be even more useful if the iphone had a more realistic cache limit.
It does make me wonder if the cache limit in the iphone was determined by the capacity of the hardware or the business needs of the carriers. A 50K cache limit would reduce a lot more carrier usage...