This question already has answers here:
Does Javascript have something like Ruby's method_missing feature?
(8 answers)
Closed 7 years ago.
I need some functionality that works like Ruby's method missing. I have searched and only found 2 ways:
noSuchMethod: Only available to Mozilla Firefox, and I think it's
deprecated or something.
ES6 proxys: Not yet implemented in Chrome, which is a major browser,
and partialy implemented in other major ones as per: https://kangax.github.io/compat-table/es6/.
I was thinking in proxies but is a major drawback if isn't supported by Chrome, and if it's not supported by chrome, probably not for NodeJS either.
Any idea how to implement this feature? maybe a library or plain JS prototyping?
This is not possible without a language level feature like proxies or noSuchMethod. The prototype chain suffers from the same problem that any other solution does in that there is no generic way of handling calls to missing methods/properties on an object.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I am looking to working on a project using node js addons with C++. I came across two abstract library NAN and N-API that I can use. However I am unable to decide which one I should use. I was not able to find proper comparison between these two libraries.
What are the pros, cons and differences of both? How to choose between them?
So far I have found that NAN has more online tutorials/articles regarding async calls. But N-API is officially supported by Node (and was created after NAN as a better alternative, although not sure.)
My understanding is this:
The Node-API (formerly N-API) was added to the core node.js interface in v8.0.0. "It is intended to insulate Addons from changes in the underlying JavaScript engine…" to quote the documentation. It also provides some other wrappers around things like buffers and asynchronous work (which should help avoid some of the underlying non-stable APIs noted in their Implications of ABI stability section).
nan (Native Abstractions for Node) is indeed older and so also supports older versions of node.js — back to node.js 0.8! Now despite its author claiming back in 2017:
As I mentioned somewhere else, N-API is not meant to be directly used for anything. Where has this notion come from? It is an (effectively internal) low-level infrastructure layer meant to offer ABI stability. There will be another layer on top.
…I do not see much warning to that effect in the official Node.js add-on documentation. Perhaps this other comment is a bit more insightful:
Yes, you should still use NAN for production use. It covers every relevant version of Node.js. Also note that N-API is not intended for end users. You should eventually use https://github.com/nodejs/node-addon-api.
Again, that was in June of 2017 by the maintainer of nan at the time. It seems that node-addon-api has matured in the meantime and remains active. In fact, I found a comment in the -addon-api repo that is only a month old at present:
…part of the goal was to make it easy to transition from nan.
So I think the answer is:
use nan if you want something mature and very backwards-compatible
use node-addon-api if you want something forwards-looking in C++
use Node-API/N-API if you are comfortable working in C and dealing with possible lower-level concerns
You should use the node-addon-API module for new C++ code (or N-API for C code). All supported (non-EOL) versions of Node.js support it, and it makes maintaining and distributing native add-ons much easier: whereas addons using NAN require rebuilding the module for each NODE_MODULE_VERSION (major version of Node.js), modules using N-API/Node-Addon-API are forward-compatible:
A given version n of N-API will be available in the major version of Node.js in which it was published, and in all subsequent versions of Node.js, including subsequent major versions.
There's a somewhat confusing compatibility matrix here. N-API version 3 is compatible with Node.js v8.11.2+, v9.11.0+ and all later major versions (v10+), for example.
On top of that, node-addon-API fixes a lot of the annoying parts of NAN (like Buffers always being char* instead of, say uint8_t*).
NAN still works of course, and there are more learning resources online, but node-addon-API is the way forward.
I'd like to use WebGL Extensions from within Rust code that is compiled to WebAssembly. The web_sys::WebGlRenderingContext has a method get_extension which returns a JsValue.
I expect there is a way to either use the dyn_into method to get an ANGLE_instanced_arrays interface, which according to this webidl may be included in web_sys somewhere, but I can't seem to get at it. If it's not possible to get to the ANGLE_instanced_arrays interface, is it possible to call known methods and properties using the JsValue directly?
I noticed that you also posted your question on the wasm-bindgen issues log where they provided some useful information. For other people who come across this I thought I would share the link.
https://github.com/rustwasm/wasm-bindgen/issues/1257
As per this issue: wasm-bindgen issue 893 - Figure out how to support interfaces with NoInterfaceObject attribute The WebGL extensions should be available in the next release.
This question already has an answer here:
Node.js plans to support import/export ES6 (ECMAScript 2015) modules
(1 answer)
Closed 5 years ago.
Just wonder how do we import a module in node.js 8 - are we still using require?
Or do we still need babel for using import?
I have been digging around but seems no answer. If we still have to use require, why can't node implement import yet?
UPDATE-2018.11.15 ↓
Short answer
We're still using require
Long answer
ESM loading has partially landed in node 8.5.0 which was released in September 2017. As such, it has beeen part of the specs as an experimental feature for a little while: see the API documentation here. Caveats include the need for the --experimental-modules flag and the use of a new .mjs extension for modules.
There is still changes that need to happen in V8 before ESM loading is stable and fully featured so as with my original answer, I would still advise on sticking with CommonJS require if you don't already use Babel for other stuff
See this post for a more didactic explanation
PREVIOUS ANSWER ↓
The two implementations are completely different under the hood, so there is more to it than what meets the eyes
The takeaway is that there are still lingering issues/questions over the specifications (all the way to V8), and as such import cannot currently be implemented in Node without a using a transpiler
See this comment (dated February 2017) from one of the contributor:
At the current point in time, there are still a number of specification and implementation issues that need to happen on the ES6 and Virtual Machine side of things before Node.js can even begin working up a supportable implementation of ES6 modules. Work is in progress but it is going to take some time — We’re currently looking at around a year at least.
Keep in mind that transpilers simply converts the ES6 module syntax to the CommonJS module syntax, so there is currently no performance benefits. In other words, if you don't have a Babel pipeline already, there is not much incentives to create one just to use the new proposed import syntax, except from a proactive syntactic perspective
For more details on how the implementation differs, see this write up
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why do browsers create vendor prefixes for CSS properties?
What is the advantage for browsers to use prefixes to implement some technology?
e.g. Google Chrome needs the -webkit- prefix to render some css3-tags, like animation (it needs "-webkit-animation:" to work).
What is the advantage compared to implementing the technique directly into chrome?
Browsers use prefixes so that they can implement a new features before it gets standardized.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
In a related question, I asked about Web Development. I came across something called OpenLaszlo yesterday and thought it looked interesting for doing some website development. The site has a bunch of good information on it and they've got some nice tutorials and such, but being a total novice (as far as web development goes), I'm wondering whether anyone here would recommend this. As I stated in my other question, this is a new world for me and there are a lot of directions I could go. Can you compare/contrast this and other web development you've done? Obviously, this is somewhat subjective, but I haven't heard much about it on SO and I'm hoping to get some opinions on this.
I worked on a website for about a year in which the entire UI was developed in Laszlo. I've also developed AJAX applications using JS frameworks such as JQuery, Prototype and Scriptaculous.
In my experience, the total effort required is considerably less when using Laszlo, and the class-based object model helps to keep your code better organised than when using JS frameworks. My only complaints about Laszlo were that:
It "breaks the browser" in terms of support for the back/forward/refresh buttons. This problem also exists with AJAX, but most JS libraries seem to have found a workaround.
No support for internationalization, though none of the JS libraries are any better in my experience
Relatively small user base/community compared to competitors such as GWT, JQuery, etc.
All in all, I thought OpenLaszlo was a pretty good solution for creating rich web-based user interfaces, and has a number of very novel features, e.g. ability to deploy on multiple runtimes (Flash, DHTML, etc.) without requiring any code changes.
Also, I should mention that I haven't used it for almost a year, so it's likely that some progress has been made in recent times on the issues I mentioned above.
Update
5 years since I posted this answer, things have changed considerably. In case anyone is in any doubt, don't use Laszlo, the project is completely moribund.
I used openLaszlo to develop a few blog widgets for some friends of mine (about a year ago) and it was easy enough to get something basic working and it looked OK. But if I had to do it again, I would probably use FLEX I think you can make a more polished looking application in a lot less time using Flex than with Laszlo
You definitely can write a flash app quickly with OpenLaszlo. There are a lot of similarities to developing for Silverlight.
One OpenLaszlo lameness is that it uses a lame variation of javascript similar to ActionScript. Takes a little getting used to, if you are used to the latest features.
Also, the final flash file that you end up with is very large (file size) compared to what you can do with other tools.
One benefit of OpenLaszlo is the possibility of DHTML output. But for me the mix of XML and JavaScript in the same source file was somewhat confusing.