I've been really impressed by a couple of examples of 'raw' Web Components in the wild, most recently Addy Osmani's latest version of the TodoMVC, called Componentized Todo. Now, with Chrome 36 hitting stable, this example works without Polymer's platform.js shim (which is awesome!)
I wondered how easily, then, it would be to convert this project to use platform.js alone, and get it working on (at first) Firefox stable and (later) Safari, IE, mobiles etc. Because that sounds to me like a really big step forward for Web Components, when they become true extensions to browsers (either natively or through platform.js as a shim), rather than being tied to Polymer as a framework.
I added platform.js to that example and got this running, but couldn't access the template element in the individual files, so had to make some compromises. I've submitted this as a PR: https://github.com/addyosmani/componentized-todo/pull/1
My question is, is this a viable direction for platform.js to be taking - to be breaking beyond its role in Polymer and becoming truly a shim for Web Components in older browsers?
Related
Is it possible to have a single code base for a mobile(ios/android) and web application? I'm thinking about using react native or angular/nativescript. If you have attempted this what are the things to keep in mind before doing this. Also anything particular to for SEO?
Most importantly are there any real world apps with reasonable complexity that already have done this?
NativeScript actually supports this a couple different ways.
NativeScript officially supports Angular; so you can create everything as an Angular application. Almost the entire app can be shared between Web and NativeScript; the only things that can't is the actual screen layout. In Angular for the Web; you use HTML tags so it might be somepage.html <div>{{somevalue}}</div> and for the NativeScript side you would have somepage.xml and it would have <Label text="{{somevalue}}"></Label>. This allows you to layout the app using the native components for Mobile, and web components for browsers, but use the same backend logic.
There are several seeds and platforms that are designed around fully creating a web app and a NativeScript mobile app that can share virtually everything.
NativeScript also supports VueJS; in this case you can again create virtually everything that shares much of its code base, the only thing is again you need separate layout files because again the web uses html, and NativeScript uses native components. So you have to have separate display files.
Disclaimer: I also work for nStudio; I tend to do non-angular type plugins mainly; but I do know that xPlat is really state of the art and has been used in several successful applications that our development studio has produced.
What is the exact difference between plugins, add-on and extensions.
I have read a lot about this and confused,
For example see these four definitions:
1-fire-fox says "Add-ons is the collective name for extensions, themes and plugins" (see https://support.mozilla.org/en-US/questions/790919)
2-www.Differencebetween.net says "Plug-in and Add-on are simply extensions ... Plug-in is the term that is usually used when referring to third party software (interact with a certain program) like flash player ...
3- wikipedia (https://en.wikipedia.org/wiki/Plug-in_%28computing%29) says plugin are being deprecated.
4-I have read in another website that plugins are larger than add-ons and it consist add-on concept.
Also I have read the answer provided in firefox add-on vs. extensions vs. plugins and http://colonelpanic.net/2010/08/browser-plugins-vs-extensions-the-difference/
However I want to understand these differences especially in firebreath where plugins execute automatically through user's consent and add-on should install manually. Also I think plugin embed in htm page while add-on is in form of a separated file like xpi in fire-fox.
Any exact, comprehensive and precise definitions for these three concepts which emerge differences would be appreciated.
General rule of thumb:
Plugins
When you're talking about a web browser, a plugin talks about a NPAPI or similar plugin, which is specific to the page. IE doesn't support "plugins" per se, but they have activex controls which can fill a similar function, though there are also BHO (Browser Helper Object) ActiveX controls which are more similar to extensions. Thus we (the FireBreath team) usually use the term "plugin" to refer to something that works like a NPAPI plugin and the term "extension" to refer to something that works like a typical extension (firefox XPI, Chrome CRX, etc).
Plugins only know about the page they are in; they don't know anything else about the browser or what is loaded in other pages.
Plugins have been responsible for a lot of security problems, since they actually run native code. This has led to a lot of discrimination against them -- much of it deserved. Because of this, and because NPAPI is a royal pain in the neck (hence FireBreath was created), most browsers are trying to phase out plugins. Plugins should never be used unless there is no other way to solve your problem.
That said, there are a lot of cases where they are the only option.
Extensions
An extension is something that is specific to the browser, and they are a bit different on each browser, but tend to be able to learn more about the overall state of the browser; they may be automatically added to pages, accessible separately from a page, etc.
Add-ons
Add-on is more of a generic term which is used to mean a lot of different things. What it actually means just depends on who is talking, but the mozilla definition is probably as good as any; it could be anything that adds functionality to your web browser, regardless of the context.
Key Differences
Extensions tend to be automatic once installed. Plugins are instantiated in one of two ways: 1) by an <object> or <embed> tag in the HTML of a web page, or 2) because they are registered to be the handler for a mimetype which the browser doesn't support.
FireBreath
FireBreath deals with plugins. It has nothing to do with typical browser extensions, only plugins. It is a C++ framework, not a javascript framework, and it allows you to add functionality that can be used from within a web page. Typically FireBreath plugins are used from inside a <object> tag.
FireBreath post-NPAPI
As you may or may not know, Chrome has dropped support for NPAPI plugins (as of version 45) and Firefox has done so as of version 52 (excluding the version 52 Extended Support Release, which will support them for another year). FireBreath 2.0 is now being used in production by several companies and can produce "plugins" (not really plugins, but work similarly) which can work with Google Chrome and Firefox via Native Messaging via a helper extension. The main limitation is drawing; there is no way to draw directly to the browser across native messaging (well, no good way, and no way at all on platforms other than windows).
Eventually we may add support for some abstraction to draw using Canvas / WebGL over the native messaging bridge in FireBreath 2.0, but that hasn't been done yet. Frankly, I don't need it, so I haven't bothered to do it. FireBreath is an open source framework which has unfortunately not received enough support from users in the last couple of years and so the documentation is a bit outdated and there are a lot of little things which haven't been done.
The Native Messaging method relies on an Extension -- we did this primarily to confuse everyone, of course, but also because it was the only way to allow us to communicate with FireBreath plugins from the page in Google Chrome or Firefox.
*(Last updated Mar 6, 2017; Firefox 52 is scheduled to release tomorrow)
Hope that helps. See also:
Browser Plugins vs Extensions -- the difference
FireBreath 2.0 home page
I recently came across this term and I was wondering if there is anyone that could enlighten this concept and how it could fit into application development?
Twitter Bootstrap
You're probably reffering to Twitter Bootstrap. Not to be confused with normal bootstrap, which is something else.
Twitter bootstrap is a small (frontend) css/js "framework" with which you can build fluid web pages. So this is meant for web design only.
This means that when you resize your browser, all elements will be resized aswell, so that it even displays everything nicely on a mobile device.
For examples and more information check out their github page: http://twitter.github.com/bootstrap/
What is bootstrapping? (bootstrap)
Bootstrap (or bootstrapping) is something different. A bootstrap is a piece of code that is run when the machine (or application) first starts. A bootstrap file contains all sorts of standard configurations to configure itself.
There's actually more detail behind the whole bootstrap story, so for more information please read the wikipedia article:
http://en.wikipedia.org/wiki/Bootstrap
Bootstrap(aka Twitter Bootstrap)
It is a powerful front-end(CSS,JS) framework for faster and
easier web development.
It contains HTML and CSS-based design templates for
typography, forms, buttons, navigation and other interface
components, as well as optional JavaScript extensions.
It is compatible with all browsers from mobile to desktop
platform.
Since version 2.0 it also supports responsive design. This
means the layout of web pages adjusts dynamically, taking into
account the characteristics of the device used (PC, tablet, mobile
phone).
Its open source and its hosted on GitHub
To know more
Actually, the people giving the prior answers themselves did not have knowledge of the term and mistakenly, provided to you something "that is more popular".
Bootstrap UI is also called Angular UI. This is a JavaScript Library that is used for enhancing features used in projects using both - Bootstrap + Angular. It synchronized between them regarding pagination and other stuff. It is useful for projects primarily using Angular.
See here more details:
https://angular-ui.github.io/bootstrap/
https://scotch.io/tutorials/how-to-correctly-use-bootstrapjs-and-angularjs-together
Thanks, buddy!
There's one feature in my web application which requires a small browser plug-in to work. 99% of the application is ASP.NET + javascript and we have no skills in writing browser plug-ins or any interest in training someone to maintain it so I've used freelancer web sites with great success to get a working firefox plug-in/add-on/extension.
However, the new Firefox rapid release schedule is throwing this whole plan into disarray because every new version of firefox seems to need a new extension. This is not just to do with the em:maxVersion versions in the RDF file; the plugin actually refuses to load, so it seems that every 6 weeks I will have to commission a freelancer to update the plug-in for the next version of Firefox. From my limited understanding this is because each version of gecko is not compatible with the previous one.
I can't help but think I'm missing something here. For instance, the IE plugin was written in about 2005 for IE6 and we have never needed to touch it; it still works with IE9. Is it really the case that all firefox plug-ins have to be rewritten every 6 weeks, or am I doing something wrong?
The basic function of the plug-in is to use a windows timer to poll shared memory and then traverse the DOM to find a page with a specific javascript function which it then calls.
So my question is, is there any way that I can make a firefox plug-in with a more reasonable lifespan (i.e. year or more), or am I stuck with having to release a new one every time a new version of firefox comes out?
The best way to avoid compatibility issues with Firefox addons when using binary code ( c / c++ ) is to use JSCtypes. Here is a recent overview of how this works:
http://blog.mozilla.com/dwitte/2010/03/12/extension-authors-browser-hackers-meet-js-ctypes/
Here is an entry point to the MDN documentation on JSCtypes:
https://developer.mozilla.org/en/js-ctypes
To avoid this long-term problem with compatibility, I would make a port of your C++ code to jsctypes from xpcom a hard requirement for the contractors you are working with.
What's your experience in using web technologies (HTML, XML, CSS, JavaScript) to implement part of the functionality of a GUI application? Pros and cons, please.
No servers, relational databases, AJAX, or cookies for session management, nor an existing webapp either, but rather a GUI app that uses web widgets (like Qt WebKit) to render and handle substantial parts of the UI, while taking advantage of a GUI framework to achieve an even richer interaction and better desktop integration.
I've already validated that the approach is possible using PyQt. Content can be rendered from the file system or from strings, and URL requests (images or clicks) can be captured and served by the form's event handlers. CSS and JavaScript are supported, perhaps with some limitations.
# ...
self.webView.page().setLinkDelegationPolicy(
QtWebKit.QWebPage.DelegateExternalLinks
)
#...
class TotiMainWindow(QtGui.QMainWindow):
def linkClicked(self, url):
pass # events arrive here
Note: This question is different from this one and this one made before, among other things because there is no requirement to use web technologies on the GUI, but there is the requirement that the application should work without a network connection available, and should integrate well with the default desktop over different platforms, without previous infrastructure requirements (no .NET, Java, browsers, or database servers).
Note: I posted a different version of this question on PMS but found very little experience with this approach there.
Closing Note
I just found most of the information I was looking for in a series of blog posts by André Pareis.
I think the largest advantage to using web markup like HTML/CSS and other web technologies is that desktop apps may very well have their days numbered.
As we speak, Google engineers are working on the Chromium OS, which essentially consists of a single GUI application... the browser...
Now, while nothing may never actually come of it, there is clearly a rising trend in the number of applications accessible through a web browser, accessible anywhere. It seems to me that this is the future of application development.
By using these technologies, this becomes one less headache you have to deal with when or if you determine that your app should be available as a web application.
Update: A few years ago, we developed an Agent Desktop for our call center that is essentially a local application that opens sockets to integrate with the phone system. The user interface the agents use is built with HTML, CSS, and JavaScript, and the experience is stunning. When we released our latest update in 2010 with a professional CSS redesign, our agents were all very impressed with not only how easy it was to interact but also how easy it was to use.
In the future we will port this 100% to the browser, but for now it needs to be a local application because of the COM integration with the phone system.
We did exactly this for a project back when Windows XP was new.
This gave my team several benefits:
A good-looking UI with relatively little effort
Easily change the style of the UI in a consistent manner using CSS
Relatively simple integration with C++ (invoking functions from the ui and vice versa)
The drawbacks we saw were:
Some not-so-good firewalls considered accessing internal resources (ie other html pages in the ui) to be a web request
Adding and accessing the needed resources could in some cases be a bit cumbersome
It was possible set properties in Internet Explorer that would prevent JS from running in the application
Note that some of Windows XP:s programs are using this approach.
This probably works best with small, more Wizard-like parts of the ui (which our ui consisted almost entirely of).
I have since then not really been involved in ui projects, so I cannot really tell you whether this approach is still valid... I know that MFC-based applications will let you use HTML-based dialogs though.
In a similar situation in 2005 I created a stand-alone webapp using XForms, CSS, JavaScript, XML and XML Schema for offline data retrieval and verification. With a good XForms -> HTML + JS transformer (Chiba) it did the job with no bug fixes after the initial release. It was used for 6-12 months (IIRC) by about a dozen engineers for a project gathering test data in the tunnel of the Large Hadron Collider. The biggest surprise of that project was just how much you get for free when going for a web platform, even for offline use. Highly recommended.
The major problem is that it reduces your development speed, or the quality of your user interface. A lot. Unless you're using Seaside, it is much faster to develop a desktop app.
There is quite some number of applications built on top of Mozilla platform. It isn't 100% web technology, as instead of HTML you use XML based XUL, but the rest is indeed web stack (JavaScript, CSS). The most successful of these it the OpenKomodo and it's commercial big brother Komodo IDE.
On the other hand, as far as Qt goes, the newest version 4.7 you can build GUI using QML language. Don't let the name mislead you, it's not markup, it acctually JavaScript with app-specific extensions.