Git Product home page Git Product logo

trycatch's Introduction

trycatch

Build Status A domain-based asynchronous try/catch with (optional) long stack traces for node.js optimized for V8.

WARNING: trycatch replaces the built-in global Error object.

Install

npm install trycatch

Use

var trycatch = require('trycatch')
trycatch(function() {
  // do something error-prone
}, function(err) {
  console.log(err.stack);
})

Returning 500s on Server Request

http.createServer(function(req, res) {
  trycatch(function() {
    setTimeout(function() {
      throw new Error('Baloney!');
    }, 1000);
  }, function(err) {
    res.writeHead(500);
    res.end(err.stack);
  });
}).listen(8000);

Visit http://localhost:8000 and get your 500.

Options

Optional Long-Stack-Traces:

// Because trycatch shims all native I/O calls,
// it must be required & configured with 'long-stack-traces' before any other modules.
var trycatch = require('trycatch')
trycatch.configure({'long-stack-traces': true})
trycatch(fnTry, fnCatch)

Colors:

var trycatch = require('trycatch')
trycatch.configure({
  colors: {
    // 'none' or falsy values will omit
    'node': 'none',
    'node_modules': false,
    'default': 'yellow'
  }
})
trycatch(fnTry, fnCatch)

Advanced Formatting:

var trycatch = require('trycatch')
trycatch.configure({
  format: function(line) {
    // Alter final output (falsy values will omit)
    return line
  }
})
trycatch(fnTry, fnCatch)

Basic Example

var trycatch = require("trycatch"),
  _ = require('underscore')._

  trycatch(function() {
  _.map(['Error 1', 'Error 2'], function foo(v) {
    setTimeout(function() {
      throw new Error(v)
    }, 10)
  })
}, function(err) {
  console.log("Async error caught!\n", err.stack);
});

Output

Advanced Examples

See the /test and examples directories for more use cases.

uncaughtApplicationException

trycatch effectively wraps all application callbacks in try/catch blocks, preventing an exception in your application code from causing code in core to not execute. Effectively, this means that exceptions originating in application code that normally would be passed as uncaughtException, can instead be handled via uncaughtApplicationException without requiring a restart:

process.on('uncaughtApplicationException', (err) => console.log(err.stack))

process.on('uncaughtException', (err) => {
  console.log(err.stack)
  // We are in an undefined state and need to restart
  handleSoftShutodwn()
})

trycatch's People

Contributors

bryant1410 avatar crabbot avatar crabdude avatar dvv avatar jeffbski avatar leggiero avatar raynos avatar staeke 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

trycatch's Issues

Error callback does not use the right version of the front-end connection object if the path goes through an event emitter which is set only once (e.g. persistent connections)

I have a code example I am using to test try catch, and I run in weird cases: for example, sometimes it will respond on the first error call properly and print the stack, and then just hand on subsequent call. Sometimes I get the stack, but no HTTP response.

The code I am using leverages MySQL and memcached: from what I can see, libraries which uses network connections seems to be the cause of the problem, but I cannot exactly understand why this would be the case.

Update:

I have changed the name of this problem, as the understanding I have of it now makes it clearer that this is really an architectural problem, and not one related with any library. I am not exactly expecting this to be solved, as this seems to me like an extremely challenging issue, but I am still pushing it forward because solving such problem would be, in my opinion, of great value for both insuring better response time and overall application stability when using this kind of library.

Rework coloring

Coloring needs to be handled differently, because errors are not always sent to stdout/stderr, resulting in coloring noise in logs.

Possibilities:

// opt-in
console.log(err.colorStack);
console.log(trycatch.color(err.stack));

//opt-out
nonTTYLogger.log(err.colorlessStack
nonTTYLogger.log(trycatch.stripColor(err.stack));

// heuristics / pattern-matching on stdout/stderr
process.stdout.write(err.stack); // automatically colorize here

I'm leaning toward overwriting tty.WriteStream.prototype.write() and adding trycatch.colorize() for opt-in in all other cases, with something like trycatch.removeTTYColorize() to restore tty.WriteStream.prototype.write().

trycatch not working with mongojs module

Hi,

I was waiting for a solution like this. It will simply the life of many noders. Thanks to your efforts.

I had tried examples found with this library and it's working like a charm. So I went ahead to use it in my application to throw errors from my database (mongodb) layer. I am using mongojs ( https://github.com/gett/mongojs ) , a simplified wrapper around mongo-native ( https://github.com/christkv/node-mongodb-native ) driver.

While trycatch works very well with mongo-native callbacks, it is unable to catch exceptions thrown by mongojs callbacks.

I would like to bring this case to your attention since I read that trycatch hooks at low-levels node's event source api's and why this particular module is not working as expected ?

You can find my working & non-working code samples in this issue mongo-js/mongojs#10

Configure how to print lines

Sometimes I want to do

trycatch.colors({
    "core": "dont print"
    , "node_modules": "dont print"
    , "other": "white"
    , "test": {
        color: "green"
        , regexp: /test/
    }
})

Which basically means ignore all that node & node_modules noise in those massive stack traces and just show me my code in white. Also for anything that matches /test/ print it in green.

Potential Memory Leak

We've been trying to track down a memory leak which has been killing our prod boxes. Eventually, with the help of the heapdump module, we've been led to believe that it has something to do with either trycatch, or the way we use it. See attached screenshot of profile.

memoryleak

The doCatch function is the closure we pass as the catchFn to trycatch, and onError and onMessageHandled are functions referenced from doCatch.

According to the profile, it seems that these functions can't get cleaned up due to persistent references from inside trycatch, in particular via the _trycatchOnError function. This function in turn creates a reference from the child domain to the parent domain. It does this via

d.on('error', _trycatchOnError)
and
handleException(err, parentDomain, catchFn)
. Seemingly this reference from child to parent gets cascaded and prevents the whole chain from being cleaned up.

To test this theory, I hacked trycatch locally to pass a callback to the tryFn (incidentally the catchFn doesn't need to get invoked to create to the leak). This callback would then remove the listener added at

d.on('error', _trycatchOnError)
which breaks the chain and gets rid of the leak.

I'm not sure whether this is a feasible route to go down though, as handling the error case, where the catchFn actually needs to be called, which itself could fail, would be challenging.

What is also confusing is that we do use trycatch elsewhere and I haven't seemed to notice any leaks there, though that could be due to us using it at much larger scale in this use case, which makes the leaks visible.

Add a general technical explanation of how trycatch is solving error handling

This is both a question and a issue for adding the answer to the documentation. Forgive me if this is an innapropriate place for discussion, but I don't know where else to ask.

The documentation on domains says not to ignore errors caught by a domain, but gracefully restart or shutdown the process after finishing up other requests (in the case of a server). Of the discussions I've seen out there on Node.js error handling, many of them point to this module as a 'solution'. Does trycatch solve this problem completely? Regardless of the answer, could somone add the answer to the docs and any other related technical (but general) information on what trycatch is actually doing to handle errors under it's hood?

not compatible with io.js

node -v && node setTimeout.js
v2.2.1
This is an asynchronous scoped error handler!
 Error: foo
    at [object Object].f (/Users/adrai/Projects/trycatch/examples/setTimeout.js:5:9)
    at Timer.<anonymous> (timers.js:89:15)
/Users/adrai/Projects/trycatch/lib/trycatch.js:245
    throw err
          ^
TypeError: Cannot read property 'length' of undefined
    at _stream_writable.js:352:12
    at _stream_writable.js:342:5
    at node.js:408:9
    at process._tickDomainCallback (node.js:378:13)

any idea why?

Using "process.stdout.isTTY" inside Windows service causes exception.

When node starts from Windows service, accessing property "process.stdout.isTTY" in "lib/formatError.js" causes the following exception "Implement me. Unknown stream file type!".

In my case moving "try ... catch" block outside the block "if (process.stdout.isTTY)" resolved issue:

try {
  if (process.stdout.isTTY) {
    colors = require('colors');
  }
} catch(err) {}

Speed up long stack traces

I am still using this puppy... and I am still an happy customer.

I was looking at the implementation of the long stack traces. It looks like that you do string concatenations for each async stack.

I was wondering... Would not be better to just store a reference to the string and lazy concatenate the strings only when somebody access to the err.stack ? I think you can save a lot of CPU and memory this way.

Add support for node.js version 5.0.0

Hi,
We have used trycatch module with node.js version 0.10.40 and it works fine, recently we had to update the node.js to version 5.0.0 for testing the application on stable version. When we were accessing any of the api, we started getting an error and my server started to shutdown.
The exception that we are getting is listed below
error: error: In UserController : ViewDetails() :: Error is TypeError: Cannot read property 'length' of undefined
/home/user/TestSails/node_modules/trycatch/lib/trycatch.js:222
throw err
^

Doc update

Please update the documentation according to new features like trycatch.config({'long-stack-traces': true}).

Weird usage of event emitters loses errors in mongodb

I'm using trycatch with mongodb. It is not printing long stack traces and only showing a single stack

mongodb re emits errors from one emitter onto another emitter ( https://github.com/mongodb/node-mongodb-native/blob/master/lib/mongodb/connection/base.js#L216 )

I believe it loses the right domain.

Here is a mongodb example that doesnt work with long stack traces

var mongo = require("continuable-mongo")
var Users = mongo("mongodb://localhost:27017/db").collection("users")

trycatch(function () {
    Users.findOne({ email: "fake "}, function (err) {
        throw { "foo": 42 }
    })
}, logError)

function logError(err) {
    console.error("ERROR", err.message)
    console.error(err.stack)
}

This prints

ERROR [object Object]
Error: [object Object]
    at normalizeError (/home/raynos/Documents/colingo-one-on-one/node_modules/trycatch/lib/formatError.js:33:11)
    at formatError (/home/raynos/Documents/colingo-one-on-one/node_modules/trycatch/lib/formatError.js:17:9)
    at Domain.EventEmitter.emit (events.js:95:17)
    at Db.EventEmitter.emit (events.js:70:21)
    at /home/raynos/Documents/colingo-one-on-one/node_modules/continuable-mongo/node_modules/mongodb/lib/mongodb/connection/base.js:217:19
    at process._tickDomainCallback (node.js:459:13)

This is a reproduction of the issue without the mongodb specifics

trycatch(function () {
    setTimeout(function () {
        var EventEmitter = require("events").EventEmitter
        var firstEmitter = new EventEmitter()

        process.nextTick(function () {
            var emitter = new EventEmitter()

            emitter.once("error", function (err) {
                process.nextTick(function () {
                    firstEmitter.emit("error", err)
                })
            })

            emitter.emit("error", { foo: 42 })
        })
    }, 100)
}, logError)

function logError(err) {
    console.error("ERROR", err.message)
    console.error(err.stack)
}

Here is the stack trace (not long)

ERROR [object Object]
Error: [object Object]
    at normalizeError (/home/raynos/Documents/colingo-one-on-one/node_modules/trycatch/lib/formatError.js:33:11)
    at formatError (/home/raynos/Documents/colingo-one-on-one/node_modules/trycatch/lib/formatError.js:17:9)
    at Domain.EventEmitter.emit (events.js:95:17)
    at EventEmitter.emit (events.js:70:21)
    at /home/raynos/Documents/colingo-one-on-one/bin/check-personal-teacher.js:69:34
    at process._tickDomainCallback (node.js:459:13)
raynos at raynos-Latitude-E5530-non-vPro  ~/Documents/colingo-one-on

Is this an issue with trycatch or with mongodb ?

Make long stack traces optional.

Making long stack traces work requires preliminary creation of Error objects.
But creating Error objects is one the most expensive parts of trycatch flow.

A simple benchmark

for (var i = 0; i < 1000000; i++) {
  trycatch(function() {}, function() {});
}

gives 10M iteration/sec with _TOKEN_.error = null
and only 150K/sec with _TOKEN_.error = new Error.

I think that such low level things should be as fast as possible, and therefore long stack traces should be optional in favor of performance.

I would recommend to make a runtime option probably by adding trycatch.enableLST(false) function.
A default value could be also set in ENV as a bonus.

Context issue : Using trycatch within function and calling same function insite it.

Hi CrabDude,

My Code :

var trycatch = require('trycatch');
var fun = function (one, cb) {
    var obj = {
        name: one
    }
    trycatch(function () {
        setTimeout(function () {
            console.log("======", one);
            if (one == "function2") {
                return cb();
            }
            fun("function2", function () {
                if (one == "function1") {
                    throw new Error("Something Went Wrong");
                }
                cb();
            });
        }, 2000)
    }, function (e) {
        console.log("Error >>>>>", obj, e);
    });
}

fun("function1", function () {
    console.log("Success >>>>>");
})

Output :
====== function1
====== function2
Error >>>>> { name: 'function2' } [Error: Something Went Wrong]

My inside function "fun" has been finished but still getting context of it. I want to get context of function in which error occurred.

I want to get output :
====== function1
====== function2
Error >>>>> { name: 'function1' } [Error: Something Went Wrong]

How can I get above output ?

long stack traces only

Is it possible to use try catch only for long stack traces and not have it intercept thrown errors. (I would want thrown errors to continue crashing my process)

300% performance impact

I'm using the long stack traces implementation in trycatch.

My tests run in 5s without trycatch and in 15s with trycatch.

Having a performance penalty of 20-30% is normal, having one thats 300% slower seems crazy.

Is there anything that can be done to optimize this library ?

Stack trace is lost when Error catched inherits from Error base class

Hi
When we use inheritance for error handling, but also for standard error class like ReferenceError etc..., the stack trace is lost.
Its because of function isError in formatError.js
check is made with Object.prototype.toString.call(err) === '[object Error]'
but it should be err instanceof Error;
to take inheritance in account
Thanks

Error installing [email protected] as a non root user

Hi,

I got the following error when installing trycatch:

[jenkins@sf1nimbuild2 mn-node]$ npm install [email protected]
npm WARN [email protected] dependencies field should be hash of <name>:<version-range> pairs
npm WARN [email protected] package.json: bugs['web'] should probably be bugs['url']
npm http GET https://registry.npmjs.org/trycatch/0.0.11
npm http 200 https://registry.npmjs.org/trycatch/0.0.11
npm http GET https://registry.npmjs.org/trycatch/-/trycatch-0.0.11.tgz
npm http 200 https://registry.npmjs.org/trycatch/-/trycatch-0.0.11.tgz

npm ERR! Error: EACCES, permission denied '/tmp/npm-1331808923733/1331808923733-0.5058121806941926/___package.npm/package/examples/helloworld.js'
npm ERR! 
npm ERR! Please try running this command again as root/Administrator.
npm ERR! 
npm ERR! System Linux 2.6.32-220.el6.x86_64
npm ERR! command "node" "/usr/local/bin/npm" "install" "[email protected]"
npm ERR! cwd /home/jenkins/workspace/rms-modules_Development_Build/mn-node
npm ERR! node -v v0.6.8
npm ERR! npm -v 1.1.1
npm ERR! path /tmp/npm-1331808923733/1331808923733-0.5058121806941926/___package.npm/package/examples/helloworld.js
npm ERR! code EACCES
npm ERR! message EACCES, permission denied '/tmp/npm-1331808923733/1331808923733-0.5058121806941926/___package.npm/package/examples/helloworld.js'
npm ERR! errno {}
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /home/jenkins/workspace/rms-modules_Development_Build/mn-node/npm-debug.log
npm not ok

Note that [email protected] installs fine:

[jenkins@sf1nimbuild2 mn-node]$ npm install [email protected]
npm WARN [email protected] dependencies field should be hash of <name>:<version-range> pairs
npm WARN [email protected] package.json: bugs['web'] should probably be bugs['url']
npm http GET https://registry.npmjs.org/trycatch/0.0.9
npm http 200 https://registry.npmjs.org/trycatch/0.0.9
npm http GET https://registry.npmjs.org/trycatch/-/trycatch-0.0.9.tgz
npm http 200 https://registry.npmjs.org/trycatch/-/trycatch-0.0.9.tgz
npm WARN [email protected] package.json: bugs['web'] should probably be bugs['url']
npm http GET https://registry.npmjs.org/colors
npm http 304 https://registry.npmjs.org/colors
npm http GET https://registry.npmjs.org/colors/-/colors-0.5.1.tgz
npm http 200 https://registry.npmjs.org/colors/-/colors-0.5.1.tgz
[email protected] ./node_modules/trycatch 
└── [email protected]

As you can see, this is happening in our continuous build so we can't really workaround it by making jenkins run as root. It would screw up all our build process.

Thanks,

  • Nicolas

trycatch requires node 0.9

package.json says that trycatch requires node 0.8.14, however it appears that nodejs 0.9 is required because "In Node.js versions below 0.9, setImmediate is not available". There is a routine (line 25) of hookit that iterates over ['setTimeout', 'setInterval', 'setImmediate'], replacing these functions. This fails for setImmediate.

y u no use domain?

var domain = require('domain');
require('longjohn');

function trycatch (fn, cb) {
  var d = domain.create();
  d.on('error', cb);
  d.run(fn);
}

Error not catched

Hi, i dont know where to put my message so i'll just write it there.
I've read a lot about your very interesting plugin but i just cant get it work properly.
I threw my exception in the try function, and handle it on the catch callback.The nodejs process just crash.

exports.newTag = function(req,res)
{
  trycatch(function()
  {
    var label = req.body.label;
    if(!label)
    {
      var error = new Error("Veuillez entrer un label pour le tag");
      error.custom = true;
      throw error;
    }
    database.Tag.count({label:label},function(err,count)
    {
      if(err) throw err;
      if(count> 0)
      {
        var error = new Error("Le tag existe déjà, entrez un autre nom");
        error.custom = true;
        throw error;
      }

      var tag = 
      {
        label: label
      };
      tag = new database.Tag(tag);
      tag.save(function(err)
      {
        if(err) throw err;
        return res.json({ok:true,tag:tag});
      });

    })

  },function(err)
  {
    console.error(err.stack);
    if(err.custom)
    {
      return res.json({ok:false,msg:error.message});
    }
    return res.json({ok:false,msg:"Désolé, une erreur est survenue"}); 
  });
 }

Separate guarding functionality into base module

There are 4 parts to trycatch:

  • Fixing callback context (EE handlers at time of listen vs at construction)
  • Guarding core from userland errors and fixing
  • Long-stack-traces
  • Async try/catch

trycatch should be refactored into the separate modules, with trycatch at the top of the abstraction stack.

Perhaps, Error.longStackTraces should be used instead of trycatch.configure.

Add typed catch support

And Error.create for convenience.

Something like...

trycatch(function() {
  ...
}, [EvalError], function(err) {
  // only catch EvalError
})

Add `Promise` API (Bonus: finally support)

An opt-in Promise API is the best avenue for adding finally support.

Likely, the callback API will be deprecated at a point that makes sense and avoids as much inconvenience as possible for the community

re-implement on top of async listener

0.12 async listener will allow implementing long stack traces without monkey patch hacks.

The async-listener shim on npm will give 0.10 support and "hide" all the monkey patch hacks.

Add finally support

For cases when you don't want the domain to leak or nest.

function doAsync(callback) {
  trycatch(function(next) {
    foo('value', next);
  }, callback, callback.bind(null, null));
}

Disable colors for non-tty stdout

If I do output redirection to a file:

node test.js > 1.txt

I get color codes in the file too:

caught!
Error: black box error
^[[31m    at Object.<anonymous> (/home/wicked/trycatch/test.js:3:11)^[[39m
^[[37m    at Timer.ontimeout (timers.js:101:19)^[[39m
        ----------------------------------------
        at setTimeout
^[[31m    at blackBox (/home/wicked/trycatch/test.js:2:3)^[[39m
^[[31m    at Timer.<anonymous> (/home/wicked/trycatch/test.js:11:3)^[[39m
^[[37m    at Timer.ontimeout (timers.js:234:14)^[[39m

Which is not desired.

I think it's better use http://nodejs.org/api/tty.html to determine if stdout supports colors. Also it should be configurable directly of course.

What do the colors mean?

They look random.

Can we use them for something useful like differentiating node core, node_modules and my source code.

CoffeeScript line numbers doesn't match 'trycatch' stack trace

When running CoffeeScript files directly from the code, via require('coffee-script').register(); for example, Stack Traces are generated incorrectly by trycatch module; for example, line number 117 is shown in the trace, but it's really line 84 in the CoffeeScript file.

When running CoffeeScript files without using trycatch module, line numbers are shown correctly in the "normal" Stack Trace generated when an Error is thrown.

I'm not sure how CoffeeScript achieves this "mapping" of Stack Traces when compiling on the fly, so I can't provide much help there (I might try to later).

process.nextTick disrupts the stack

Hi,
When there is a process.nextTick done in the callbacks, the call stack is disrupts and the exception never bubbles ?

Is there a way to get around this and this not exceed the Max call stack size.

Thanks.

How does this work / why is this library not a bigger deal

I have been struggling with disliking asynchrous error handling in nodejs, and you seem to have solved it. It would be really nice if this were adopted at the language level so that try/catch worked as expected.

Passing error as the first argument in every callback is highly undesireable in my opinion as it really messes up the flow of code, and generally makes things messier.

Anyway, just sort of astonished that somebody was able to make this work, I might have to check out your code for a bit.

Cheers

Performance concerns

I haven't tried the module in-depth yet, nor performed serious benchmarks on it, but would this affect a framework if wrapped most of user generated code (controllers, views, routes) even if no exceptions were being thrown?
I know the common sense to avoid common pitfalls, like executing the try/catch inside a loop or recreating it over and over in async calls, but on parts that would expect an exception but most of the time wouldn't, how would it perform?

The trycatch library breaks the latest MongoDB driver

If you use MongoDB driver 1.3.15 (or near this version) then you'll see this error when you try to connect/open connection:
"undefined is not a function"

It looks like MongoDB Driver extends/uses EventEmitter in a non-standard way. From my initial debugging it appears that the listener callback function also comes along with additional properties ("extra" information about the callback). Those additional properties aren't there when MongoDB code looks for them because hookit inserted a proxy listener callback function.

See Base.prototype._callHandler function in base.js of mongodb driver.
It has this line:

var callback = this._callBackStore.listeners(id)[0].listener;

_callBackStore is an EventEmitter instance and the MongoDB code is retrieving the first listener for event of type id and then retrieving the value of the listener property on that callback function. Typically, this code would return the listener callback function:

var callback = this._callBackStore.listeners(id)[0];

The listener property is a little extra property that MongoDB code added to the callback function.

The problem might be solved if you copied all non-inherited properties from the original callback function to the proxy callback function (which unfortunately adds additional overhead every time a listener is added).

trycatch breaks this in EventEmitters

EventEmitter listeners assume that this for the listener is set to be the EventEmitter itself. The newest versions of trycatch no longer evaluate the listener in the correct context, breaking any modules that uses this behavior of EventEmitters when they're used with trycatch.

Enforce hookit version ^1.1.3 instead of 1.x.x

Hello,

When upgrading from trycatch 1.5.11 to 1.5.19, I encountered a setTimeOut bug caused by hookit. I described it here: iriscouch/follow#70

It looks like this bug has been fixed in hookit 1.1.2 or 1.1.3.. Would it be possible, for trycatch 1.5.20, to pull hookit 1.1.3 (instead of any 1.x.x version)?

Thanks

Check if the catchFn is a function

It's probably better to throw an exception if a catchFn argument passed is not a function (at trycatch() call time). Otherwise it can lead to an app crashing later, if an exception from within the tryFn is thrown.

Another option could be just to make exceptions silent in this case, but I think this is not desired behavior.

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.