Giter VIP home page Giter VIP logo

espree's Introduction

npm version npm downloads Build Status Bountysource

Espree

Espree started out as a fork of Esprima v1.2.2, the last stable published released of Esprima before work on ECMAScript 6 began. Espree is now built on top of Acorn, which has a modular architecture that allows extension of core functionality. The goal of Espree is to produce output that is similar to Esprima with a similar API so that it can be used in place of Esprima.

Usage

Install:

npm i espree

To use in an ESM file:

import * as espree from "espree";

const ast = espree.parse(code);

To use in a Common JS file:

const espree = require("espree");

const ast = espree.parse(code);

API

parse()

parse parses the given code and returns a abstract syntax tree (AST). It takes two parameters.

  • code string - the code which needs to be parsed.
  • options (Optional) Object - read more about this here.
import * as espree from "espree";

const ast = espree.parse(code);

Example :

const ast = espree.parse('let foo = "bar"', { ecmaVersion: 6 });
console.log(ast);
Output

Node {
  type: 'Program',
  start: 0,
  end: 15,
  body: [
    Node {
      type: 'VariableDeclaration',
      start: 0,
      end: 15,
      declarations: [Array],
      kind: 'let'
    }
  ],
  sourceType: 'script'
}

tokenize()

tokenize returns the tokens of a given code. It takes two parameters.

  • code string - the code which needs to be parsed.
  • options (Optional) Object - read more about this here.

Even if options is empty or undefined or options.tokens is false, it assigns it to true in order to get the tokens array

Example :

import * as espree from "espree";

const tokens = espree.tokenize('let foo = "bar"', { ecmaVersion: 6 });
console.log(tokens);
Output

Token { type: 'Keyword', value: 'let', start: 0, end: 3 },
Token { type: 'Identifier', value: 'foo', start: 4, end: 7 },
Token { type: 'Punctuator', value: '=', start: 8, end: 9 },
Token { type: 'String', value: '"bar"', start: 10, end: 15 }

version

Returns the current espree version

VisitorKeys

Returns all visitor keys for traversing the AST from eslint-visitor-keys

latestEcmaVersion

Returns the latest ECMAScript supported by espree

supportedEcmaVersions

Returns an array of all supported ECMAScript versions

Options

const options = {
    // attach range information to each node
    range: false,

    // attach line/column location information to each node
    loc: false,

    // create a top-level comments array containing all comments
    comment: false,

    // create a top-level tokens array containing all tokens
    tokens: false,

    // Set to 3, 5 (the default), 6, 7, 8, 9, 10, 11, 12, 13, 14 or 15 to specify the version of ECMAScript syntax you want to use.
    // You can also set to 2015 (same as 6), 2016 (same as 7), 2017 (same as 8), 2018 (same as 9), 2019 (same as 10), 2020 (same as 11), 2021 (same as 12), 2022 (same as 13), 2023 (same as 14) or 2024 (same as 15) to use the year-based naming.
    // You can also set "latest" to use the most recently supported version.
    ecmaVersion: 3,

    allowReserved: true, // only allowed when ecmaVersion is 3

    // specify which type of script you're parsing ("script", "module", or "commonjs")
    sourceType: "script",

    // specify additional language features
    ecmaFeatures: {

        // enable JSX parsing
        jsx: false,

        // enable return in global scope (set to true automatically when sourceType is "commonjs")
        globalReturn: false,

        // enable implied strict mode (if ecmaVersion >= 5)
        impliedStrict: false
    }
}

Esprima Compatibility Going Forward

The primary goal is to produce the exact same AST structure and tokens as Esprima, and that takes precedence over anything else. (The AST structure being the ESTree API with JSX extensions.) Separate from that, Espree may deviate from what Esprima outputs in terms of where and how comments are attached, as well as what additional information is available on AST nodes. That is to say, Espree may add more things to the AST nodes than Esprima does but the overall AST structure produced will be the same.

Espree may also deviate from Esprima in the interface it exposes.

Contributing

Issues and pull requests will be triaged and responded to as quickly as possible. We operate under the ESLint Contributor Guidelines, so please be sure to read them before contributing. If you're not sure where to dig in, check out the issues.

Espree is licensed under a permissive BSD 2-clause license.

Security Policy

We work hard to ensure that Espree is safe for everyone and that security issues are addressed quickly and responsibly. Read the full security policy.

Build Commands

  • npm test - run all tests
  • npm run lint - run all linting

Differences from Espree 2.x

  • The tokenize() method does not use ecmaFeatures. Any string will be tokenized completely based on ECMAScript 6 semantics.
  • Trailing whitespace no longer is counted as part of a node.
  • let and const declarations are no longer parsed by default. You must opt-in by using an ecmaVersion newer than 5 or setting sourceType to module.
  • The esparse and esvalidate binary scripts have been removed.
  • There is no tolerant option. We will investigate adding this back in the future.

Known Incompatibilities

In an effort to help those wanting to transition from other parsers to Espree, the following is a list of noteworthy incompatibilities with other parsers. These are known differences that we do not intend to change.

Esprima 1.2.2

  • Esprima counts trailing whitespace as part of each AST node while Espree does not. In Espree, the end of a node is where the last token occurs.
  • Espree does not parse let and const declarations by default.
  • Error messages returned for parsing errors are different.
  • There are two addition properties on every node and token: start and end. These represent the same data as range and are used internally by Acorn.

Esprima 2.x

  • Esprima 2.x uses a different comment attachment algorithm that results in some comments being added in different places than Espree. The algorithm Espree uses is the same one used in Esprima 1.2.2.

Frequently Asked Questions

Why another parser

ESLint had been relying on Esprima as its parser from the beginning. While that was fine when the JavaScript language was evolving slowly, the pace of development increased dramatically and Esprima had fallen behind. ESLint, like many other tools reliant on Esprima, has been stuck in using new JavaScript language features until Esprima updates, and that caused our users frustration.

We decided the only way for us to move forward was to create our own parser, bringing us inline with JSHint and JSLint, and allowing us to keep implementing new features as we need them. We chose to fork Esprima instead of starting from scratch in order to move as quickly as possible with a compatible API.

With Espree 2.0.0, we are no longer a fork of Esprima but rather a translation layer between Acorn and Esprima syntax. This allows us to put work back into a community-supported parser (Acorn) that is continuing to grow and evolve while maintaining an Esprima-compatible parser for those utilities still built on Esprima.

Have you tried working with Esprima?

Yes. Since the start of ESLint, we've regularly filed bugs and feature requests with Esprima and will continue to do so. However, there are some different philosophies around how the projects work that need to be worked through. The initial goal was to have Espree track Esprima and eventually merge the two back together, but we ultimately decided that building on top of Acorn was a better choice due to Acorn's plugin support.

Why don't you just use Acorn?

Acorn is a great JavaScript parser that produces an AST that is compatible with Esprima. Unfortunately, ESLint relies on more than just the AST to do its job. It relies on Esprima's tokens and comment attachment features to get a complete picture of the source code. We investigated switching to Acorn, but the inconsistencies between Esprima and Acorn created too much work for a project like ESLint.

We are building on top of Acorn, however, so that we can contribute back and help make Acorn even better.

What ECMAScript features do you support?

Espree supports all ECMAScript 2023 features and partially supports ECMAScript 2024 features.

Because ECMAScript 2024 is still under development, we are implementing features as they are finalized. Currently, Espree supports:

See finished-proposals.md to know what features are finalized.

How do you determine which experimental features to support?

In general, we do not support experimental JavaScript features. We may make exceptions from time to time depending on the maturity of the features.

espree's People

Contributors

aladdin-add avatar anikethsaha avatar brettz9 avatar btmills avatar caridy avatar doersino avatar fasttime avatar fisker avatar fredkschott avatar github-actions[bot] avatar hirse avatar kaicataldo avatar kecrily avatar marsup avatar matz3 avatar mdjermanovic avatar mreinstein avatar mysticatea avatar not-an-aardvark avatar nre avatar nzakas avatar okuryu avatar ota-meshi avatar peterkc avatar platinumazure avatar realityking avatar shinnn avatar snitin315 avatar standard8 avatar xjamundx avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

espree's Issues

Lost contributions?

This repository README states: "Espree starts as a fork of Esprima v1.2.2". However, all of history of Esprima up to this point have been conflated into one initial commit. It seems it would be more fair to Esprima contributors to preserve the history.

Add ECMAScript 6 features

This is a rollup that will let us keep track of ES6 progress.

  • let declarations
  • const declarations
  • Regular expression u flag
  • Regular expression y flag
  • Binary literals
  • New octal literals
  • Arrow functions
  • Default parameters
  • Rest parameters
  • Spread operator
  • super references
  • Classes
  • for-of loops
  • Generators
  • Object literal property shorthand
  • Object literal method shorthand
  • Object literal computed properties
  • Template strings
  • Destructuring
  • Unicode code point escapes
  • Allow duplicate object literal properties (except __proto__)
  • Modules

Parser fails on generator methods

Espree parser fails on the following with Unexpected token *:

class Foo {
  *bar() {
  }
}

Test case:

var espree = require("espree");

espree.parse('class Foo {*bar() {}}', {
  "ecmaFeatures": {
    "classes": true,
    "generators": true,
    "objectLiteralShorthandMethods": true,
  },
});

Stack:

node_modules/espree/espree.js:5373
        throw e;
              ^
Error: Line 1: Unexpected token *
    at throwError (node_modules/espree/espree.js:2078:17)
    at throwUnexpected (node_modules/espree/espree.js:2141:5)
    at parseObjectPropertyKey (node_modules/espree/espree.js:2364:5)
    at parseClassBody (node_modules/espree/espree.js:4934:15)
    at parseClassDeclaration (node_modules/espree/espree.js:5023:17)
    at parseSourceElement (node_modules/espree/espree.js:5053:28)
    at parseSourceElements (node_modules/espree/espree.js:5101:25)
    at parseProgram (node_modules/espree/espree.js:5120:12)
    at Object.parse (node_modules/espree/espree.js:5361:19)
    at Object.<anonymous> (esp.js:3:8)

See eslint/eslint#1990.

Features as modules

In the README you say you're going to break the code base down into smaller files in a CommonJS pattern. Would it be possible to make it so that features are not dependent on one another. So say you don't care about parsing comments the comment module doesn't need to get loaded or included.

Thinking about this because I have a library where I want to use Esprima (or any proper code parser) instead of hacky regular expressions but the size of the libraries are just too large. Being able to shrink it down to just what I need could solve my issue.

Error for "missing argument in class setters" fails to format

Using espree master, this code :

espree.parse('class A { set foo(){} }', { ecmaFeatures: { classes: true }});

Throws :

Error: ASSERT: Message reference must be in range
    at assert (/home/ubuntu/workspace/espree.js:78:15)
    at /home/ubuntu/workspace/espree.js:2083:17
    at String.replace (native)
    at throwError (/home/ubuntu/workspace/espree.js:2080:29)
    at throwErrorTolerant (/home/ubuntu/workspace/espree.js:2106:20)
    at tryParseMethodDefinition (/home/ubuntu/workspace/espree.js:2438:17)
    at parseClassBody (/home/ubuntu/workspace/espree.js:4984:22)
    at parseClassDeclaration (/home/ubuntu/workspace/espree.js:5065:17)
    at parseSourceElement (/home/ubuntu/workspace/espree.js:5095:28)
    at parseSourceElements (/home/ubuntu/workspace/espree.js:5143:25)

I think tryParseMethodDefinition L2438 should be throwErrorTolerant(lookahead, Messages.UnexpectedToken, lookahead.value);

super should be allowed in classes by default

Right now, I need to enable classes and superInFunctions in order to use super() in a class. Classes should always be allowed to use super regardless of the superInFunctions flag.

Template string tokens are strange

The way that template string tokens are generated is pretty strange. This code:

var foo = `hi${bar}`;

Is tokenized as:

[
    {
        "type": "Keyword",
        "value": "var"
    },
    {
        "type": "Identifier",
        "value": "foo"
    },
    {
        "type": "Punctuator",
        "value": "="
    },
    {
        "value": "`hi${"
    },
    {
        "type": "Identifier",
        "value": "bar"
    },
    {
        "type": "Punctuator",
        "value": "}"
    },
    {
        "type": "Punctuator",
        "value": ";"
    }
]

So the first part of the template string is represented by a token without a type, and then the rest are just regular tokens, completely losing the end of the template string.

Lines are calculated wrong when relying on ASI

Given the following example:

a()

gives the following loc for the Programm AST node:

"loc": {
    "start": {
        "line": 1,
        "column": 0
    },
    "end": {
        "line": 1,
        "column": 3
    }
}

if you have an extra line break

a()

you get the following loc:

"loc": {
    "start": {
        "line": 1,
        "column": 0
    },
    "end": {
        "line": 2,
        "column": 0
    }
}

Each extra line will increase loc.end.line

a()





"loc": {
    "start": {
        "line": 1,
        "column": 0
    },
    "end": {
        "line": 8,
        "column": 0
    }
}

But if you use a semicolon after the CallExpression you will get a different loc for Program even if you have multiple empty lines:

a();





"loc": {
    "start": {
        "line": 1,
        "column": 0
    },
    "end": {
        "line": 1,
        "column": 4
    }
}

Update module functionality

  • add test to validate that sourceType="module" effectible enables strict mode (e.g.: WithStatement is invalid in modules)
  • ImportDeclaration and ExportDeclaration cannot be used inside functions (missing tests and implementation)
  • Enable classes for export and export default declarations (all TODOs are in the code, very straight forward)

What's up with the `extra` object?

Trying to wrap my head around the extra object, which seems to be used everywhere for everything. Is it just a combination of parsing options & parsing state?

Trailing comments lost with return and debugger statements

I noticed that ReturnStatement nodes doesn’t have leadingComments and trailingComments attached in some cases.

The following code example fails and doen’t have leadingComments or trailingComments:

function a() {
    /* before */
    return;
    /* after */
}

The following code examples work:

Without ReturnStatement:

function a() {
    /* before */
    b();
    /* after */
}

Only one leading comment:

function a() {
    /* before */
    return;
}

Only one trailing comment:

function a() {
    return;
    /* after */
}

Same problem with the debugger statement.

Esprima bug: https://code.google.com/p/esprima/issues/detail?id=609

Update ClassDeclaration/ClassExpression name -> ID

Esprima incorrectly implemented ClassDeclaration and ClassExpression, and since I copied that, we have the same problem. The issue is that ESTree specified the name of a class as id while we are using name. So, we need to switch to use id instead.

Implement JSX syntax

Add support for JSX syntax. This should be done in the same form as esprima-fb.

Add ECMAScript version filter

This feature allows an extra ecmascript option to be passed to the parse() method. This determines the syntax will be accepted by the parser. The default is all syntax (similar to Esprima) and the valid values are currently 5 and 6.

To test, it's easiest to use let and const. Espree already parses them but technically these are not allowed in ECMAScript 5. So when ecmascript is 5, using let and const should throw an error.

Support TryStatement.handler

Ref estree/estree#1:

interface TryStatement <: Statement {
    // ....
    handler: CatchClause | null;
    handlers: [ CatchClause ]; // Removed
    // ....
}

The handlers array on TryStatement nodes was replaced with a single handler, which may be either a CatchClause or null.

Presumably the best way to do this is to port jquery/esprima#1034, a backward-compatible change which adds handler and preserves handlers, then remove handlers as a breaking change later?

Allow return in global scope

For Node.js compatibility, it would be good to add the option to use return in the global scope.

Working on this now.

For loops allow let even with blockBindings is false

Currently, for loops (for, for-in, for-of) all allow let to be used even when blockBindings is set to false. So this works fine:

for (let x of y) {
}

With this config:

{
    blockBindings: false,
    forOf: true
}

This should throw an error instead.

Object literal shorthand generator methods have incorrect range

Perhaps this is intentional, but the range given to object literal shorthand generator methods includes only the method body {}. Since they key is part of the parent property and overlapping, non-ancestral ranges might get confusing, I'm not sure that the FunctionExpression's range should include all of *foo(arg1) {}, but it seems like the range should expand to at least (arg1) {}.

Related: eslint/eslint#1677

//test.js
var inspect = require('util').inspect,
    espree = require('espree');

var source = [
    "({",
    "    *foo(arg1) {}",
    "})"
].join("\n");

var ast = espree.parse(source, {
    range: true,
    tokens: true,
    ecmaFeatures: {
        generators: true,
        objectLiteralShorthandMethods: true
    }
});

console.log(inspect(ast.body[0].expression.properties[0]));
console.log(inspect(ast.body[0].expression.properties[0].value.params[0]));
console.log(inspect(ast.tokens));
$  node test.js
{ type: 'Property',
  key: { type: 'Identifier', name: 'foo', range: [ 8, 11 ] },
  value:
   { type: 'FunctionExpression',
     id: null,
     params: [ [Object] ],
     defaults: [],
     body: { type: 'BlockStatement', body: [], range: [Object] },
     rest: null,
     generator: true,
     expression: false,
     range: [ 18, 20 ] },
  kind: 'init',
  method: true,
  shorthand: false,
  computed: false,
  range: [ 7, 20 ] }
{ type: 'Identifier', name: 'arg1', range: [ 12, 16 ] }
[ { type: 'Punctuator', value: '(', range: [ 0, 1 ] },
  { type: 'Punctuator', value: '{', range: [ 1, 2 ] },
  { type: 'Punctuator', value: '*', range: [ 7, 8 ] },
  { type: 'Identifier', value: 'foo', range: [ 8, 11 ] },
  { type: 'Punctuator', value: '(', range: [ 11, 12 ] },
  { type: 'Identifier', value: 'arg1', range: [ 12, 16 ] },
  { type: 'Punctuator', value: ')', range: [ 16, 17 ] },
  { type: 'Punctuator', value: '{', range: [ 18, 19 ] },
  { type: 'Punctuator', value: '}', range: [ 19, 20 ] },
  { type: 'Punctuator', value: '}', range: [ 21, 22 ] },
  { type: 'Punctuator', value: ')', range: [ 22, 23 ] } ]

Edit: Add arg1 to output.

Remove TryStatement.handlers

Ref estree/estree#1:

interface TryStatement <: Statement {
    // ....
    handler: CatchClause | null;
    handlers: [ CatchClause ]; // Removed
    // ....
}

The handlers array on TryStatement nodes was replaced with a single handler, which may be either a CatchClause or null.
#70 added support for the singular handler property. The next step is to remove handlers. This will be a breaking change.

Support test fixtures for when feature = false does not result in an error

For Unicode code point escapes, the string values are still valid JavaScript regardless of the feature state. But the test runner is hard-coded to check for a thrown error if the features is set to off. Thus, I'm unable to write passing tests for this feature.

A few ideas:

  1. Add an option to *.config.js to skip this second test
  2. Remove the test entirely, since I'm not sure how valuable it is to us (checking that new features aren't backwards compatible).

@nzakas thoughts?

Phase 1

Phase 1 is all about setting up the repository in such a way that it's easier to make changes later on.

  • Split up espree.js into as many small files as possible and place those small files in lib/
  • Change over build system to use ShellJS
  • Convert standalone build scripts into ShellJS
  • Create Mocha tests for small files
  • Upgrade ESLint and change code to match ESLint project styles
  • Create browserify build step for a browser-compatible version of espree.js

create-test / default-params issue

  1. the placeholder for empty defaults array members should possibly be undefined instead of null
  2. create-test-.js improperly changes undefined array members to null.

Recently when working on defaultParams and destructuring I noticed that I was having some mismatches with Esprima on the expected output, especially involving the placeholder when there are not defaults specified for each parameter.

When I use create-test to generate the expected output it seems to show [null, 1] for function(a, b=1){}, but when i actually console.log the output from Esprima, it looks like [undefined, 1].

Here is I think the source of the issue:
screen shot 2015-02-09 at 7 00 23 am

The only thing that makes me unsure is that the single test in esprima also shows null as the placeholder, but I can only assume they're using JSON.stringify in their tests, because Esprima will not generate that output:
https://github.com/jquery/esprima/blob/harmony/test/harmonytest.js#L2612

Let me know if you have any ideas otherwise I'll like manually change the tests to use undefined as part of #51, which changed some of the code around this area and caused me to bump into this issue.

Destructured catch clause doesn't work

Given the following snippet, with ESLint I get an error on the catch line with Unexpected token {

function x({a}) {
  try {
    const {b} = a;
  }
  catch({stack}) {
  }
}

Empty paren in expression throws TypeError

The following example crashes eslint (caused by the last line in the file):

var left, aSize, bSize;

aSize = {
  width: 800,
  height: 600
};

bSize = {
  width: 200,
  height: 100
};

left = (aSize.width/2) - ()

with error

eslint test.js

/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/lib/token-store.js:181
            starts[right.range[0]] + padding
                              ^
TypeError: Cannot read property '0' of undefined
    at EventEmitter.api.getTokensBetween (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/lib/token-store.js:181:31)
    at RuleContext.(anonymous function) [as getTokensBetween] (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/lib/rule-context.js:82:33)
    at isSpaced (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/lib/rules/space-infix-ops.js:21:34)
    at EventEmitter.checkBinary (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/lib/rules/space-infix-ops.js:40:14)
    at EventEmitter.emit (events.js:117:20)
    at Controller.controller.traverse.enter (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/lib/eslint.js:673:25)
    at Controller.__execute (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/node_modules/estraverse/estraverse.js:397:31)
    at Controller.traverse (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/node_modules/estraverse/estraverse.js:495:28)
    at EventEmitter.module.exports.api.verify (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/lib/eslint.js:666:24)
    at processFile (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/lib/cli-engine.js:172:27)

Looks like parentheses in the end of the line left = (aSize.width / 2) - () treated as ArrowParameterPlaceHolder

https://www.dropbox.com/s/0oltkd0vbdo0iew/Screenshot%202015-02-10%2018.51.52.png?dl=0

eslint/eslint#1816
AtomLinter/linter-eslint#28

Website design

We need a website to post Espree documentation and a demo. It would be nice if it had the same visual language as the eslint.org, but I don't think that's 100% necessary.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Switching location tracking

Espree is currently using the old mark() and markEnd() methods to track location (from Esprima 1.2.2). Esprima Harmony has two new methods markerCreate() and markerApply(). Before we can merge over more complex features, we need to switch location tracking to what's in Harmony.

Shorthand property named "get" fails to parse

var espree = require('espree');

espree.parse('var a = {get};', {
    ecmaFeatures: {
        objectLiteralShorthandProperties: true
    }
});

Raises Error: Line 1: Unexpected token }

Rename get to anything else, and it works.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.