I was reading the official Nuxt.js guide, but it says it is only supporting ES6/ES7.
In normal cases, the newest version of ES8 or ES9, they are ignored or not supported yet?
Is there any reason that ES6 is used as a term to mention the newest Javascript version than latest one?
The newser ES standards don't need to be supported by these libraries. You can normally provide support for later standards and experimental features by babel.
Related
So I've just got started with polymer and got this message:
[Deprecation] Styling master document from stylesheets defined in HTML Imports
is deprecated, and is planned to be removed in M65, around March 2018. Please
refer to ....... for possible migration paths.
After doing some reading it seems to be that
<link rel="import" href="/SOR/bower_components/paper-input/paper-input.html">
Was causing the issue and rel=import for html was being deprecated. Is this right? If so what is the fix, how should I be doing this?
Cheers
So, according to the new version of chrome (61.xx.x). Google has made a decision that Styling master document from stylesheets defined in HTML Imports
is not a good approach and so it will be unable to do in future chrome versions.
Because of this, we have to upgrade to version 2.x
Well, nothing much interesting except that Google has made a decision that HTML imports will be removed in future. This is much more frustrating. Everyone who is using Polymer 1.x or 2.x will have to update their projects to newer version of polymer (at least 3.x). Unfortunately version 3.x has no support in all major browsers (except Chrome, but not fully). So we can only hope that the remove of HTML imports will not be soon.
For me this is really piece of s**t. I have many projects written in Polymer and I am not able to upgrade them. (there is no time for this) even i had time, I don't have trust in Google Polymer... Their support is 0. They don't even answer to bugs. Old versions are already stopped from updating. No long-term support versions.
official discussion: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/VZraFwqnp9Y/discussion
The issue has actually been solved by the polymer team, as described on their blog
So versions 1.10.1 or newer for 1.x and 2.1.1 or newer for 2.x are ok, however the warning doesn't go away (see blog entry for more details).
I also tested a polymer 2.6 app on Chromium 65 and on chrome 67 beta and it works fine everywhere :)
If you are using Google Polymer it's worth remembering that webcomponents.js is actually a polyfill. We currently run Polymer version 0.5 and this can actually be tested by starting your current Chrome with those features disabled. On Mac you can do this quitting Chrome and then run from command line:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-blink-features=ShadowDOMV0,CustomElementsV0,HTMLImports
Polymer 0.5 applies the Polyfill when these features are disabled.
Here is the documentation on running Chrome in debug mode Chromium debug flags
Hello as you might now NPAPI is deprecated.
What are the alternatives to this? I see skype released now the web version where you need to install a web plugin to make voice and video calls. Looking over what I installed I arrived to the conclusion that on chrome they are using Google Native Client: https://developer.chrome.com/native-client
But this one is not supported on firefox/safari (only chrome).
On Firefox/Safary I'm not sure what they are using.
So what are now the best alternatives for this kind of job where using c++ is mandatory (to extend an existing app and make it available as web plugin)
Silviu
After Chrome drop the NPAPI support, there is no-common technology support by Firefox/Chrome/Safari. You can consider about Firebreath 2.0. It allow you use one C++ implement to support different browser.
It's not released yet... If you like to try version 2.0, you can get source code from https://github.org/firebreath/firebreath (the "refactor" branch)
Note: version 2.0 make huge change, because the call between plugin and javascript are asynchronous! Upgrade from older version required lots of javascript change.
Found a similar question about the difference between QAPlug-FindBugs and FindBugs-IDEA, but not about CheckStyle...
I think (from previous experience) with these plug-ins that one difference is that the QAPlug's CheckStyle version seems to be behind the CheckStyle-IDEA's CheckStyle version (I'm not referring to the versions of the plug-ins, but of the version of CheckStyle that's embedded in them).
Anyone knows of any other differences between those?
Advantages of CheckStyle-IDEA over QAPlug – Checkstyle:
Newer version of Checkstyle used
Community on GitHub
Fast scan before commit
Support for multiple configurations
Support for third-party checks
I haven't noticed any use case when QAPlug is better.
My application should support offline mode on the following browsers:
IE
Chrome
Firefox
Safari (supports WebSQL only)
and also application using KendoUI for UI. I have looked at JayData which looks good fit for my requirement but I heard JayData wouldn't support some good features like Transactions and so. please share your feedback on Jaydata. also suggest best wrapper to support both webSql and indexedDB?
facebook has an indexeddb polyfill, although there is a bug with indices.
my fork (branch:index_fix) has a fix and a pull request is pending. note: the minified js was not updated, use un-minified version
I have two indexedDB apps and i dropped indexedDB.polyfill.js in there and everything worked perfectly on safari (OSX and iOS)
JayData Pro does support transactions, it's free for non-commercial use and payware for commercial use.
Suitable library depends on use case.
Try my open source library, ydn-db,http://dev.yathit.com/api-reference/ydn-db/storage.html lt supports all of those features.
I will use jaydata for backend sync with odata service. Otherwise, too heavy. Ydn-db itself is heavy. There are many thin wrapper out there. Use facebook indexeddb polyfill for websql.
The Dart language looks like a very nice technology to build web applications for the web. For me it seems that there are no browsers available (yet?) which can run Dart scripts natively. Although there's a description on Dart's site about how to embed such scripts into HTML. I understand that for now i have to "compile" Dart scripts to Javascript. But will this change in the future or the language is designed to be translated to other script standards similar to Haxe?
This is speculation, but I guess that Chrome will likely support dart natively in the future. It will mean that Chrome will be able to outperform other browsers that don't have the native support.
Update: There's a hint from The Official Google Code Blog that it might be coming:
The Dart VM is not currently integrated in Chrome but we plan to explore this option.
Update 2: It looks like I was right! Here's some recent news:
Additionally, and perhaps most importantly, Google is releasing Dartium, a Chromium build with native Dart support.
It’s more than likely that Dartium is part of a series of steps that Google will be taking to launch native support in Chrome — greatly improving the usefulness of Dart. Bringing native support into other browsers like Firefox and IE, on the other hand, will be quite the challenge.
Update 3: Since I posted this answer, Microsoft have released TypeScript which is a competing technology. I'd say it's unlikely that Microsoft have any intention of integrating Dart into Internet Explorer as they would probably prefer people to use TypeScript rather than Dart.
The official answer is Yes, Dart will run natively in Chrome. The branch of Chrome, affectionately called Dartium, is now available as source, and binaries will be released soon. More information on how to get and build the source: http://code.google.com/p/dart/wiki/BuildingDartium
As of March 25 of 2015, the offical answer is: no.
Source: Dart for the Entire Web
Google dropped the integration plan of the Dart VM into Chrome in favor of optimizing the Javascript compilation. Dartium is still accessible for development purposes.
Eventually, yes. The proposed MIME type + usage looks like this:
<script type="application/dart">
main() {
Element element = document.getElementById('message');
element.innerHTML = 'Hello from Dart';
}
</script>
(That example looks like JavaScript, but don't be fooled!)