I've been looking at (mostly) functional languages that can convert to Javascript, and these two stand up top nowadays. But I have two doubts about them, (talking about ClojureScript and Pit for F#):
I suppose that, as both just translate the original language, the moment one makes a call to anything .Net or Java, the program can't directly compile to Javascript. Am I right with this? If so, in this case the ability to interact with the Java/.Net environments is "dangerous".
As far as I know ClojureScript can interact with any JS library out there (node.js, jquery, etc), whereas in Pit they are developing "extensions" to allow this... so I assume importing ANY js library is not supported. I read in SO that WebSharper does support this, but there isn't much evidence and is closed source. So, in practice, how is actually the state of any JS interaction from both languages?
Thanks a lot!
I'm not familiar with ClojureScript, but I can answer some of your questions about Pit (and WebSharper).
Calling .NET libraries
Pit only translates explicitly marked F# code, so when you call standard .NET library or some F# library that does not support Pit, it is not going to work (unlike Microsoft Live Labs Volta project, which is now dead).
However, you can re-implement any such library in F# and tell Pit to use that implementation instead - if the functionality is a part of standard F# library, you can even copy the source code from the open-source F# release. In practice, I don't think this is such a big issue, because most of the .NET libraries are specific to servers or desktops and so you probably won't need that many of them.
Calling JS libraries
Since F# is a statically typed language, it requires to know types of things that you're working with. In Pit and WebSharper, these are obtained by defining F# types (with no implementation) that then get mapped to JavaScript. In Pit, these have to be written by hand, although my guess is that in F# 3.0, this could be done automatically using F# type providers. I believe WebSharper has a tool for that, but it is only available as part of the commercial release.
Interop with JavaScript is not a problem in WebSharper. We ship a lot of bindings to existing JS libraries, and if any functionality is missing, you can recover it fairly quickly in F# with code like this:
[<Direct "jQuery($x).hide()">]
let hide (x: obj) = ()
The challenge in F# is type safety - how much type safety and precise code completion are you willing to retrofit on top of the untyped (and often untypeable!) JavaScript libraries. I never used ClojureScript, but I imagine this is not even a question there since Clojure is untyped as well.
Interop with the underlying .NET platform is indeed "dangerous". As Tomas points out, WebSharper requires that all JavaScript-callable functions are annotated. We have worked around this limitations for some standard classes (strings, collections such as dictionaries, maps and sets), but the support is far from complete.
With WebSharper you can run .NET code on the server and use it via AJAX fairly transparently:
[<Remote>]
let add (x: int) (y: int) = async.Return(x + y)
[<JavaScript>]
let remoteAdd () =
async {
let! sum = add 1 2
return JavaScript.Log("RESULT", sum)
}
|> Async.Start
Unfortunately, if you do have to run large .NET libraries on the client this is not a solution, and you probably have to look in the direction of Silverlight instead.
Disclaimer - I am developing WebSharper, so my input is obviously biased. That being said, when choosing between WebSharper and Pit, bear in mind that WebSharper has active development, support, and has been used on real projects. Since we used it in larger projects, we had to take care with optimizing output code and working around some limitations and bugs in the F# reflection model, even rewriting F# metadata reader for our purpose. This means I can take dozens of closed issues from WebSharper tracker and re-discover them as Pit issues. I do not, for humanity would be ill served by such duplication of effort.
I think ClojureScript is better fit. It has same dynamic nature like JavaScript and it may use Google Closure Compiler for output optimisation. It it designed to run on JS VMs.
There are few differences from Clojure.
Related
I saw those javascript front-end build tools, e.g. webpack, using the word "compile" from time to time. I am not sure what does compile javascript codes mean exactly, at least not like compile c/c++ codes.
I think I understand the "build" process in general, like bundle all js codes into one big file, minify/uglify the codes, using babel to transforms ES6 syntax(transpile). But what does compiling mean here, how does it fit in the whole building process or it is just another name for the whole build process?
Currently, I thought it may be just another name for using Babel to transforms ES6 syntax.
PS. after reading this SO Is Babel a compiler or transpiler? I believe my question is not same as that. Because it is not just related to Bable. For example, webpack also uses the term compiler https://webpack.js.org/api/compiler/ I do not understand its meaning there!
Browserify uses compiler as well e.g, https://github.com/robrichard/browserify-compile-templates "Compiles underscore templates from HTML script tags into CommonJS in a browserify transform"
It's better to describe the process as "transpilation."
Javascript always executes in a specific environment: in Chrome and Electron, it's the V8 engine; in Firefox, it's SpiderMonkey; etc. Each of these engines supports a specific set of language features and not others. As an example, some engines only support var and do not support const or let. Some support async/await, and others only support Promise.
But web developers know about these other features, and they want to use them, even when they're writing for an engine that doesn't support those features. Why? Most new language features are designed with the goal of making it possible to express complicated concepts in simpler and cleaner ways. This is extremely important, because the number one job of code is to make its purpose clear.
Thus, most language features are essentially syntactic sugar for existing functionality. In those cases, it's always possible to express a routine using both new and old syntax. This is a logical necessity.
A transpiler like Babel can read a script written using advanced syntax, and then re-express the script using a restricted set of language features. Relying on an intermediate representation called an abstract syntax tree, it can produce code that is guaranteed to be functionally equivalent, even though it does the work using very different, more widely-supported control structures.
Perhaps we web developers have gotten lazy in our terminology. When we talk of "compiling" javascript, we aren't usually talking about converting the script to something like bytecode. We're talking about transpilation.
Other kinds of build tasks are also becoming quite common. These days, the front-end is obsessed with a million flavors of "templating," because it's extremely tedious and confusing to describe DOM changes using pure javascript, and because application complexity is increasingly very rapidly. Some frameworks require you to convert source code to other intermediary forms that are later consumed by the web application at runtime. Others permit devs to describe UI using invented syntaxes that no browser is even attempting to support natively. Which tasks are needed varies by application depending on which frameworks are being used, the particulars of the application architecture, and the contours of the deployment environment, and that's just a start.
At its foundation, a web page is built using HTML, CSS, and javascript. That much hasn't changed. But today, most serious applications are built almost entirely in javascript (or something very much like it) and sass. Building the application is the process of applying a set of transformations to the source code to yield the final artifacts in those three bedrock languages.
We lump all that stuff under the term "compile."
You pretty much hit the nail on the head. When the Compile (or more appropriately transpilation) operation happens on a JavaScript project it can mean a number of things. As you mentioned these could range from minification, applying polyfills, shims, or the literal act of "compiling" the scripts into a single bundle file for platform/browser consumption.
Transpilation when using super sets of the JavaScript language such as TypeScript, ActionScript, or UnityScript describes the process of converting the source x-script back into native JavaScript which can be in turn be interpreted by a browser (since the browser doesn't recognize the superset languages).
However you are absolutely correct. We aren't compiling our JavaScript into binary, but the term gets thrown around a lot which can lead to confusion. All that said, we are closing in on the age of adoption of WebAssembly and ASMJs which promises to bring the age of bytecode running in the browser which will bring about some interesting possibilities, but alas... That's a story for another day ;)
You're right when you say these front-end Javascript tools don't use the word compile in same context in what your used to with build tools for languages like C/C++. C/C++ compilers turn source code into machine code.
These JavaScript build tools-- like Webpack-- use the word compile in a sense thats more metaphorical than conventional.
When web build tools use the word compile, they're using it in the sense that they are transpiling, minifying (a.k.a uglyfying), and bundling the source files so they are better optimized for client browsers and network requests. (Smaller file sizes, better browser compatibility, less HTTP requests from bundled assets, etc.)
I've used Scala.js, and enjoyed it, for writing web page functionality.
I wrote some graphics-related functions that draw pictures on the Canvas, for instance. I'm interested in porting some of that code to Adobe Illustrator and Photoshop. They offer scripting in three languages: (1) AppleScript, (2) JavaScript, and (3) Visual Basic. Of course the API is quite different than the Canvas and will offer many specific, powerful functions that I would like to take advantage of.
My program will be rewritten and expanded considerably, so development will continue. What I wonder is whether I can continue to develop in Scala and if Scala.js can be used to write code for Adobe software, or really any software that scripts with JavaScript.
I figure that I have to create some kind of interface to the Adobe API. What would that involve? Would that code be written in Scala? Would it be a plugin to sbt? How much would I have to learn about the internals of the Scala compiler?
Is it worth doing this, or should I choose instead to develop in JavaScript? (I don't really want to write in JavaScript directly because I've had bad experiences with it in the browser, but I can't say I'm an expert in it.)
(Note that I'm not familiar with much of the Adobe API yet... I'm just investigating now.)
Should be pretty straightforward. The key is that you'll need to build facades -- strongly-typed Scala descriptions -- for the APIs you care about in Illustrator and Photoshop. This isn't particularly hard: you only have to worry about the functions you actually want to call, and you describe the function signatures in Scala. With a little practice, this becomes pretty easy -- it typically takes a minute or less per function once you have the hang of it. (I maintain the jQuery facade, which is one of the larger ones, and banged out most of it in an afternoon once I was in practice.)
Assuming that they are using reasonable standard JavaScript, that's probably most of it -- you define those facades, write Scala.js code to use them, and plug the compiled JavaScript into the tools...
I need to write a library that can be compiled to Java-classes (to be more specific: Android) and JavaScript or TypeScript (modern Browser and Node.js).
The lib will deal with lists of objects with a lot of numbers and has to calculate statistics and filter/manipulate the lists. No rocket-science, dependencies can be bridged for each environment. No problems with decimal arithmetics. (=> The libs could be developed in TypeScript and Java, but nobody wants to maintain 2 semantically equal sources.)
I've no fear to learn a new language, but integration should be smooth (i.e. create a .jar with standard Java interface and Java types and a .js file for JavaScript/TypeScript without hundreds of kilobytes of runtime).
Could I choose Scala/Scala.js for this?
Would it work with Kotlin?
Has anybody of you guys managed an equal task successfully? What are the caveats?
Well, the basics are very normal for Scala/Scala.js these days -- many libraries cross-compile with no changes. The Scala.js compiler is highly optimized, and only includes code that is actually invoked, so the output is reasonably lean. (Unless you need bulky external dependencies, which the SJS compiler can't do much about.)
Managing the dependency differences will be some extra effort, if you need to deal with them differently on the two sides. This isn't terribly unusual for Scala/Scala.js, but does require that the project be structured for that. The documentation of CrossProject gets into the details.
But overall -- yeah, that's all fairly common at this point...
How does GWT compare (or can it be compared) to Javascript frameworks such as backbone.js, angularJS, Ember, JQuery, etc.? Do they aim to accomplish the same job, making them competitors, or can they be used together?
Yes and no. While GWT's compiler is essentially a Java-to-Javascript converter, the benefits it offers far outweigh anything I've seen from any popular JS libraries.
Since GWT-based apps are written in Java, they gain many of the benefits thereof, such as being strongly typed and extremely easy to refactor. If something changes that affects another class, you know it immediately. And for those things that Java isn't great at, you can always use Javascript to handle the case with JSNI. Google has also provided a great plugin for Eclipse which allows you to debug your code like nothing I've ever seen of a JS library. Another benefit of this is that you write your client- and server-side code in the same language, and GWT does the heavy lifting of tying them together.
There are also the benefits of the automatic generation of multiple permutations. GWT kicks out a copy of your code that looks and behaves identically (inasmuch as is possible) on the most commonly used browsers. Your clients all see the same thing without you carrying the extra weight. You aren't responsible for writing endless lines of code to deal with those countless browser idiosyncrasies that have plagued web developers forever. While to some extent these things are handled by some JS libraries, GWT makes it completely effortless.
In my experience, the libraries you mentioned are all great in their own right, but simply can't provide the powerful debugging, portability, extensibility, maintainability and portability that GWT does right out of the box. GWT isn't really built to work with other libraries, and instead gives you the capacity to do (mostly) everything those libraries can without their help. (Of course that isn't to say that you can't use other libraries wherever you want...you can if you really feel the need to do so.)
So in my opinion, no, there is no competition. GWT is the figurative heavyweight champion in this arena.
Are there any real-world prototype-based programming languages with a whole development cycle?
"A whole development cycle" like Ruby and Python: web frameworks, scripting/interacting with the system, tools for debugging, profiling, etc.
Thank you
A brief note on PBPLs: (let's call these languages PBPL : prototype-based programming language)
There are some PBPLs out there. Some are being widely used like JavaScript (which Node.js may bring it into the field - or may not!). One other language is ActionScript which is also a PBPL but tightly bound to Flash VM (is it correct to say so?).
From less known ones I can speak of Lua which has a strong reputation in game development (mostly spread by WOW) but never took off as a full language. Lua has a table concept which can provide you some sort of prototype based programming facility.
There is also JScript (Windows scripting tool) which is already pointless by the newcomer PowerShell (I have used JScript to manipulate IIS but I never understood what is JScript!).
Others can be named like io (indeed very very neat, you will fall in love with it; absolutely impossible to use) and REBOL (What is this all about? A proprietary scripting tool? You must be kidding!) and newLISP (Which is actually a full language, but no one ever heard about it).
For sure there are much more to list here but either I do not remember or I did not understood them as a real world thing, like Self).
I would argue that JavaScript is a real world language. The main difference is that it tends to be embedded into lots of different environments rather than being a stand alone development environment.
Aside from the obvious use in a browser, JavaScript can be used on the server side using CouchDB (which is becoming very popular as a database both for websites and the desktop) or Node.js - there are lots of others as well. It can also be used to create desktop applications via seed or gjs.
As for debugging tools, these are included in most web browsers and there are extensions such as firebug.
The approach is different in JavaScript - instead of having a core language and using libraries to access different programming environments, it is embedded directly into these environments.
It doesn't look like it. Checking out the Wikipedia list, I can't say any of them are particularly popular for systems-type or standalone programming. And I have a few theories why:
Inertia - people are more familiar with procedural/procedure-class based languages. In the same way procedural languages are more popular than functional, I think we find it easier to mentally keep track of the objects we've specified beforehand
Less error-prone - When I use a class, I can't use things not specified in that class. It's a bit less flexible, but when working on a large project I'm very, very grateful to be able to look at the spec for an object (even if I've written that object) and know how the object will behave. That is, I know the compiler will probably throw an error if I try to do something stupid like use the wrong variable name.
You mention "scripting/interacting with the system". As far as that goes, classes aren't even particularly popular. One-off scripts may use a few functions, or even just straight procedural code. I know if I write a simple little Python script, I'll have a few simple functions and I'll use builtin objects. It's OO, but I'm not writing anything.
No/not many suitable languages. This is I think the biggest one. Lua's great for embedded scripting, but I don't think it can replace Python/Perl scripts in my toolkit.
Prejudice - the sordid past of Javascript has not been good for prototype-based languages, I don't think. Javascript's actually a pretty nice language, once you see code written by somebody that understands it, but there's still a lot of derision - it's seen like a kiddie language. If you say "I'm a Javascript programmer", it's hard to be taken seriously.
EDIT It's either a sign or a symptom, but most PT languages are embedded or application-specific scripting languages (Lua in games or for UIs, Javascript in webpages or for the UI like in Firefox, etc). I'm not sure why this is, but they are either more suited to application customizing or otherwise-embeddedness, or that's what the common implementations are designed for. Python can be easily embedded into a program, and it sometimes is, but it's more common standalone.
This may be more philosophical than you're looking for, and I'm by no means a prototype-based expert, but I've done a fair bit of Javascript and fiddled with Lua. I stand by my answer, though, based on at least personal experience. YMMV.
I see no reason why a PT language as useful as Python couldn't be written, but it doesn't seem like anyone's done it.
I did not found one and the only candidate (JavaScript) is still spending very first steps (like Node.js).
Still one other valid candidate would be JavaScript! There is a .NET based implementation named IronJS which is implemented in F# and is going pretty well. This way one can have whole .NET development cycle at his toolbox. It is based on DLR and can be used in both .NET and Mono!