Giter Site home page Giter Site logo

nodejs / node Goto Github PK

View Code? Open in Web Editor NEW
103.0K 2.9K 27.6K 1.04 GB

Node.js JavaScript runtime βœ¨πŸ’πŸš€βœ¨

Home Page: https://nodejs.org

License: Other

JavaScript 62.99% Shell 0.44% C 2.73% Makefile 0.23% C++ 21.67% Python 10.91% R 0.03% Batchfile 0.17% HTML 0.70% Emacs Lisp 0.06% Perl 0.05% Assembly 0.01% TypeScript 0.01%
nodejs javascript node js runtime mit linux macos windows

node's People

Contributors

addaleax avatar aduh95 avatar apapirovski avatar bnoordhuis avatar bridgear avatar cjihrig avatar danbev avatar indutny avatar isaacs avatar jasnell avatar joyeecheung avatar lpinca avatar mhdawson avatar mscdex avatar mylesborins avatar nodejs-github-bot avatar piscisaureus avatar refack avatar richardlau avatar ronag avatar rvagg avatar ry avatar sam-github avatar shigeki avatar targos avatar tjfontaine avatar tniessen avatar trevnorris avatar trott avatar vsemozhetbyt 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  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

node's Issues

Contribution policy addition request

To those here that are obsessive about avoiding merge commits please expand the contribution policy with technical details about how to land patches to (1) avoid merge commits and (2) keep a healthy git log in the process. I find the process kind of infuriating and have messed up the commit log slightly while landing the last few PRs.

The contribution policy is also lacking technical details about how committers should be keeping contributions to a single commit, ammending to insert the requested tags, and other minor details; it's a bit too hand wavy for a project that has built up an rigid set of conventions about how to git.

Installation via curl

Getting started with any app should be as simple as curl https://somepath.to/install.sh | sh

or brew install io.js, etc...

GitHub issue management

I firmly believe it could greatly help the project if we had more people able to actively sort though issues, as well as good labels to sort them with.

Sorting issues with good** labels has helped a lot with managing issues over at express, and I'd like to bring that to core.

Core is, however, much larger, and we'd need more people who can do the sorting imo.
I understand that not everyone may be comfortable with more people with commiter permissions, but the reality is git is distributed and it is easy enough to fix things if anything goes awry. I think people could also be more comfortable with a boarder community "managing" the project in this way.

I propose we use some modified / extended list of express's labels, which can be found here and here. (we have a tool that helps manage them too.)

(** What makes a good issue label? I'm not 100% sure, but I feel most in the example are pretty good.)

p.s. I have bugged GitHub about an issues management repo permissions level for a long time. I'll be writing them a detailed support email shortly.

Tracking / Assuring Compatibility

Since the plan is to provide some level of compatibility to joyent/node, are there plans to track compatibility explicitly? Providing assurance that iojs version "X" is a drop in replacement for nodejs version "Y"? At least until that compatibility explicitly breaks.

The binary and long term compatibility with node

There has been a bit of discussion in #28 about what to name the binary. This probably deserves it's own discussion.

The proposed approach

Is the plan to have the installer install an iojs binary and an alias to node?

presents some additional questions:

  • how do node / iojs live side by side?
  • is it a goal of iojs to be long-term compatible with node?

Working with nvm, nvmw and similar installation managers

This is intended as a placeholder and heads-up.

In the transitional period (while io.js is gaining acceptance, node has a huge install base, and people are sorting out which binary they are going to use), package authors will need to test against both io.js and node. Making io.js easy to install via tools like nvm would ease that.

nvm maintainer @ljharb says this here ( nvm-sh/nvm#590 (comment) )

If the community starts moving in a major way towards any given fork of node, and if that fork provides the same installation methods that node does (binaries and source), then this project should be able to easily support it, and I'd intend to do so.

So that's a good goal.

test-tls-server-verify takes too long, occasionally hits test timeout limit

I'm seeing this mainly on Windows, it's a very long test and even though it works it comes too close to the default timeout (60s). This is going to result in a lot of false negatives for the test suite when running CI.

Can we either explore ways to shorten the test time or split it into multiple subtests or perhaps extend the default timeout length?

Assigning to @indutny

Splitting node in to more projects

I'm going to coalesce as much as I can remember of dozens of conversations I've had with people over the last year in to an actual proposal.

For some time node has been getting separated in to difference projects which then become dependencies of node itself in some way. These range from libuv to readable-stream (which is just stream in core).

How and when a module gets broken out in to its own project has been seemingly random, although a more accurate description might be "whenever the opportunity arrived," like a module rewrite.

A specific "version of node" must be a static collection of these dependencies, as has been the case for the history of node, suggesting that we change this would be crazy. Below I will describe this proposal as a collection of projects (some existing and some yet to be produced) which would be locked to a specific version of each project in order to produce a single version of node.

  • v8
  • libuv
  • http-parser
  • libuv.js -- libuv bindings to v8
  • require -- the module system
  • stdlib.js -- every JS module you can require() without installing as a dependency
    • within stdlib.js a specific released version would also have, as dependencies, many other modules like readable-stream
  • npm
  • node-bin -- node's command line interface

Note that there is no abstract C/C++ interface on top of v8's API. Native modules would still be built using a combination of nan (which has the advantage of being able to stretch multiple v8/node version combinations) and direct v8 bindings, as is the case today.

The biggest benefits I see with this approach are reuse and ease of contributions. I think we would see some very interesting experiments with libuv.js. I also think that the community in userland that has had a hard time getting input in to node core would have an easier time directing that feedback towards a stdlib.js or require project which is entirely JS.

Concerns with this approach

  • Additional coordination cost between dependencies.
    • How well is this handled today with libuv?
  • Additional administrative overhead, maybe.
  • Increased difficulty of making performance related improvements traversing several dependencies.

Proposal: Move isaacs/readable-stream to iojs and make it the authoratative source

#53 and all of the other obscure streams issues that keep coming up keep on giving me headaches. Even though I "maintain" readable-stream as an extraction of joyent/node streams I still don't have a complete handle on the inner workings of the streams code and I imagine this is the same for many core contributors. I'm willing to bet that even now, nobody understands the code better than @isaacs because it's grown so complex.

As the most obvious source of JavaScript complexity in core, I propose that we move readable-stream to iojs and make it the place to file streams issues and where the code in core is extraced from rather than the other way around. It can also have its own core team, separate but potentially overlapping with iojs TC, that cares about and understands how they work and maybe the tight integration with core can be loosened (and perhaps broken completely) over time. As a separate project we can also pursue better testing (including browserify) of the code.

logo ideas

Let's all make some logos!

I'll go first:

iojs

svg file

license: public domain / CC0

Some other ideas:

  • IO the moon of Jupiter
  • network/disk/RAM/CPU
  • octogons for the 8 in v8

Initial Release

In the TC meeting today we came up with a vision for the first release.

First, a few assumptions we've internalized that probably need to be stated for this to make sense.

  • Node is pretty damn stable already. There are huge companies with it in production, 100K+ modules, etc. It is already far more stable that its pre-1.0 release tag suggests.
  • Releasing more frequently leads to a more stable product, not a less stable product.
  • The entire ecosystem uses semver while node uses a confusing even/odd release structure.

If people disagree with any of those assumptions then they certainly won't agree with anything the TC determined for the initial release.

So, first release of io.js:

  • January 13th (Fedor's Birthday!) target date.
  • Will be 1.0-alpha1, with alpha releases continuing until 1.0.0.
  • Switching to semver.
  • We will be taking new v8 releases as fast as possible moving forward.
  • Trying to get to a weekly release cycle. Which version number is incremented each week is determined by the changes and whether or not they are breaking. Again, following semver.

Some questions still left open:

  • Are there any changes other than dep upgrades and fixes required for 1.0?
  • Is build confident we can have enough automation in place to hit this date.
  • Is the plan to have the installer install an iojs binary and an alias to node?

Consistent sync and async function names

Specifically all synchronous functions should be *Sync and all other functions should be async. Mixed usage would be deprecated, but not removed for backwards compatibility.

For example, we should deprecate crypto functions like crypto.randomBytes(length) in favor of crypto.randomBytesSync(length).

There is no request for additional functionality. PR welcomed?

Reference: nodejs/node-v0.x-archive#7030

Add `find` method to require

Actually it's very strange behaviour of require.resolve, which throws an error when package not found. Add require.find method which would return null if package not found.

The README is oriented towards Node

Although it is a reasonably small file, the project's readme is the central core of all the project's documentation, but it still uses documentation from Node.js. Some examples:

image 1
image 2

I'd suggest that a change is made to the readme so that it has more of a belonging to iojs, even if 'proper' documentation hasn't been written yet.

V8 upgrades and what they mean for versioning

In the Initial Release issue @indutny says that the API shielding the users from V8 C++ API has been rejected. This lack of a shield + @mikeal's start of that thread here where it is stated that V8 will be merged as fast as possible when V8 releases brings up a very concrete problem.

The choices come down to the following if a shield is not developed for users to use. When V8 releases backwards incompatible changes to their C++ API:

  1. iojs will have to increment its major as V8 is considered a blessed part of the API and iojs is hard conforming to semver.
  2. iojs releases backwards incompatible API changes in minor/patch versions because V8 is not considered part of the blessed API.

Both of which have major consequences on the community who is trying to use iojs as a platform to build things on top of. The last solution, and one that makes even more sense in the world of faster releases and semver, is to protect the users and provide a stable API they can build against. The V8 API can still be there, but now there is a safe way for developers to write binary packages.

I understand that rvagg/nan exists and is even blessed. And perhaps that is the solution that core developers are alright with accepting and consider the V8 API not part of the API that iojs presents for its users. But that decision should be made official and communicated to the community that they are playing with fire if they touch the V8 API directly.

npm install is unbelievably slow, fails in certain environments

tl;dr something is up with npm and https.

I'm attempting to compose an iojs heroku buildpack :) but I'm encountering some interesting behavior.

  1. On my local machine:
    I've built iojs and then, using the bundled version of npm, attempt to install an arbitrary module -- request. It takes a very very long time (minutes!) but it completes.
  2. On a Heroku dyno:
    Ditto the above, but after a very long time, I get the following error(s)
155 info retry will retry, error on last attempt: Error: Hostname/IP doesn't match certificate's altnames: "Host: registry.npmjs.org. is not in the cert's altnames: DNS:npmjs.orgDNS:registry.npmjs.orgDNS:www.npmjs.org"

It gets more interesting. I've done the following, /iojs/bin/npm config set registry http://registry.npmjs.org/ and then npm install completes very quickly -- both locally and on Heroku. I've then explicitly set the registry to https on Heroku and ran npm install again -- no errors about Hostname/IP mismatch this time, but it takes a very long time for the installation command to complete.

Any insight or suggestions appreciated!

Multiple persistent child-process-related test failures on Windows when running as a Service

This sucks because I want to run the Jenkins client as a service but when I do I get 4 persistent failures:

=== release test-child-process-double-pipe ===
Path: simple/test-child-process-double-pipe
grep stdin write 18
echo exit
grep stdin write 7
Command: c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\Release\node.exe c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\test\simple\test-child-process-double-pipe.js
--- TIMEOUT ---
=== release test-child-process-exit-code ===
Path: simple/test-child-process-exit-code
Command: c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\Release\node.exe c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\test\simple\test-child-process-exit-code.js
--- TIMEOUT ---
=== release test-child-process-spawnsync ===
Path: simple/test-child-process-spawnsync
sleep started
sleep exited [ 50, 509779200 ]
assert.js:100
  throw new assert.AssertionError({
        ^
AssertionError: sleep should not take longer or less than 1 second
    at Object.<anonymous> (c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\test\simple\test-child-process-spawnsync.js:44:8)
    at Module._compile (module.js:462:26)
    at Object.Module._extensions..js (module.js:480:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:503:10)
    at startup (node.js:135:16)
    at node.js:866:3
Command: c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\Release\node.exe c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\test\simple\test-child-process-spawnsync.js
=== release test-child-process-spawnsync-input ===
Path: simple/test-child-process-spawnsync-input
Command: c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\Release\node.exe c:\workspace\iojs+v0.12+multi\nodes\node-forward-rackspace-iad-win2012r2-msvs2013\test\simple\test-child-process-spawnsync-input.js
--- TIMEOUT ---

Compare Jenkins running as a service to running manually from cmd.

I'm using nssm with fairly standard options, running Jenkins from a 1-line .bat file and redirecting stdout and stderr to files.

Anybody have any clues about this? The only service-related problems I'm aware of are obvious ones like permissions problems. The test-child-process-spawnsync failure is particularly interesting. The sleep 1 appears to be taking 50 seconds (look at builds 47 and 48 and you'll see the same number!)--what's the significance of 50 seconds? A longer-than-expected execution might explain all of these errors but it's still not acceptable since running Node from a service on Windows is fairly common for production deployments.

[streams] _flush not being called

In the following testcase the _flush callback is not being called after stream.end().

Simply removing the stream.write(null); line works fine.

Is it possible to end a stream with stream.write(null) and stream.end() or only the latter.

If so, why does stream.write(null) prevent stream.end() from triggering _flush?

var Transform = require('readable-stream/transform'),
    inherits  = require('util').inherits;

function MyTransform(opts){
  Transform.call(this, opts);
}

inherits(MyTransform, Transform);

MyTransform.prototype._transform = function( chunk, enc, next ){
  console.log('.');
  next();
};

MyTransform.prototype._flush = function(){
  console.log('END');
};

// ---

var stream = new MyTransform({ objectMode: true });

stream.write({ a: 'b' });
stream.write(null);
stream.end();

same behaviour on v0.11.14 and v0.10.33

ref: #89

openssl-cli.exe child process stdin problem on Windows

Three tests are failing on Windows now, perhaps this is related to the openssl upgrade or perhaps something that's changed in libuv, I don't have good enough data to say yet. My guess is openssl because of the recent upgrade.

  • test-https-foafssl
  • test-tls-securepair-server
  • test-tls-server-verify

Each of these uses openssl-cli.exe s_client ... via a spawn() and then interacts with stdin to do some funky stuff with a local server and verifies stdout. It's as if stdin isn't being properly flushed to the client.

This is the basic pattern, extracted from test-https-foafssl:

  var args = ['s_client',
              '-quiet',
              '-connect', '127.0.0.1:' + common.PORT,
              '-cert', join(common.fixturesDir, 'foafssl.crt'),
              '-key', join(common.fixturesDir, 'foafssl.key')];

  var client = spawn(common.opensslCli, args)

  client.stdout.on('data', function(data) {
    // .. verify and clean up
  });

  client.stdin.write('GET /\n\n');

It just hangs and the tests end up timing out. When you do an 'inherit' for stderr on the spawn you can see that it initializes but doesn't react to the client.stdin.write() at all.

Then, if you do a full 'inherit' and skip the rest of the steps and take control of it:

  var args = ['s_client',
              '-quiet',
              '-connect', '127.0.0.1:' + common.PORT,
              '-cert', join(common.fixturesDir, 'foafssl.crt'),
              '-key', join(common.fixturesDir, 'foafssl.key')];

  var client = spawn(common.opensslCli, args, { stdio: 'inherit' })
  return

And manually type in GET /\n\n to the console it does what it's supposed to; connecting to the local server and printing out the response.

I've tried putting a timeout on the write, I've tried using full CRLF, nothing works and I don't know why taking the parent process stdin should be any different than simulating stdin data.

Anyone?

Proposal: Comment all the code

Something that might have popped up several times before. But it would be awesome to have all source code properly commented. Why are certain code decisions made and why not. This could benefit contribution and perhaps some minor issues that popped up in the past. Question is, is their broad support for this? What comment style should be used? Should code be stripped from comments before release to save space? Etc.

Failed assert in AsyncWrap::MakeCallback(uint32_t, int, Handle) from test-timers-unref.js on ARM

Only seen on ARMv7 and goes away when you comment out this line (which does t.unref.bind(t)).

node: ../src/async-wrap-inl.h:245: v8::Handle<v8::Value> node::AsyncWrap::MakeCallback(uint32_t, int, v8::Handle<v8::Value>*): Assertion `cb->IsFunction()' failed.

https://jenkins-node-forward.nodesource.com/job/iojs+v0.12+multi/nodes=node-forward-nodesource-armv7-ubuntu1404/13/console

Could this be a libuv thing perhaps?

ARMv7 machine now hooked up to the CI cluster and will run with the rest of them.

Confirmation around contributing

Hi guys,

Just want to confirm the status of contributions as all docs still link to the joyent contribution guidelines.

I have already jumped through those hoops but moving forward, and for others that have not, should they?

@rvagg mentioned in #3 that things are still being finalised and to expect more information this week.

Should we hold off committing to this repo till things are finalised or go forth and pull request?

ENOTFOUND and ECONNRESET errors

I will switch to anything that gives me better debug info when these two errors happen. Please just put the domain or IP or something in the message :)

Community contrib direction

Hey guys!

So I saw the TC meeting with the goal of Jan 13th for the alpha release, and am super excited to be seeing movement with this! I was wondering what I could do, as a member of the community, to help assist with hitting that goal?

I'm a full-time node dev, with no experience in C nor C++, but could possibly help with documentation or something along those lines? With this fork officially occurring, I want to do everything in my power to make sure it takes off like it should. Fishrock123, Domenic and chrisdickinson on #io.js and #node-forward irc channels directed me to nodebug.me for triaging issues on node core, but also to open an issue here to see from you guys what can be done to assist.

Thanks for all you're doing!
Trent

EDIT: Updated in light of #28

Proposal: return Promises as well as taking callbacks.

Here is a proposal for gradually moving node.js toward the ES6 future: all async methods in the node standard library which currently take a callback and return no value would instead be extended to return a Promise which can be used instead of the callback. (The callback would become optional, if it is not already. If you are really worried about performance for legacy code, you can return the Promise only if no callback is supplied by the caller.)

This would eliminate the need for extensive promisify calls in code using ES6 Promises (or ES7 async functions), and provide an API like that enabled by the nodify functions in bluebird and prfun.

Feature Request: Every async function returns Promise

Now in node we have callback or EventEmitter model to deal with async calls by default. But in my opinion it is better if every async function returns a native Promise (from new version of V8).
It does not break backward compatibility and supports optional callback if needed.

If so we just do not need to install additional package for promises like q or bluebird except additional functionality is needed.


_EDIT 2014-12-11 by @rvagg_

Comment lifted from here so it's easier to see for newcomers to this conversation.

This was discussed at the TC meeting yesterday, see #144, the aim was to be able to provide at least some kind of statement as feedback in this issue. I don't think the issue needs to be closed and can continue to collect discussion from those who feel strongly about this topic.

The feedback from the TC about incorporating a Promises-based API in core goes something like this:

A Promises API doesn’t make sense for core right now because it's too early in the evolution of V8-based promises and their relationship to other ES* features. There is very little interest within the TC in exploring this in core in the short-term.

However, the TC is open to change as the feature specifications and implementations in ES6 and ES7 are worked out. The TC is open to experimentation and providing the most optimal API for users, which may potentially include a Promises-based API, particularly if newer features of JavaScript work most optimally in conjunction with Promises. The speed of the language specification process and V8 implementation will mostly dictate the timeline.

It should be noted that a callback API is unlikely to ever go away.


Proposal: Introduce CI builds to GitHub PR process

We should be introducing CI builds to the GitHub PR process to verify code integrity, tests and coverage for those contributing to the codebase.

There are plenty out there, Travis-CI, Drone, Hosted Jenkins.

Thoughts?

Add `major`, `minor`, and `patch` labels to PRs, Issues

I think it would be nice to be able to label (and filter) PRs & issues, and to have some insight before even reviewing changes as to how they impact SemVer. There are a lot of issues and PRs that have already been submitted and there's little context to them on real or potential impact to SemVer.

I opened this in part to help to understand impact of an issue, say #66, which I assume to be major at such time as they're actually removed.

Gitter chat room?

To make the project more welcoming I think it'd make sense to have a gitter chat room and a badge in the README. Thoughts?

Good but stagnant PRs from joyent/node

Through my attempt to contribute to Node.js that resulted in practically no attention, I realized that there are a lot of unknown but good pull requests waiting on the Node.js repository, some of them sizzling for over a year. I understand that some pull requests fly under the radar or get abandoned, but I'd estimate at least half of Node.js's 240 are stagnant.

I would suggest we look for some way to implement some of these good pull requests, but I'm not exactly sure how to approach this.

Here are some searches that reveal pull requests that may never be dealt with:

Nominating Chris Dickinson to the TC

Chris has provided some of the best comments on recent issues and has been a pretty active contributor for a while. He's also just a great guy and everyone likes him :)

simple/test-crypto-stream broken after openssl upgrade

=== release test-crypto-stream ===
Path: simple/test-crypto-stream
assert.js:100
  throw new assert.AssertionError({
        ^
AssertionError: false == true
    at Decipheriv.end (/opt/node/test/simple/test-crypto-stream.js:74:5)
    at Decipheriv.<anonymous> (/opt/node/test/common.js:241:15)
    at Decipheriv.emit (events.js:131:20)
    at done (_stream_transform.js:192:19)
    at _stream_transform.js:133:9
    at Decipheriv.Cipher._flush (crypto.js:180:5)
    at Decipheriv.<anonymous> (_stream_transform.js:132:12)
    at Decipheriv.g (events.js:201:16)
    at Decipheriv.emit (events.js:106:17)
    at prefinish (_stream_writable.js:448:12)
Command: out/Release/node /opt/node/test/simple/test-crypto-stream.js

consistent across all platforms I believe. Assigning to @indutny

Better embedded system support

I'd love to see better support for embedded/resource constrained systems in terms of a minimal core, dealing with the garbage leave in NPMs (I removed a 20MB profile trace from a popular NPM the other day), and paying attention to those of us trying to run node^d^d^d^d io.js on systems with as little as 64MB of RAM and 400Mhz MIPS CPUs (think Arduino Yun).

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.