I would like to know when Chrome's declarative web request API will be in the stable channel (https://developer.chrome.com/extensions/declarativeWebRequest). I realize that is asking a lot. I'd like to write an extension that depends on a beta API though and am just curious if there is a best approach for guessing when it might become stable.
declarativeWebRequest is not currently scheduled for promotion to stable. There were some issues with certain use cases that made the current design and implementation insufficient for the long-term support that stable would entail. We have not announced plans to proceed further with the API. You can star http://crbug.com/112155 for updates.
There is no way to guess when a Chrome API be become stable until it does. Priorities, features, bugs, etc make it impossible to predict.
Related
I have a Rails app which is a traditional web application (HTTP requests are processed and HTML pages are rendered). As of now, it does not have an APIs that are exposed to other apps.
I want to use semantic versioning for versioning the application. Currently it is at '0.0.0'.
Quoting from the documentation:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
From what I understand, because there are no applications dependent on mine, the major version will never change. Only the minor and patch versions will change, the major version will always remain 0.
I want to know if my understanding is correct. Is there any scenario in which my major version will change?
Since you're not developing and releasing software package, semantic versioning is not directly applicable. It sounds like a single "release" number could be enough for your use case, since what you need is track when a code change will be in test and in prod. Assuming code must go through test before going to prod, you would update the number whenever you update the test environment with code from the development branch. This way, at a given moment development would have release N, test would have N-1, and prod N-2.
API versioning is a different problem, independent of release numbering. In my experience API users only care about breaking changes, so those need to be versioned. Also, since users are slow to update their apps you must be prepared to keep old versions around indefinitely.
One way you could think about this is to think about the user's flow through the application as the basis for versioning. If a breaking change happens (i.e. the user's flow is changed in a way that makes the old route impossible) then it could be considered breaking. If you're adding new functionality that hasn't existed before (i.e. the user has access to a new feature or sees something new on the website that they can interact with) then that could be considered a minor version increase. If you're deploying minor fixes to things like text, then that could be considered a patch-level change.
The problem with this approach, though, is that you need to understand a user's workflow through the application to be able to correctly increment the major version, and as software developers we're still pretty terrible at doing that properly.
Ref: https://christianlydemann.com/versioning-your-angular-app-automatically-with-standard-version
Roughly 6 months ago I had a chat on IRC with some Spotify engineers about a pending replacement library for libspotify, which I understood is deprecated and no longer developed. Essentially it was said that work was being done on a small POSIX-style native library just for the audio playback portion of the Spotify playback, with the Web API intended to handle every other aspect. I got the impression that the intention was to make this library as small and portable as possible, hence it would work on most platforms, including desktop.
I have not heard any more of this, and I can not find any sources that detail plans to replace libspotify. Besides being fairly buggy, outdated and somewhat painful to use, the current issue I see with libspotify is that it uses a different method of authentication from the Web API, making it awkward to mix data and functionality between these two sources.
Could someone from Spotify please elaborate on whether or not this small native library is at all in development, and whether there are any plans to release it, or at least something that would fill the same role?
(I am a developer at Spotify, but I don't work on this part of our software specifically)
Yes, the small native player library will eventually be shipped for desktop platforms. We are already shipping it for Android and iOS, but those SDKs also have platform bindings so it's not obvious that they are actually using the same library which will eventually replace libspotify.
In the meantime, the Web API has been growing at a steady pace and provides much of the non-playback functionality that libspotify used to provide. At any rate, the replacement library is very much in active development. Last I heard, they are still working to release it for desktop platforms, but I do not know exactly when, since I am not working on the team that handles this code.
I would like to start a community discussion. As per my question, when do you decide to stop supporting older browsers?
I've nearly completed the development of a large personal application. It uses a lot of HTML5, CSS3 and JavaScript. If I were to support older browsers, I would estimate that it would increase my front end work load by at least 50%. And to be frank, I don't want to support the older browsers. From a business point of view, one could argue that if I don't, I could lose revenue. I disagree. I feel that the customers who use older browsers wouldn't be the customers I would want anyway - they would be the ones giving me more work as I'd have to fix compatibility problems in my application to work with their old browser or have to continually tell them to upgrade their browser. If the web is to move on, then people need to stop supporting the older browsers, however, I do see that the tide is slowly starting to turn towards this.
Recently, IE6 was pronounced dead. When can we safely say that IE7 and IE8 or indeed Firefox 3 can longer be considered as 'important' enough to support?
Furthermore, I hear a lot of people say on this site "make sure it degrades gracefully so it'll still work with browsers that don't have JavaScript support"? What kind of browsers now don't have JavaScript support? Mostly old phones and if these old phones don't support JavaScript then I highly doubt that they will parse the HTML correctly either. I also have a Sencha touch mobile version of my application. Am I going to make a WAP version of it to support older phones? No. It's a rich web app. That's how it has designed to be and that's how I intend for it to stay.
I rather like Apple's approach: If you upgrade your OS, don't expect your apps from the previous of the OS to work with the new one. Yes, it can be a frustration, but it means there is less of a mess overrall and people are forced to upgrade to move along with the times.
It works the same way for new web apps, if I want to keep them clean, quick and efficient, I need to stop hacking the code to support legacy software and if users don't like it, they can move on from my site or join the rest of us and upgrade their browser and have a better web experience.
I don't want this to come across as arrogant, but I am genuinely interested in your opinions when you consider enough is enough and only support recent browsers.
For me, I have always assessed the users who would be using it. I think in the end, it is impractical to support every single browser and its version under the sun.
As a baseline, I always ensure that the application works fine in IE8 and the latest version of Firefox. IE8 is pretty decent, so there usually isn't much work required to get it working. As most versions of Firefox and Chrome tend to get auto updated, I just test in Firefox Latest, Firefox 3.Latest and the latest version of chrome.
For example, if I am designing an application to be used by tech-heads, I wouldn't really care much about IE7 and below, or old versions of Firefox and Chrome.
However, if I am designing something that will be used internally and there are certain browser requirements, then I will make sure that the app works perfectly in those browsers (i.e. the dreaded IE6 and IE7).
As IE8 is the "final" version on Windows XP, I think it would be quite beneficial to ensure that things work decently in IE8 at least.
Also, since Facebook and GMail has dropped support for IE7 and below and older versions of other browsers, I think it's safe to say that we can ignore those versions too.
As for javascript, I think it is impractical to build something that works exactly the same without javascript. I think it is a good idea to gracefully degrade, so that certain things might not be avaliable for the user, but they can still use the app to a certain extent.
However, in certain cases, the whole app would not be able to work without javascript (or a non-javascript experience would be next to useless), then telling the user to enable javascript is probably a good idea. This is implemented in apps like Facebook and Google Docs. See this excellent blog post for some debate.
So, in summary:
Develop for "modern browsers", IE8+, FF3.latest and the latest FF, latest Chrome and Opera.
Support other browsers if the development/client requirements exist.
Look at what the big boys (facebook and gmail) are doing in terms of browser support. If they can afford to drop support for browser x and we are developing an app targetted towards general consumers, then we can afford to drop support for browser x too.
I agree with you on the most part that it is a pain to support older browsers and I think that creating web applications that are supported on older browsers such as IE6 and IE7 should be stopped because it is our duty as developer's to help the web advance even further.Furthermore Google has dropped support for every IE browser under IE8 and these in my agenda means that the browser is as good as dead and I can safely stop to create websites for it.
IE8 is a decent browser and is still very widely used even if it's usage is being dropped at an increasing rate : browser usage statistics ; I still think that you should develop for it at least a year from now when hopefully it's usage will be to small to matter
Firefox ,Safari,Chrome and Opera have auto updates witch popup to the user every time a new version is released so most of the times I don't bother checking for older versions how my websites work.
But about the graceful degradation of your websites I still think you should try as much as possible to make your websites work even if you have Javascript disabled because not all users have old browsers that don't support Javascript but there are those who keep it turned off for various reasons
I am considering having a look at Opa. While I am comfortable with the usual way of building web applications, the project seems very interesting, and having the client-server communication handled automatically is a real plus.
My only concern is about security. If a new type of attack or vulnerability is discovered, I can usually take precautions myself. What if I develop an Opa application?
I guess MLState will react very promtply to add bug and security fixes, but is this assurance enough? The company is not huge, and they may be under pressure for other things.
Are Opa projecst flexible enough to allow patching security bugs on my own?
one of MLstate employees speaking :). Glad you like the concepts behind Opa. Now on to the question.
Of course we will try our best to address any security vulnerabilities as fast as possible. If you can patch security bugs on your own? Opa is fully open source so nothing stops you from making a fork of the compiler and making your own fixes at your own pace. In which case of course we'd hope you'd send us a patch to be included in the official branch. Does that answer your question?
We have developed a small web application for a client. We decided on the Dojo framework to develop the app (requirements included were full i18n and a11y). Originally, the web app we developed was to be a "prototype", but we made the prototype production quality anyway, just in case. It turns out that the app we developed (or a variant of it) is going to production (many months hence), but it's so awesome that the enterprise architecture group is a little afraid.
508c compliant is a concern, as is security for this group. I now need to justify the use of Dojo to this architecture group, explicitly making the case that Dojo does not pose a security risk and that Dojo will not hurt accessibility (and that Dojo is there to help meet core requirements).
Note: the web app currently requires JavaScript to be turned on and a stylesheet to work. We use a relatively minor subset of Dojo: of course, dojo core, and dijit.form.Form, ValidationTextBox and a few others. We do use dojox.grid.DataGrid (but no drag N drop or editable cells, which are not fully a11y).
I have done some research of my own, of course, but I any information or advice you have would be most helpful.
Regards,
LES2
I'm not sure how to answer this question except to point out that you'd be in good company using Dojo. Several large corporations, deeply concerned about security issues have contributed to the toolkit and use it in their own products. Audits have been done on the toolkit, including one recently which did expose a problem which was quickly patched -- in fact, the CDN feature of Dojo, if you use it, means you can pick up patches like this automatically. Other than that, I'm not sure what proof to offer. A toolkit is secure until someone finds a security hole! Also, there are plenty of things you can do with Dojo, or the underlying HTML/JS technology, which are not secure. You need to follow best practices. One example is with JSON. There are a couple of methods to handle JSON. The base one is fast, works on older browsers, but is known not to be secure. It is meant to be used only with trusted data sources, and typically with the same domain policy, that's what you'll be doing. There are alternatives in dojox.secure which you might want to look at, depending on what you're doing, you may be able to provide an extra level of security to your application.
For performance, you can look at the various benchmarks like taskspeed, which focus largely on the dojo.query DOM traversal functionality common to most toolkits. Of course, YMMV depending on your usage of Dojo, but there's healthy competition between the toolkits and continuous improvement with each release.
For accessibility, all Dijit widgets were reviewed and considered to be 508c compliant. There is more precise documentation on Dojo/Dijit a11y requirements. Not all dojox widgets pass this requirement.
HTH