I trying to decide whether I could to use angular.js (and anguar-ui-bootstrap) in my project.
The web application should work with any reasonably modern browser, I was quite surprised that the right on the angular-ui-bootstrap site, after clicking on "create a build" button the server responds:
Your current browser doesn't support creating custom builds. Please
take a second to upgrade to a more modern browser (other than Safari).
with a link to http://browsehappy.com, where my Safari (v.8) is listed, but the angular-ui-bootstrap explicitly excludes it.
In the FAQ for the angular.js is:
AngularJS is 100% JavaScript, 100% client-side and compatible with
both desktop and mobile browsers.
also the bootstrap 3 itself is compatible too.
Since I am a complete novice to angular.js, just downloaded and trying to learn it, but honestly, I do not want to waste several days/weeks with learning to discover: it doesn't supports Safari fully. The support of all reasonably modern browsers is crucial for the project.
Therefore the questions are:
Supports angular-ui-boostrap any reasonable modern browser fully, e.g. for any functionality?
If not fully, which functions / modules / parts are "problematic"?
e.g. the "build-problem" is the angular.js's "feature" ?
The angular-ui-bootstrap build modal window kicks off a function called isOldBrowser. Looking through their repo you can find that function under misc/demo/assets/app.js. Instead of looking for specific browsers it's looking for the browser to be able to execute specific functions or return certain results. Presumably, the checks would be a very generalized way for them to make sure you have an appropriate browser.
Having said that, Bootstrap lists pretty much every browser as being supported with only a few exceptions (like Safari on Windows) plus a couple of bugs each. Angular has a similar statement in that they support all current browsers (IE9 and up). Either way you should be safe using any modern browser.
Related
I understand that AngularJS will stop being supported in July 2021; after that date, some changes to jQuery etc. might cause AngularJS applications to stop working and AngularJS will not be updated.
I have an AngularJS-based application running in an isolated environment with Internet connectivity normally turned off, i.e. the application doesn't require Internet connection since all AngularJS, jQuery and other JS libraries are embedded in the application. Internet is periodically turned on just to update the Chrome browser used to run the application.
Let's assume that after the end of support period for AngularJS I keep all AngularJS, jQuery and other JS libraries unchanged, but I do allow Chrome browser to periodically update itself.
Question: in such scenario, is there a risk that my application will stop working after updating Chrome, so I should consider freezing Chrome version as well? Or would updating only the browser not cause any changes to the application behavior?
Browsers don't impose certain client-side libraries or their versions on the users. If you don't upgrade any libraries in your app, you should be just fine with your current lib setup. Your app may become vulnerable if some new bugs are found in the outdated libraries, but apart from that, I wouldn't worry too much.
jQuery that you've explicitly pointed out shouldn't be a problem, if you stay within the minor versions and not upgrade to new major version. But even though, the new major versions may still have breaking changes non-related to the functionality you use within jQuery. Check changelogs of those specific new versions. But if your app isn't critical, you can just stay at the versions you're using now if they satisfy the requirements of your app.
I have watched the latest ng-conf and saw Brad Green says Angular2 now weight 45K, and angular1 is 56K. I try to understand what those number represent, but without success.
I also saw this gist that list Angular1 and 2 frameworks by size. And there are completely different numbers there.
The ng-conf YouTube link (it's in 57:10).
The relevant slide:
I understand well your question ;-) In fact, it's after packaging your application and using tree shaking. The latter is a technique that leverages modules to only keep what is used in the application (apply to third party libraries as well).
I think these two links could help you:
http://blog.mgechev.com/2016/06/26/tree-shaking-angular2-production-build-rollup-javascript/
https://medium.com/#Rich_Harris/tree-shaking-versus-dead-code-elimination-d3765df85c80#.6s0vcyv49
The presentation was about offline template compiler that is currently experimental, that eliminates loading Angular2 parser and compiler into the browser by processing the templates and converting all declarative bindings to JS at compile time.
This allows to reduce the Angular2 package code size that actually needs to be loaded into the browser.
If one requires solutions like demonstrated in How to realize website with hundreds of pages in Angular2 the parser and compiler would be required to be loaded into the browser and lose this size benefit.
So I know that AngularJS dropped support for IE8. I'd like to learn, whether this means that they won't simply test in IE8, or did they introduce some features that simply break in IE8.
Did anyone actually succeeded in setting up Angular 1.3+ application on IE8? What kind of approaches/shims are needed (modernir, es5-shims, respond.js, others?)
I have Angular 1.3 working with IE8.
It requires jQuery, a couple of shims and one source code change to Angular. I'm maintaining builds of Angular with a lot of the shims baked in and instructions on what else to include here:
https://github.com/fergaldoyle/angular.js-ie8-builds
I can't get the unit tests running properly with IE8 so can't confirm 100% compatibility, but using a broad smoke test I can confirm every feature I've ever used with Angular works fine in IE8 + 1.3
It simply means that they've stopped testing for anything beyond 1.2.x, which enables them to "add more exciting features to Angular faster, decrease Angular's support burden, and cut [their] build time in half, while affecting only a very small proportion of users."
They're not necessarily removing the hacks from Angular that made IE8 work but there's no guarantee that changes in anything after 1.2.x won't break an application running on IE8 since they've stopped supporting it and addressing any issues that are solely related to it.
The above was what they said in a post about a year ago, so it might very well be the case that there are certain features that break today. With that said, your safest bet would be to work with 1.2.x, unless you want to use 1.3.x and test it yourself.
References:
https://blog.angularjs.org/2013/12/angularjs-13-new-release-approaches.html#!http://angularjs.blogspot.com/2013/12/angularjs-13-new-release-approaches.html
https://docs.angularjs.org/guide/ie
After trying it on my own - no, Angular 1.3 simply won't run on IE8. It's not a matter of shims, or other libraries, or some hacks. It just won't work at all.
I'm wondering if anyone has found a solution to this problem. Is there a way to get the best of both worlds:
build a page-based site, with permanent links, accessibility, SEO, and graceful fallback / progressive enhancement (basically all the best practices of web development)
and, for those with javascript, a responsive front-end experience with ajax loading of content, no page refreshes while navigating the underlying site pages, minimal redundant downloading of scripts/content/css/etc. (all the benefits of a client-side framework like AngularJs or Ember.js)
I see a few major sites are able to manage this (gmail, stackoverflow), and I see that Jeff's new site builds a bare-bones version of the site in a noscript tag.
Is the solution to the hybrid page-based/single-page app to build two versions of the site, send both, and let the client decide which it can show? (is this what gmail does?)
Or is the problem that AngularJS et al. are simply not designed to allow for graceful degradation?
It hurts my DRY brains to think that #1 is the answer.
(The reason I am focusing on AngularJs is that I like its support for html templating, declarative style, and its attempts to fix js scoping. Ember and other frameworks are excellent too; maybe one of them would be a better fit for a hybrid site?)
This questions is a bit of a nuanced one because the answer is "it depends". For example you mentioned Gmail, there isn't any reasons whatsoever that an application like Gmail would need to be indexed for SEO, though depending on what you want or need to support you may want to ensure you can support not having Javascript.
However even the "no-javascript" argument is getting tired and weak these days, at least for the class of "web applications". If I want to use a Windows application I need Windows, if I want to use a javascript powered web application it isn't unreasonable to assume that I'm going to need a browser that isn't crippled to use it.
However back to your question I can only speak to AngularJS because I'm the most familiar with it. For the most part it does allow you to support a progressive enhancement approach, though don't expect to use things like URL routing if this is what you want to support. What you can do is use AngularJS controllers, bindings and directives similar to how you might use jQuery as a way of enhancing the interactions and behaviours of the page.
Just keep in mind this approach will seriously limit what you can do with Angular (or Ember for that matter) and it may start to be debatable what you are getting from this approach that you couldn't easily do with jQuery alone.
The alternative these days is to do what sites like Twitter are doing. That is basically serve fully rendered HTML from the server for any view on the initial load and then use Javascript for subsequent loading and enhanced UI behaviour. This is very effective (though perhaps quite challenging to implement) if you really need to support browsing with and without Javascript and has the added benefit of improve the rendering/load times for the first request. Again "it depends" because it depends a lot on how your site actually works if it is possible to use this. You have to design for it, and it isn't going to be trivial or easy.
Update:
For what it's worth we are taking the Year of Moo approach and rendering the pages that need SEO using PhantomJS and sticking the cached initial state of them somewhere to serve them up. We have a rake task we run on deployments to update this. Again this is just the initial state but it helps get around the issue for now.
Things are always changing though and I'm sure I will have changed my mind on this approach in a year or so.
Have you read Google's Making AJAX Applications Crawlable. You can have JavaScript single page app and crawlable content.
If you stick with angular, there is interesting article: Turns out it is possible to have your AngularJS application indexed
I have heard that EXTJS is a browser independent javascript library. How does extjs make itself browser independent? When I open up the library classes, I do not see any code like :
if (IE)//do this;
else if (FF) // do something else;
Is my understanding correct that extjs is browser independent?
In addition to sha's point, I'm aware that ExtJS uses conditional checks for browser features and selects whether to use things like images, or css for particular visual effects.
Two examples of this would be that it manages to produce rounded corners on it's widgets in IE6 via images, but in anything which supports it, it will use 'border-radius' in CSS.
This is also true with gradients in widgets, which are rendered as images in older browsers, but use CSS3 gradients where supported.
As a rule, from what I've seen, ExtJS uses 'feature detection' to work out what your current browser supports and responds appropriately. A further example of this would be it's charting classes, which render as SVG if supported, or VML on older browsers.
There are some classes in ExtJS you can use to perform feature detection if you wish to do anything specific outside of it's in built in actions too. I'd imagine it uses these under the hood to make decisions about what to render.
That aside, it should be noted that every now and again, you can notice odd discrepancies between browser versions, usually annoying little visual effects, like a scrollbar being present in one browser an not in another, this could however just be a symptom of other code, but I know we've seen a few little quirks from time to time when testing accross IE8, IE9 and Chrome for example.
It is browser independent. As far as I know they have some different CSS definitions for different browsers. If you want to see is there any difference in the JS code you will have to look deeper - probably at some ExtJs core files.
We've been using it so far on IE, FF, Chrome, Safari, Mobile Safari etc.