Tag Archives: JavaScript

The ES6 Development Scheme For React Using GNU Make

The ES6 Development Scheme For React Using GNU Make

ES6 is so much better than current JavaScript that I couldn’t write any line of JavaScript if not using ES6. The problem is that, main stream browser and even most recently version of NodeJS(!) couldn’t support it.

Yes, there will be so much work to be done to let these engine support ES6, but since most JavaScript developers are also as eager as me.

So they build Shim and Polyfill for it. But what about the syntax change of the ES6?

This is a little complicated, since current JavaScript engine won’t accept the new syntax, so there must be some kind of translation or compilation.

And there is, Babel is one of them, and the one I used most in my workflow (and there is another reason that I use Babel as the compiler, the reason is that Babel supports React’s JSX officially, I’ll talk about that later).

The Problems To Face When Using ES6

It is not easy to choose the way of using ES6 as the main language when developing JavaScript application. You’ll get many problems to face, just list as below:

  1. Every out file must be compiled, or you won’t get your application run on any browser or nodejs
  2. Since all the output file are compiled, you’ll face a problem of C, you can’t debug the running code, unless you have some kind of debug data exists, because the result code is quite different(compiled and optimised) than the original one
  3. There is no official JavaScript dependency mangement(for browser), so you must choose one(for example bower, or npm), and of course, they’ll have nothing ES6(since they are JavaScript running on current engines)
  4. For these files, including them or tracking the change is quite complex

The Solution

For Babel, it can compile the ES6 file and create an Source Map and using main stream browsers(Firefox or Chrome) to debug the original code (yeah!).

And let’s face the problem again:

  1. Must compile source to dest code
  2. Must compile and create source map file/data
  3. Files are stored as trees in directory, must track every file’s change so that, you don’t rebuild the whole directory again when only change a small file

What development scheme do you recall? It’s C!

For C development, we use Makefile and Bash to to that, and it works perfectly(Yes, I know there are plenty of them using Grunt, but GNU Make and Bash can do a lot better than that).

But how about the problem 3?

For C, it is quite easy, since every file is compied as an object file .o, there will be another process of building, it is called linking.

And is there any tool in JavasScript support linking? Yes, the tool I used is Browserify.

So, the solution that will solve the problem above, should be something like this (exactly same as C, I’ll add the C part as comparation):

  1. Compile the code and generate the debug information (Babel – GCC)
  2. Tracking the file change and do the incremental compile (Makefile)
  3. Complex test and directory operations (Bash)
  4. Linking the output file and required libraries together to the product (Browserify – Link)

And Beyond That

And the way beyond is that you can make the style files be compiled too(I use Sass to compile the style code)

Even more, you can add the phase of Uglifying JavaScript and Css and the deployment phase to your make file as well.

The Details

First, you must have a GNU Make installed on your system.

This should be quite easy, you can use any package manager to install it(including Cygwin), the version that I installed using mac ports, is GNU Make 3.81.

Then you’ll need to setup the compiling environments:

  • For ES6 compilation, you’ll need
    • NodeJS: This is the JavaScript runtime based on Google’s A8, and yes, this is also platform independent, you can install this in almost all the morden OS
    • NPM: The Package manager of Node, it is bundled with NodeJS’s installation, so you won’t need to install it.
    • Babel: The ES6 compiler that I used, this can be installed just using npm like this:
      npm install babel
  • For the result linking you’ll need:
    • Browserify: The tool that used to package all the JavaScript dependencies together and make them a single JavaScript file(I’ll talk about the benifits and cons of single JavaScript file and browserify in another post), you can install browserify just by using this command npm install browserify

And there you go, you can make GNU make to build your project.

The Make patterns

The first thing for compile is to add the compile patterns to do the compliation(just like C, source files are using file extension .c and the output files are using file extension .o).

I’m using this scheme to init the pattern:

  • The dependencies are using NPM to do the management, so, all the dependencies are standard JavaScript (.js) files, and used using Common JS’s require thing (but, Babel can make it better, you can just use the import key word to do the function, and babel will compile it to the code that support Common JS)
  • All the source files of JavaScript all have the .jsx file extension to distinct from the js outputs (it has two meanings to use the .jsx file extension):
    • Babel can compile the JSX code for React, so it is very natual
    • You can make your JSX editor plugin (for example VIM plugin) to recognise this, and since JSX is a super set of ES6, so you’ll make your editor support your source files automaticly
  • All the compiled result are using .js file extension, having the same file name

So, the pattern to compile all the source file is something like this:

%.js: %.jsx
        $(SILENT) $(BABEL) -s inline -o $@ $<

The meaning of this pattern is like this:

  • All the js output file can be compiled using the source code file of jsx, for example, if you want to make a js file named hello.js, make should find the source file named hello.jsx, and compile it using the operations below and make hello.js
  • $(SILENT) is the make trick to have the debug output, let’s ignore it, suppose it is blank
  • Here is the operation$(BABEL) -s inline -o $@ $< this command means that I want babel to compile the source map into the output and $@ means the output file name $< means the input file name

So, if you have this pattern in your Makefile, you’ll have the ability to make any JavaScript file by compiling the jsx file of same name, and store them in the same folder.

The Source Files And How To Build The Dist File

But how can you specify all the source files to let them to be compiled by make, you can use this way(so straight forward, but not wise)

SOURCE_FILES := hello.js world.js bye.js main.js

This is a little stupid, but straight forward.

Is there any better way to handle this? I’m using a macro to do this, it is something like this:

rwildcard=$(foreach d,$(wildcard $1*),$(call rwildcard,$d/,$2) $(filter $(subst *,%,$2),$d))

SRC_DIR := src
SRC_FILES := $(call rwildcard, $(SRC_DIR), *.jsx)

This settings will have all the jsx file in the src folder set as the variable SRC_FILES. Then you can use this variable to add the build task.

build.js: $(SRC_FILES)
    $(SILENT) $(BROSERIFY) $(SRC_DIR)/app.js -o build.js

And even add the uglified version of the build.js

build.ugly.js: build.js
    $(SILENT) $(UGLIFY) build.js -o build.ugly.js

How About Unit Testing?

For unit testing, we can just use Jasmine.

And using the variable and tasks like this:

SPEC_DIR := spec
SPEC_FILES := $(call rwildcard, $(SPEC_DIR), *.jsx)

test: $(SPEC_FILES)
    $(SILENT) $(JASMINE)

The problem

So far, there is an problem using this way, is that the linker of browserify is quite qutie quite quite slow.

For my project, it’ll cost at least 6 seconds on a MacBookPro Retina 2015 to build the result , this is unbareable, so I decide to write a new linker(just the linker, which supports CMD requiring and add the glue code to make it works in a single file) in Go, and that’ll make it faster.

This will take a little time to finish, so, before that, I’ll just using browserify to do the job.

What Next?

So much for this blog post, I’ll write another blog post about the project setup, and after cleanup the code, I’ll create an project bootstrap on the github.com to let you understand the benifits of this method.

The launch of Jersey

I was glad to announced that the launch of my JavaScript execution environment(called Jersey, in the name of JavaScript of Easy).

This begin with the thought on how to get a handy too to handle the tiny programming works I have to do very often, and has many foundation between(such as text manipulating, http site data fetch and processing, xml processing, html processing, sold data updating or data migration).

I’ll write an article to explain the this later.

The link for Jersey is https://github.com/guitarpoet/jersey and the README of it is below.

Jersey: A pluggable JavaScript execution environment

This is a pluggable JavaScript execution environment based on Rhino. It can run on any Java runtime above Java 5.

Jersey also contains a package manager called jpm, so you just need to provide an ivy module file, then you can get all the plugin and plugin dependencies using maven distribution.

Concept

Jersey is a running environment for JavaScript, it can run Mozilla Rhino flavoured JavaScript using Java. The aim for Jersey, is to provide a nice and pluggable environment to playwith or use JavaScript and based on the richi set of Java libraries.

The concept of Jersey is as list bellow:

  • Pluggable: Jersey is pluggable, you can install any plugin to it, and the plugin is just a java jar. All the plugins are deactivate at the start of the enviromnent, you can activate the plugins using Spring(Jersey provides you the functions to do that).
  • Simple: Jersey try to provide the api as simple as possible, and provide a console to play JavaScript with and will add the support of other script that compiles to JavaScript(for example, CoffeeScript) using the console, and the console support the tab completion, so you can fool around very easily
  • Configurable: Jersey provides the configuration basics based on Java’s properties, and all the configuration for application and plugins contains within the same configuration file
  • Discoverable: You can list all the provided function and provided modules using native functions.
  • Docable: Jersey provides the doc method for all the function and plugin modules, you can read the documentation of the function and modules using man function, and even have a pager function to view the pages.
  • Easy to be server: Since Java has many good embedded services, Jersey using Apache Derby to provide Database service and using Jetty to provide http server service, I also have a small CMS system written using the mvc and http plugin of Jersey
  • Easy to use: Jersey providing the pacakge management system based on the Famous Maven and Ivy, so you can download every plugin and plugin dependencies using Ivy’s module file.
  • Can support other languages: Since JavaScript is not a very simple language to write, Jersey also supports Coffee script(detected by the file extention) and using coffee to compile it and run, will support others in the future
  • Powerful: Jersey is based on Java, so it can take advantage of current Java and opensource Java libraries to provide powerful functions, it can use JDBC to access Database, using Commons DBCP to make the database connection pool, it can use Solr client to access the Apache Solr, it can use Log4J to handle the logging things and even using JBoss Drools to do the Rule matching.
  • Stable: Thanks to Java’s stablility and JavaScript’s simplicity, Jersey can be very stable for running, it can run very long time without memory leaks or make system unstable. Jersey’s multithreading is using Java’s multithreading support, and Jersey provides a JobManager function using Java’s concurrent library.

Architecture

Jersey is based on Java, Rhino and Spring, the component structure of Jersey is based on Spring, and the interpreter of JavaScript is using Rhino.

All the native functions and native modules is initiliazed at the intializing of the environment, all the plugins you want to use, need to be installed into the lib folder first, configure it correctly in the configuration file, then using require function to require the intialize script for this plugin.

Usage

Jersey is used using commandline, you can run the console using just jersey command. Or jersey a.js b.js c.js to run the script file one by one.

Jersey accept -c option to get the option file location (default is config.properties), and -s to get the script file(This only used for standard in, standard in file for Jersey is – )

Native Functions

Here is docs for some native functions that Jersey provided, you can list all the native functions using function functions().

  • require: Require the library using the resouce location, support file:file and classpath: protocol.
  • appContext: The function to load application context to javascript console
  • config: Read the configuration from system.properties or list all the properties
  • functions: List all the functions this shell provided.
  • modules:Prints all the modules that have loaded.

Native Modules

Here is the docs for some native modules that Jersey provided, you can lis all the native modules using function modules().

  • console: The console object.
  • file: The file utils.
  • csv: The csv utils service.
  • sutils: The string utils service.

Standard Libraries

Jersey provides some standard JavaScript libraries in the distribution. Here is the list of the libraries:

  • std/common: This provides the common extention of JavaScript, for example capitalize, isBlank, endWith for JavaScript and so on.
  • std/date: This provides date
  • std/evn.rhino: This provide env, to use library like jQuery
  • std/man: This provide the manual function for all the native function and modules
  • std/jquery: This provides the famous jQuery
  • std/underscore: This provides underscore

You can load your scripts using classpath protocol too.

Let’s Talk About JavaScript (Part 1)

Mammon slept. And the beast reborn spread over the earth and its numbers grew legion. And they proclaimed the times and sacrificed crops unto the fire, with the cunning of foxes. And they built a new world in their own image as promised by the sacred words, and spoke of the beast with their children. Mammon awoke, and lo! it was naught but a follower.

from The Book of Mozilla, 11:9 (10th Edition)

To me, the programming languages can mean many things, they are tools to do specific jobs, they are the grammar and words to explain the problem and how to handle the problems, they are the methodologies to understand and explain the world’s reality to logic and entities.

So, to me, the programming language has 3 parts:

1. Methodology: This part is the fundamental side of the language, the philosophy of the language, the core concept of the language. This part explains why this language exists, what’s the original purpose of this language and how it evolved. This is the metaphysics side of the language, but the most important part to understand the language deeply(at least for my opinion).
2. Words and Grammar: This part is the body of the whole language, how to claim a flow, how to claim a data structure.
3. Fundamental Libraries: Although the first 2 part define what the language is, this part(the fundamental libraries) for the language runtime, is very crucial for the language, it even can affect the success of the language

As this article is the first part of the discussion for JavaScript, so, I’ll talk about the methodology of JavaScript first.

As I said, the methodology of the language is more important part for the language, and how the language is designed, why this language should been created should be discuss at the very begining.

First, the name, JavaScript is a trademark of Oracle Corporation(cited as Wikipedia). It is the common name for ECMAScript v3(for today’s talking), so, when I talking about JavaScript in my blog, I was really talking about ECMAScript (and v3 only), just the standard features and standard build in function and objects.

So, what’s an ECMAScript then?

ECMAScript is an object-oriented programming language for performing computations and manipulating computational objects within a host environment.

And what’s the purpose of the ECMAScript, why we should need it?

ECMAScript was originally designed to be a Web scripting language, providing a mechanism to enliven Web pages in browsers and to perform server computation as part of a Web-based client-server architecture.

As we can see in the ECMAScript’s introduction[http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%203rd%20edition,%20December%201999.pdf] and about [http://inventors.about.com/od/jstartinventions/a/JavaScript.htm]. JavaScript was originally inspirited by the idea of Java, that you can run computation and show animations in the web browser(web pages are really dull back to that year).

So, in the design of JavaScript, the author even don’t think the most fundamental part of the programming language, the Standard Input and Standard Output should be necessary.

As stated in the ECMAScript’s standard:

ECMAScript as defined here is not intended to be computationally self-sufficient; indeed, there are no provisions in this specification for input of external data or output of computed results. Instead, it is expected that the computational environment of an ECMAScript program will provide not only the objects and other facilities described in this specification but also certain environment-specific host objects, whose description and behavior are beyond the scope of this specification except to indicate that they may provide certain properties that can be accessed and certain functions that can be called from an ECMAScript program.

So, we can have a conclusion here:

JavaScript (the language standard ECMAScript v3) is a web scripting language, it is interpreted by the host environment (run time), and besides the language grammar, other things that needed is provided by the host environment, and these things are depended by the host environment, not the language itself.

Then we can get the real fact of JavaScript, it is a interpreting embed language for running the computation tasks by the host environment.

And why I think JavaScript is a good(in fact very good) interpreting embed language, let’s see JavaScript’s philosophy(I try to make it clear, but I’m not teaching JavaScript here, if you want to know the details of JavaScript programming, you can find it on W3CSchool).

1. JavaScript is a Object oriented language

Everything in JavaScript is an object, the object itself is something like a hash table(so javascript don’t need bother to have the data structure for hash tables). Object can have a function as its constructor, and if you are clever enough, you can make objects has parent object (even parent constructor). Because object are somewhat hash table, you can’t have really private in the object, everything you have in the object can be see by anything that can get hold of the object, and JavaScript even let you to iterate the property names in the object.

Since everything is an object, the primitives and functions are object too, but the primitives(numbers for example) can’t really perform as a hash table, though you can setting properties to them, they won’t save any of the property at all.

This purity offers JavaScript the simplicity, if you don’t agree, see what a mess Java has become.

2. JavaScript is a prototype based language

JavaScript is not the first one prototype based language, but I think it is the most famous one. The prototype based nature of javascript can be more easily implemented, and still have the good ways of object oriented. I’ll talk about prototype based language in other articles, so I’ll skip this part in this one.

3. JavaScript is a weak typed language

JavaScript do have types, it has Undefined, Null, Boolean, String, Number and Object type, they can convert to each other (except object, because we don’t have to, everything is an object, remember?)

But the variable don’t have types, so that, you can set anything to any variable and JavaScript won’t complain anything.

But JavaScript won’t let you to create your type, and there is nothing can help you to create a thing like type(since JavaScript is prototype based), it seems weird though(especially from java’s world), but it is really easy for JavaScript’s implementations (If we have Classes, then we must need packages and other many more things, if you don’t want have a mess environment).

4. JavaScript is an embed language

JavaScript can do anything the host environment want it do. So, if the host environment don’t provide the fundamental part JavaScript wants, suppose a calculator can run JavaScript, maybe javascript is just an object oriented calculation language on that calculator, it just can calculate the numbers and output the texts.

All the nature for JavaScripts only points to one conclusion:

JavaScript is build to be an embed language, and it focus on the simplicity of the language(and the implementation of the language), so that, the language(or the implementation) can be run at most machines, and can be easily implemented and mantained.

And as the simplicity of JavaScript (language design), for many circumstances, JavaScript can be the fastest scripting language on any platform, and the philosophy of JavaScript makes it a very nice embed language to use.

Yes, JavaScript have its flaws, but not on its philosophy, we’ll talk that later.

So, a final word for the conclusion of this article:

JavaScript an Objected Oriented Prototype Based Weak Type Scripting Language, its aim is to be a scripting language of simplicity to run in the host environment, and it has achieve its design goal.

We’ll talk about JavaScript’s grammar in next article.