In Firefox there are plugins and extensions. Could you please explain to me why these addons have different name and tabs ? Does they differ so much so they need different names? I think it's a little unnatural to differ these things, extensions have so much and more functionality, what they lack for comparing to plugins?
The difference is both historical and real:
plugins are compiled, loadable modules, originally descended from NPAPI; they can live outside of the browser's process space (which leads to all kinds of fun interoperability issues and vulerabilities). The most common examples of these are Flash and Java - both request a sub-window ("viewport" or "canvas" (not HTML5's canvas - that's something else altogether: a native part of the webpage)) inside the webpage and handle it themselves, in a way that's largely independent of the browser.
extensions are written mostly in JavaScript and XUL. Since the extensions act as part of the browser, they have wider access privileges than JS-in-a-webpage, but they are still subject to some limitations. The most common way of integration is to hook into some part of FF's functionality and extend it.
So, although the plugins and extensions might appear to be related, they're very different technologies behind the scenes.
According to Mozilla, plugins help the browser display content, such as playing media. Extensions actually add new functionality to the browser.
See the first couple paragraphs here:
https://developer.mozilla.org/en/extensions
One are programs which runs side-by-side of firefox. They get a canvas and when they paint on the canvas, firefox renders it. Notable examples: Flash, Java, QuakeLive.
The other are programs which run in the javascript interpreter/compiler of firefox. They extend firefox functionality more directly, since they have access to the firefox internals and are not merely a canvas. Also, they are much more portable since they do not require underlying support of the operating system as much.
There are advantages and disadvantages to both approaches, and they solve different tasks.
Related
Suppose I'm writing a 2d tile based MMORPG.
Furthermore suppose I hate flash.
Lastly, suppose I only need my code to run in the latest safari, latest firefox, and latest chrome.
What are the limits to what I can and can't do? (Are there examples of good game engines that only require a recent web browser)?
Look into HTML5 Canvas http://en.wikipedia.org/wiki/Canvas_element
The latest versions of the browsers you mention already support it.
Check out the Unity3D engine: http://www.unity3d.com
Cross-browser, cross-platform, although your users would have to download the unity browser plugin...
There's also the Raphaël javascript library...it does a very nice job of abstracting a lot of the heavy lifting you'd have to do otherwise! The memory footprint seems decently light as well (from my small-scale playing around with it anyway).
For something that works for the user, OOBE (without add-ins etc); Javascript is probably the only unified functionality that exists between all browsers.
The browser is surprisingly quite capable (at least Chrome is), this is something that Google Chrome is attempting to promote (see http://www.chromeexperiments.com/). Notice some however, that experiments are often laggy or unworkable in other web browsers.
As for a list of things that are and aren't capable; that would take a fair while to compile.
In regards specifically to a 2D tile based game, I wouldn't say it isn't possible, but it may be quite difficult to create. As mentioned before, most browsers (apart from the stand-out; Google Chrome), suffer from limited resources. Therefore resources wise, it may be difficult to implement and would defiantly require a lot of requirement fore planning.
Java applets are also possible...
You could also move to 3D. While it does require a plug-in (although is being integrated into Chrome), the results are undeniable.
"O3D is an open-source web API for creating rich, interactive 3D applications in the browser." http://code.google.com/apis/o3d/. The video is quite amazing actually -- especially the live map editing (e.g. removing sprites).
I want some personally developed JavaScript code to execute whenever I load a page in Safari. Seems like addblock for Safari does this. Anyone know how to do this?
Safari is not extensible. There's no addon framework for it. But yet there's adblock and verious other addons available for it, although Apple's Webkit and Safari developers discourage users from using them, calling them 'binary hacks'. Seems though some of these addons use InputManager, which isn't documented at all anywhere, at least for not for how people are using it to load scripts in Safari. I guess I'm going to have to backwards engineer to see how addblock does it, but before I do, I thought I'd ask around here. Anyone know?
Input managers are a commonly (ab)used way of injecting arbitrary code into another application's runtime. Once you are there, you have to reverse-engineer enough of the application itself to figure out how to get the behavior you want; usually that involves method swizzling to replace parts of the application you are hacking. It's not documented because there's no API to document, but you can learn about the individual pieces (how to write an input manager in general, how method swizzling in Objective C works, how to use tools like class-dump) and then put it all together.
What you are describing sounds like Greasemonkey though, and there are least one or two hacks already out there to enable Greasemonkey-like behavior in Safari. I'd suggest seeing if one of them meets your needs first.
I'd like to learn how FireFox works behind the scenes. I'd like to understand the source code and the different components but the code-base is rather large and I'm not sure where to start.
I'm wondering if there is some sort of walk though written up by anybody either from the firefox team or from outside the community.
I've looked a little bit at: https://developer.mozilla.org/En but I don't see anything that screams "Start here". I'm simply trying to review their code base for [self-]educational reasons.
Seneca College in Toronto has a program geared towards exactly this -- beginners to Mozilla development.
Check out some of these links:
Real World Mozilla
Fall 2008 Weekly Schedule
Some labs if you want to dive right in:
Lab: Learning Collaborative Development (Fall 2008)
Lab: Building Open Source Projects (Fall 2008)
Lab: Real World Mozilla - Source Code Reading
Lab: Working with Patches
Lab: Dive into Mozilla - Debugging Mozilla
Lab: Thunderbird Bug Fix
Lab: Modifying the Browser
Lab: Modifying Firefox using an extension
Lab: Real World Mozilla - First XPCOM Component
Lab: Real World Mozilla - Adding chrome to first XPCOM component
If you need any help, use IRC: #seneca on irc.mozilla.org. Don't worry if you're not a (Seneca) student, lots of people around the world (people from Seneca, people from Mozilla, and others) are in this channel, the purpose is to educate developers about open source in general and the Mozilla project specifically.
Good luck!
Here's a top-down answer (most of the others are bottom-up):
Firefox is a XUL application (see also: XUL); XUL is a variant of XML used to describe a GUI that is interpreted by a renderer, much the same way that HTML is rendered within the browser, but XUL includes the browser's menus, buttons, status bar, keyboard shortcuts, etc. It's pretty neat; I've been able to put together some simple GUI apps much faster in XUL than in other frameworks (and it's platform-independent!).
If you look in the Firefox application directory (wherever you installed it on your system), you'll see a "chrome" directory with a bunch of .jar files. These are just .zip files with a particular structure (including a manifest) and you can look through them yourself.
Much of the Firefox browser is actually XUL + Javascript. It does utilize a lot of lower-level libraries written in C++ and accessible to Javascript via XPCOM, but if you want to understand (& modify) the higher-level behavior, the XUL+Javascript parts are probably the place to start.
edit: p.s. here are some tutorials/references for XUL: 1 2 and also the O'Reilly book
edit: XUL documents are very similar to HTML documents (only more so!) in the way they interact with the user + events. There's a document model for dynamically modifying the XUL, and there are event models that have event listeners. Both act just like HTML + DOM + its event model, but with a richer set of builtin objects/interfaces/events/etc. The event handlers are interfaces of a particular sort, and can be implemented by Javascript objects (declared in the XUL with onclick="blah()", or added dynamically through Javascript calls to addEventListener() -- both are exactly the same syntax as HTML events in Firefox) or by C++ or other languages that can implement XPCOM objects with the proper interfaces.
One way to start would be to look at some recently fixed bugs in Firefox (see Bugzilla) and take a look at how they were fixed.
That said. The Firefox codebase is very large, and it's likely that no one person understands all of it, so it would be a good idea to start off with a small section (say favorites), and try finding the code for it and looking at how it works. Again, resolved bugs and the files they affect would be a good way of identifying some relevant code to start with.
i worked with mozilla code ( precisely mozilla/nss/security). as far as my understanding of mozilla goes :
It follows layered architecture with NSPR layer (Netscape Portable Runtime ) at the bottom which interacts with Operating Systems.
get the source code from
https://developer.mozilla.org/En/Download_Mozilla_Source_Code and build it in your working environment( as far as i know it support wide variety of platforms/architectures)
join Mozilla developers community/ try to help through testing some of the components.
to code for mozilla, go through :
http://www.mozilla.org/hacking/ ( C++ portability standards is a must if you are C++ programmer).
hope some of the above might help you getting started.
A set of videos was recently released (as for beginning of 2015) that walk through the some of Mozilla Firefox components. Maybe you would be interested in them.
https://air.mozilla.org/search/?q=tag%3A+TorontoBootcamp
They aren't very newbie but still can be helpful I think.
We provide a web application with a frontend completely developed in Adobe Flash. When we chose Flash 6 years ago, we did so for its large number of features for user interaction, like dragging stuff, opening and closing menus, tree navigation elements, popup dialogs etc.
Today it's obvious that AJAX/JS offers roughly the same possibilities and because of the number of frameworks that are readily available, it's very feasible to implement them.
Is there a technical reason one should choose either technology over the other? By "technical", I mean performance, security, portability/compatibility and the like. I don't mean aspects such as the very non-programmer way development is done in Flash or whether it makes sense to switch an app from one to the other.
As I just explained in another question, it seems to me that JS is way ahead in terms of market share and I'm wondering whether we are missing some important point if we stick to Flash.
In addition to what others have said, Flash is constrained in the "rectangle" and cannot be added to a normal html page in an un-obtrusive manner.
#Gulzar I think when more browsers will support the video tag like mozilla 3.1 does we'll see even more adoption of ajax/js over flash.
Adobe Actionscript is a statically typed language, Javascript is dynamically typed. Depending on your point of view, this may be a good thing or a bad thing.
With Javascript/HTML/CSS you're going to be heading into cross-browser compatibility hell, especially if you want to support older browsers. This can be mitigated by the libraries that are available, but it's still a big headache. With Flash, you write the code once and it just works in all browsers.
Even with the libraries available, Flash user controls are simply more advanced than anything you can find in the world of Javascript/HTML. In Javascript, you are not going to find anything that comes close to the simplicity and power of a databound user control that Flash provides.
I don't see how Javascript has more of a "market share" than Flash. Pretty much anyone with a web browser has a Flash plugin installed. I'd be curious to know how many people disable Javascript but have a Flash plugin.
Also keep in mind that you're going to be in for a huge learning curve and lots of development time if you decide to switch your technology base so you'd really better have a good business reason to do it.
This decision also has a lot to do with what your application does and who your install base is.
Edit: I see people have mentioned that the iPhone doesn't have Flash support. I would expect this to change with the install base of the iPhone - Adobe would be crazy not to support it.
Correctly designed AJAX apps are more googleable than Flash
Correctly designed AJAX apps are more easily deep linkable than Flash
AJAX doesn't require a plugin (Flash is pretty ubiquitous, so it's not really a big deal)*
AJAX isn't controlled by a single company the way Flash is
Edited to add:
* Except for the iPhone, as Abdu points out.
JS and Flash both have great presence on the web with overlapping capabilities. One area JS is still lacking is in rendering video.
Flash, used well, allows easy localization and internationalization.
Furthermore, it is much easier to use Flash in an accessible manner; you can feed screen readers the right text, instead of having them iterate over all of the possible form elements.
I think Flash should be limited to online games, videos and animation. Otherwise use html and Ajax. It's a web standard and supported by almost all devices.
AFAIK, the iPhone doesn't support Flash. That's a fast growing segment you're blocking out already. Keep it simple and efficient.
Although flash is pretty ubiquitous on desktop browsers, mobile support is very limited (flash lite? yeah, right). I get really frustrated looking up a restaurant on my phone only to find the entire site is flash based and I can't even get a phone number or address!
One benefit of Flash is that it has a few facilities to help do cross domain type operations safely, which can be helpful. Flash also has (limited) support for some hardware, which is not possible with Javascript.
Personally, I'd try to use as much Ajax as possible before turning to something like Flash. From the UI perspective, it is better in that the controls and basic authoring is a little more developed. The Sound Manager project is a good example of effectively using a small amount of Flash while keeping the remainder in Javascript.
I suspect one of the reasons javascript is becoming more popular is that it's more easy to retrofit into an existing application.
As I can't accept two answers, I'm going to merge Christ Upchurch's and 17 of 26's answers in my own post. I think, these two together pretty much sum up what I wanted to know. Thanks guys!
If you're dealing a lot with polygons, then Flash is still easier to program and debug. With AJAX there are a lot of libraries to handle polygons, but the more libraries your app uses, the slower it gets.
Jeff mentioned the concept of 'Progressive Enhancement' when talking about using JQuery to write stackoverflow.
After a quick Google, I found a couple of high-level discussions about it.
Can anyone recommend a good place to start as a programmer.
Specifically, I have been writing web apps in PHP and would like to use YUI to improve the pages I am writing, but a lot of them seem very JavaScript based, with most of the donkey work being done using JavaScript. To me, that seems a bit overkill, since viewing the site without Javascript will probably break most of it.
Anyone have some good places to start using this idea, I don't really care about the language.
Ideally, I would like to see how you start creating the static HTML first, and then adding the YUI (or whatever Ajax framework) to it so that you get the benefits of a richer client?
As you've said
To me, that seems a bit overkill, since viewing the site without Javascript will probably break most of it.
This isn't progressive enhancement. Progressive enhancement is when the site works perfectly without JavaScript or CSS, and then adding (layering) these extra technologies/code to increase the usability and functionality of the website.
The best example I can give is the tag input box on this website. With JavaScript turned off, it would still work allowing you to enter tags separated with a space. With JavaScript turned on, you get a drop down with suggestions of previous entries.
This is progressive enhancement.
See also Unobtrusive JavaScript which is the bedrock progressive enhancement is built.
Going at it from the other direction is sometimes referred to as graceful degradation. This is usually needed when the site is built first with the enhanced functionality afforded by the various technologies then modified to degrade gracefully for browsers with those technologies are not available.
It is also graceful degradation when designing to work with older browsers (ancient in the Internets terminology) such as IE 5.5, Netscape, etc...
In my opinion it is much more work to gracefully degrade the application. Progressively enhancing it tends to be much more efficient; however, sometimes the need to take an existing app and make it accessible in these lacking environments arise.
Basically, if your site still works with JavaScript turned off, then anything you add with JavaScript can be considered progressive enhancement.
Some people may think that this is unnecessary, but plenty of people browse with addons like NoScript (or, with JavaScript simply turned off in their browser settings). In addition, many Mobile web browsers may or may not support JavaScript. So, it's always a good idea to test your site completely with and without JavaScript.
Progressive Enhancement is a development technique that stresses the primacy of the semantic HTML, then testing for browser-capability and conditionally "layering" on JavaScript and/or CSS enhancements for the browsers that can utilize those enhancements.
One of the keys is understanding that we're testing for what the browser can do, as opposed to browser-sniffing. Modernizr is a very popular browser-capability test suite.
Progressive-Enhancement is inherently (section 508) accessible; it provides for meeting the letter of the law and the spirit of the rule.
The Filament Group wrote the excellent "Designing With Progressive Enhancement" book on the subject. (I am not affiliated with Filament Group, though they are so freaking smart I wish I were.)
This is such an important concept and it saddens me that so few web developers understand it.
Basically, start by building a site/framework in Plain Old HTML -- structural elements, links and forms. Then add on some style and then shiny stuff (Ajax or what have you).
It's not very difficult. Like palehorse says, graceful degradation is more work.
Websites should work in any user agent, not look the same (not even look but sound if your vision impaired), just work.
Progressive Enhancement:
The plain HTML/CSS site is awesome (fully working and user-friendly).
Adding JavaScript defines a new level of awesome.