I saw a pre-launch FAQ on the Adobe Tech Blog that says XD plugins will "be written in modern JavaScript", but what does that mean exactly?
Can I use ES5?
What about ES6/ES2015 features?
Does it support Adobe ExtendScript?
Adobe XD Extensibility is built on top of a Modern JavaScript engine, which means that it understands both older versions of JavaScript (ES5) and the newer variants (ES6 / ES2015, etc.). ExtendScript is not supported for Adobe XD plugins.
Some useful features are listed below:
ES5
Getters / Setters
Array#map, Array#foreach, etc.
ES6/ES2015+
Promises
Template literals
Classes
const and let (block-scoped variables)
Destructuring, default and named parameters
Symbols
Iterators
async and await
That said, if you're not familiar with ES2015+, you're not required to use it.
Related
I need to connect native java libraries for use in the ios environment. In particular, it is necessary to use ready-made support for crypto libraries.
I tried using ikvm(.net core xamarin) for ios. but there is no support for mono-touch.
See this answer from the knowledge base.
You can't use an arbitrary JAR "as is". Please also check the maven dependency discussion in this post.
You can wrap libraries as cn1libs but a library might use arbitrary Java code which might be a problem, see this.
I am new to browser development, so I have no prior experience with AMD, CommonJS, UMD, Browserify, RequireJS, etc. I have been reading a lot about them and I believe I generally understand the JavaScript story but I am still very confused as to how to make everything work together.
I have a library written in TypeScript. It is a pure TypeScript library, it doesn't interact with a browser or any browser framework nor any node or NPM things.
I also have a TypeScript client application that leverages this library. The client application may leverages a web framework as well (e.g., jQuery).
Now when I compile my two TypeScript files (which we will assume are in separate projects, isolated from each other and built separately), each will generate a .js file. In Visual Studio I have to choose AMD or Common as my module loader.
This is where things fall apart. My research tells me that if I want to work on the web I either need to use Browserify or RequireJS. Browserify appears to require I first install Node on my machine and then use a command line tool as a post-build step to generate a file and as far as I can tell this isn't available as a NuGet package. Alternatively, I can use RequireJS but then all of the examples stop working. Something about not doing things on window load and instead doing them somewhere else, but nothing that I have found really explains that well.
So, what is the story here? I want to use TypeScript but at the moment it really feels like it is just a language, there aren't any compelling usage stories available to me as a developer as I have grown accustomed to in the Microsoft ecosystem.
TypeScript does support AMD and CommonJS just as JavaScript. But in addition it also supports internal modules. When using internal modules in conjunction with a decent build system like gulp-typescript you'll find that internal modules can cover lot of use cases where one would choose AMD/CommonJS in traditional JavaScript projects.
TypeScript gives you the freedom to decide yourself. If you need asynchronous module loading you are free to use AMD via external modules. You can also use CommonJS and/or use browserify to link together your code into a single file.
I've found that when you are a library developer - that is you ship your TypeScript compiled JS code to other developers - internal modules are a good compromise. You don't force your target audience (developers) to use any special module system like AMD/CommonJS, but instead ship isomorphic JS that runs in the browser as well as in node. Yet you still have a way of modularizing your code internally, just as AMD/CommonJS would allow you.
TL;DR: When you use TypeScript you get internal modules for free, and they provide you with a flexibility that would else only be achieved by AMD/CommonJS. Yet external modules still have their advantages. In the end, you should decide what is the best fit for your project.
TypeScript is a superset of JavaScript so its story is the story of JS, not of .NET or any other Microsoft product.
If you compile your TypeScript modules to AMD, then you load them through an AMD module loader like RequireJS (or Dojo, or curl) in your entrypoint HTML file, which can be as simple as this (using RequireJS):
<!DOCTYPE html>
<title>Application name</title>
<script src="scripts/require.js" data-main="scripts/client"></script>
(Assuming that your built TypeScript module is scripts/client.js.)
The Start page for RequireJS or the Dojo Introduction to AMD modules are both resources that can tell you more about how to load AMD-formatted modules in a browser.
You got a really good technical answer from C Snover, but the answer you're actually looking for is "don't use external modules". By external modules, I mean "AMD" or "CommonJS" modules.
If you actually need what external modules offer, they can be very useful, but they come at a significant cost in terms of build/deployment complexity and concepts that you need to understand.
Just because external modules are way more complicated doesn't mean they're better; the TypeScript compiler itself is written using internal modules.
You can convert an external module back to an internal module by omitting any export statements on the module itself (and by not having an export = statement at the end of the file either). For example, this is an internal module:
module MyLibrary {
export class MyClass {
public Foo = 1;
}
}
If you are using internal modules, all you have to do is reference them in the right order via script tags in your HTML files and they will work without having to deal with any sort of loader system.
<script src="MyLibrary.js"></script>
<script src="MyUICode.js"></script>
reStructuredText allow you extend/rewrite writer for its markup. So you can add new type of embedded objects or introduce new sub-language by defined API.
Is this possible with Asciidoc (original Python implementation or Ruby asciidoctor)?
Yes to both, though the ways to extend each are different. In the Python implementation there's a conf file you use to create additional regex matchers. In asciidoctor (ruby) there is a full extension system built into versions starting at 0.1.4 (though it was at preview level in 0.1.4). Visit http://asciidoctor.org/docs/user-manual/#extension-points for more information about extensions in asciidoctor. http://asciidoc.org/userguide.html#X7 for asciidoc.
I have the following requirement.
I need to implement dll kind of thing on mac.I need to create a backend library which can be loaded dynamically.This backend library will contain the cocoa classes and c++ classes.
What is advantage/disadvantage of cocoa framework,I was googling so far,I was not able to figure out the best one.Please give me some suggestion.Is cocoa framework also loaded dynamically?
The main difference between a dynamic library and a framework is that a framework can contain resources (images, sound files, nibs, etcetera) and header files. When you use a dynamic library, these are separate.
Both a framework and a dynamic library are loaded at runtime. If your library will only be used on Mac OS X, I recommend creating a framework because it is easier to manage since everything is in one folder.
Bundles (the white LEGO bricks) are almost exclusively used as plug-ins. If you want to create a plug-in interface you should accept bundles and you should provide a framework the bundles can link against. Bundles are also loaded at runtime.
Here's a decent tutorial (PDF form) that goes a little more in depth explaining the differences between ordinary libraries and frameworks.
I came across Microsoft's Portable Library Tools add-in for Visual Studio, but I see System.Xml.Linq is not in the supported list at this time (but does exist on my target platforms).
Knowing that I'm going to have to do some work myself to get multi-platform linq to xml support, does the PLT add-in do anything else for me?
The goal for portable library tools is to have the minimun set of dependencies in order to allow you to create a cool library for different type of projects. The idea is to not to have dependencies in this kind of library, just Dto, Model and some similar stuff are good examples of use