Code Monkey home page Code Monkey logo

linkedom's Introduction

webreflection

WebReflection Ltd

linkedom's People

Contributors

alan-agius4 avatar alexeychikk avatar dchester avatar delucis avatar devinellis avatar dt-jean-baptiste-lemee avatar eordano avatar fabiospampinato avatar gingerchris avatar haikyuu avatar havunen avatar iam-medvedev avatar jarusll avatar jordandh avatar kal-aster avatar luwes avatar madlittlemods avatar maheshsundaram avatar marcelreppi avatar matthewp avatar mikemadest avatar omril1 avatar philipp-classen avatar qwelias avatar ra80533 avatar stefan-guggisberg avatar tai2 avatar ttraenkler avatar webreflection avatar xeaone 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

linkedom's Issues

Attributes missing

Hey,

I was porting code like this https://github.com/google/eleventy-high-performance-blog/blob/main/_11ty/apply-csp.js#L54 and this https://github.com/google/eleventy-high-performance-blog/blob/main/_11ty/json-ld.js#L35 and both of those selectors fail. From my debugging it looks like those attributes (csp-hash and type) on script aren't parsed (I logged the outerHTML of the nodes and didn't see the attributes).

Besides that things are working great and the performance is very much appreciated!

Cheers!

Encountered issue with empty document ""

After replacing jsdom with linkedom, i ran into issues where documents being sent into linkedom was throwing errors because some html are blank strings. I had to wrap in try{} and return a default blank document.

Not sure why, but JSDOM handled it somehow. I dont know how, its too late, its gone from my system

What are some possible uses cases?

This seems like an efficient way to represent the DOM. What is an example real life use case that you thinks represents the sweet spot usage for this lib?

parseHTML(htmlStr).defaultView -- returns undefined

Strange. I am currently trying to swap out the JSDOM api I am using for Linkedom. But i am always getting undefined for default view. I even tried running it from console:
parseHTML("<html><body>Hello</body></html>").defaultView

and its still undefined. I don't know if JSDOM is conflicting with it, because it's still being imported in another area of the system.

Is that possible? BTW - I am able to test is from the console because I require it from my Electron app and assign it to the window, so i get access:

In Electron:

var {parseHTML} = require('linkedom');
window.parseHTML=parseHTML;

Empty attributes should be permitted in output

Several advanced HTML use cases, such as attaching data- tags for testing purposes can require empty attribute values to be present, currently empty attributes are entirely removed from the string that Linkedom outputs. Here is a test to illustrate the behaviour:

const {document} = parseHTML('<!DOCTYPE html><html id="html" class="live"><!--&lt;hello&gt;-->&lt;hello&gt;</html>');

document.documentElement.innerHTML = '<div data-amend="">Foo</div>'

// Assertion fails currently (desired behaviour)
assert(document.documentElement.toString(), '<div data-amend="">Foo</div>')

// Assertion passes currently
assert(document.documentElement.toString(), '<div>Foo</div>')

document.documentElement.innerHTML = '<div data-amend>Foo</div>'

// Assertion fails currently (desired behaviour)
assert(document.documentElement.toString(), '<div data-amend="">Foo</div>')

// Assertion passes currently
assert(document.documentElement.toString(), '<div>Foo</div>')

HTML Entities cannot be outputted

For a large variety of use cases it is desirable to have HTML entities in Linkedom output. Currently outputting an element as a string decodes these entities, so for example an &amp; appears as an & and an &nbsp; appears as a (space).

Here's a simple to test to demonstrate desired behaviour:

const {document} = parseHTML('<!DOCTYPE html><html id="html" class="live"><!--&lt;hello&gt;-->&lt;hello&gt;</html>');

document.documentElement.innerHTML = '<div>Foo&nbsp;&nbsp;&nbsp;Bar</div>'

// Assertion fails currently (desired behaviour)
assert(document.documentElement.toString(), '<div>Foo&nbsp;&nbsp;&nbsp;Bar</div>')

// Assertion passes currently
assert(document.documentElement.toString(), '<div>Foo    Bar</div>')

Missing properties in DocumentType

Hello! 👋 When parsing a document, the doctype is missing properties such as publicId and systemId mentioned here: https://developer.mozilla.org/en-US/docs/Web/API/DocumentType#properties

Running the code below using [email protected] produces the following results:

import { parseHTML } from "linkedom";
const { document } = parseHTML('<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html></html>');
console.log(document.doctype.name);     // => 'html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"'
console.log(document.doctype.publicId); // => undefined
console.log(document.doctype.systemId); // => undefined

However, opening this HTML file in the latest stable version of Firefox...

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html></html>

...and running the code below produces the following results:

console.log(document.doctype.name);     // => 'html'
console.log(document.doctype.publicId); // => '-//W3C//DTD HTML 4.01//EN'
console.log(document.doctype.systemId); // => 'http://www.w3.org/TR/html4/strict.dtd'

It looks like DocumentType only contains a name property which is set to the entire doctype string:

https://github.com/WebReflection/linkedom/blob/main/esm/interface/document-type.js#L12
https://github.com/WebReflection/linkedom/blob/main/esm/shared/parse-json.js#L87
https://github.com/WebReflection/linkedom/blob/main/esm/interface/document.js#L144

Many thanks in advance!

node.cloneNode(true) causes corruption of document structure

Thanks for your extremely rapid attention and released fix for #65. Unfortunately the fix which has been issued has made the situation worse in some aspects and for the time being I have to return to release 0.8.0.

The following code which was functional under 0.8.0 now no longer returns any result for the query under 0.9.1

var linkedom = require("linkedom");
var text = "<!DOCTYPE html>\n<html lang=\"en\"><body><div class=\"test-component-include\"></div></body></html>"
var root = linkedom.parseHTML(text).document.cloneNode(true);
var queried = root.querySelectorAll(".test-component-include");
console.log("queried " + queried.length + " elements");

In addition part of the original problem reported under #65 is still present in that the classList member of the div node in the cloned markup is not populated. And className neither, which is probably what is responsible for the query failure.

Uncaught SyntaxError: Octal escape sequences are not allowed in template strings.

I never got this error with JSDOM, i feel it's important to file the bug since I am using Linkedom as a dropin. I went back today to pull in a site into the tool which then uses linkedom to manipulate. It turns out that this HTML previously worked with jsdom, but now breaks in Linkedom, again, no control over the crappy html.

ERROR:
Uncaught SyntaxError: Octal escape sequences are not allowed in template strings.

Clicking on the error took me to the place in the HTML src that i am feeding into Linkedom, and it shows this (chopped snippet for brevity):
footer:before,blockquote small:before{content:"\2014 \A0"}

Thats just a part of inline css in a <style> tag in HEAD

Any idea?

Error: :nth-last-child isn't part of CSS3

I got an error:

Error: :nth-last-child isn't part of CSS3
    at Object.compilePseudoSelector (...\node_modules\css-select\lib\pseudo-selectors\index.js:29:15)
    at Object.compileGeneralSelector (...\node_modules\css-select\lib\general.js:21:39)
    ...

with selector like this

document.querySelectorAll('.t01 > tr:nth-last-child(n+2)')

but isn't the nth-last-child already supported by CSS3?

My environment:

  • linkedom: 0.7.6
  • node: 15.14.0
  • OS: Windows 10 21H1 19043.964

Events are not supported

When using LinkeDOM for testing, I stumbled across this limitation:

input.dispatchEvent(new window.InputEvent("change", { data: "filter" }));

This errors since InputEvent is undefined.

Contributor documentation: Running tests, working in IntelliJ

Hi @WebReflection ,

The how-to-contribute.md suggested creating an issue for further documentation that I think might be useful.

I'm trying to get to grips with the project so I can maybe solve my own problems, let me tell you how I got started and maybe in the process of telling me what I should have done it'll become apparent what to add to the docs.

I want to look at the toString'ing of Element so I found a test file. I couldn't see any sections e.g. like in Jest (it("test thing thing")), I assumed this assert format is a stylistic thing but since I'm fixing one very defined problem for now I didn't want to spend time reading about it just yet. I just commented out the whole of test/html/element.js and added in one test for my issue at the top whilst I tried some things out:

const {document} = parseHTML('<!DOCTYPE html><html id="html" class="live"><!--&lt;hello&gt;-->&lt;hello&gt;</html>');
document.documentElement.innerHTML = '<div>Foo&nbsp;&nbsp;&nbsp;Bar</div>'
assert(document.documentElement.toString(), '<div>Foo&nbsp;&nbsp;&nbsp;Bar</div>')

I usually work in IntelliJ, I tried to run the test from there but it can't make sense of the global.symbolFor stuff:

image

So I went to the CLI and luckily npm run test -- test/html/element.js - a pretty standard syntax seemed to work. It would be great to have test commands documented.

I got a lot of output though, a lot of things that I probably don't need when I'm just iterating on one little test, a big table with these headers: File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s

So it would be great to know how to not get all this stuff in the output whilst I'm focusing on a small task. Of course I'd come back and run a full test suite afterwards. I appreciate it's probably important a lot of the time, but it's quite daunting to a newbie.

My test output is present about halfway through the big chunk of output from this command, so I can work with it for now. It would also be helpful to know how you might add console.log type statements whilst debugging, they don't seem to come out in the test output currently. I'd use the debugger, but IntelliJ has issues as above.

toString on templates doesn't show contents

const { parseHTML } = require("linkedom");
const test = parseHTML(`
<template>
    "hello world"
</template>
`);
const template = test.document.querySelector("template");
console.log(test.document.toString()); // "<template></template>"
console.log(template.toString()); // "<template></template>"

the "hello world doesn't appear, only ""

possible bug? html gets escaped when maybe it shouldn't

quotes get changed to " for example, and this breaks some template languages
(text inside script and style tags don't have this problem thankfully, but text inside template tags do)

const { parseHTML } = require("linkedom");
const test = parseHTML(`
<div>
    "hello world"
</div>
`);
const bla = test.document.querySelector("div");
console.log(bla.innerHTML); // &quot;hello world&quot;

querySelector with :scope failing unexpectedly

Re-using the example from the readme, the following minimal example failed unexpectedly:

const {parseHTML} = require ('linkedom');

const {
 document
  } = parseHTML(`
    <!doctype html>
    <html lang="en">
      <head>
        <title>Hello SSR</title>
      </head>
      <body>
        <form>
          <input name="user">
          <button>
            Submit
          </button>
        </form>
      </body>
    </html>
  `);


const form = document.querySelector('form');
const button = form.querySelector(':scope > button');
console.log(button); // returns null while DOM would return the button

I realize that this might be a bug in css-select but I don't know it well enough to figure things out.

Setting textContent removes attribute from element

Test case

const { parseHTML } = require("linkedom");

const { document } = parseHTML(
  `<script type="application/ld+json">{}</script>`
);

document.querySelector("script").textContent = `{"change": true}`;

console.assert(
  document.toString() ==
    `<!DOCTYPE html><html><script type="application/ld+json">{"change": true}</script></html>`,
  `Should retain type: ${document.toString()}`
);

Thanks!

Clarification on relationship to DOM standards

Thanks for working on and publishing this project. I’d like some clarification on this line of the project README, which states:

  • be close to the current DOM standard, but not too close.

What are this project’s design goals with regard to DOM standards? If LinkeDOM is not aligned with WHATWG standards, where does it diverge? Is there a general rule of thumb or list of differences describing what’s in scope for the project?

Expose the Text constructor

In addition to checking node.nodeType, another way to check if a node is a Text node is:

const isTextNode = node instanceof Text;

But currently parseHTML() does not return the Text constructor, though it returns window, document, HTMLElement etc. This of course isn't specific to Text; for compatibility we might need all the other globals as well.

Would it be better to attach them to window, which is returned from parseHTML() anyway?

window.addEventListener not available when running in node environment

Hello )
Is it expected that window.addEventListener is not available in node env?

Here is my snippet:

const html = `
<!DOCTYPE html>
<html>
<head></head>
<body></body>
</html>
`
const { parseHTML } = require('linkedom')
console.log('linkedom: ', parseHTML(html).window.addEventListener)

const { JSDOM } = require('jsdom')
const dom = new JSDOM(html)
console.log('jsdom: ', dom.window.addEventListener)

running this code with node results into:

linkedom:  undefined
jsdom:  [Function: bound addEventListener]

What I am trying to do is to use linkedom together with jest similarly to how it is used in jest-environment-jsdom https://github.com/facebook/jest/blob/master/packages/jest-environment-jsdom/src/index.ts

window.perfomance object doesn't exist

Hi! I am using this library to run unit tests over a library I work on. Great work.

I realized the window.perfomance object is missing. Do you have plans to add it?

If you do, with the right instructions I could volunteer to include it. I read the code and I believe it should live under interface.

Best, Carlos

querySelectorAll does not filter by it's root node

Repro

const { parseHTML } = require("linkedom");

const { document } = parseHTML(
  `<picture><source></picture><picture><source></picture>`
);

const sources = [
  ...document.querySelector("picture").querySelectorAll("source"),
];

console.assert(sources.length == 1, `Should get the right src ${sources}`);

When update from 0.6.0 to 0.8.0 got perf_hooks error

When I update the version from 0.6.0 to 0.8.0 I got this error

ERROR in ./node_modules/linkedom/cjs/interface/document.js
Module not found: Error: Can't resolve 'perf_hooks' in '/home/giles/Projects/FriendOfAnimal/Frontend/foa-vue/node_modules/linkedom/cjs/interface'
 @ ./node_modules/linkedom/cjs/interface/document.js 2:22-43
 @ ./node_modules/linkedom/cjs/xml/document.js
 @ ./node_modules/linkedom/cjs/dom/parser.js
 @ ./node_modules/babel-loader/lib!./node_modules/vue-loader/lib??vue-loader-options!./src/views/ViewPost.vue?vue&type=script&lang=js&

Low priority: Entity encoding of quotes in attribute values

Hey,

It is pretty common (and this is how JSDOM behaves) for HTML serializers to allow special-casing the single quote ' to not be encoded when using double-quote " as the attribute value delimiter.

While the current behavior works perfectly fine, it does make quote-heavy content like CSPs or SVG-data-URIs very busy to read.

Thanks!

serialize empty attributes for xml

First of all a very big thank you for a wonderful project! I thoroughly enjoy working with it.

I wonder if serialization of empty attributes should not depend on target (xml/html).

Consider console.log((new DOMParser).parseFromString(`<test hello=""></test>`,"text/xml").toString());
vs console.log((new DOMParser).parseFromString(`<test hello=""></test>`,"text/hmtl").toString());

in both cases the output is empty attribute: <test hello></test> which is correct html but not correct xml. Maybe the toString() method of attr.js should be dependant on target html or xml?

For now, i monkey patch with toString("text/xml") in the xml scenario.

Many thanks
Martin

innerHTML produces incorrect result

Calling .innerHTML on an element that includes escaped characters produces incorrect results.

E.g.:

console.log(parseHTML(`<body>
  <div class="comment">
    <pre><code>echo &quot;&lt;table class=&#39;charts-css&#39;&gt;&quot;</code></pre>
  </div>
</body>`).document.documentElement.innerHTML)

produces

<div class="comment">
    <pre><code>echo "<table class='charts-css'>"</code></pre>
</div class="comment">

However, the correct output would leave the input unchanged:

<body><div class="comment">
    <pre><code>echo &quot;&lt;table class=&#39;charts-css&#39;&gt;&quot;</code></pre>
</div></body>

Removing unescape inside the innerHTML getter fixes this, but it's not clear if removing it would break other behaviors?

StyleSheet implementation

Hi, thanks for this library.

Is StyleSheet (HTMLStyleElement.sheet property) available?
It always returns me undefined and I can't find the implementation in the source code.

Move symbols into ... 🥁🥁🥁 ... sykbols.js

It looks like I've been lazy enough to not put symbols in the file they likely belong the most: shared/symbols.js

It's easier to look at that file and check what Symbols are about, so ideally I should:

  • move orphan symbols in the wild in there
  • write at least a comment per each symbol so it's clear what they're used for
  • be sure no conflicting names exist

LinkeDOM seems to be dealing differently with different HTML entitites

This is not an issue for my usage as far as I know, so feel free to close the issue if this is not something useful to "fix".

I'm using v0.9.6 on macOS Big Sur v11.4 with Node.js v16.0.0

When I run this code:

const { parseHTML } = require('linkedom');
const { document } = parseHTML(`<!DOCTYPE html>
<html>
<body>
  <p>&lt;img src=&quot;…&quot; /&gt;</p>
</body>
</html>`);
console.log(document.toString());

I get this result:

<!DOCTYPE html>
<html>
<body>
  <p>&lt;img src="…" /&gt;</p>
</body>
</html>

The &lt; and &gt; are preserved, but not the &quot;.

Entire <style> being removed by linkedom

After replacing jsdom with linkedom, i continued regression testing all the html src that i was previously pulling into this tool. Linkedom i noticed is removing entire blocks of <style> tags, no errors though, its just gone from the DOM after resave it to disk an open.

It's unfortunate, i had to reinstall jsdom, and all the hundreds of HTML src files are being processed again fine. I still have the linkedom commented for a future try again:

/*
var {parseHTML} = require('linkedom');
window.JSDOM = function JSDOM(html) { return parseHTML(html);} //facade to work like jsdom
*/

const jsdom = require("jsdom");
const { JSDOM } = jsdom;
window.JSDOM = JSDOM;

The benefits, design, efficiency and thought that went into linkedom is amazing, but it's a bit off to be a drop-in for jsdom. When dealing with HTML src that we have no control over, jsdom does swallow the errors (like octal syntax errors etc) and never mutates the DOM automatically.

Like the disappearing STYLE tag, no idea why linkedom just removes it, causing the page to be completely unformatted.

Will def come back to try this api out a few months from now, i'll keep a watch.

Could be used with jest as jsdom replacement?

Hey! I came across linkeddom today while googling for "faster jsdom" alternatives.

Specifically I'm looking to speed up our react application's Jest test suite, and wondering if you have any experience / tips doing that with linkedom?

The comment in your blog post "I am already replacing every repository of mine that uses, either for testing or as browser-less dependency DOM env, basicHTML with linkedom" makes it sound like you have, but just naively scanning the linkedom readme, and search for "jest" in this repo, so far I'm not seeing anything obvious. Or is this just really easy to do and I'm missing it?

Thanks!

Performance over native DOM

Not an issue but a question. Is Linkedom faster at navigating the DOM compared to native use of querySelector/DOM.?

CharacterData's `data` should be mutable

Hello there—thanks for this library! I ran into some issues when attempting to use Preact with linkedom, which the Preact team was able to track down to an unhandled edge case with CharacterData.

According to this section of the DOM spec:

Each node inheriting from the CharacterData interface has an associated mutable string called data.

It looks like data isn't mutable at the moment. I think all that needs to be added is a setter below CharacterData's get data().

strange crash when when using template elements

const { parseHTML } = require("linkedom");
const bar = parseHTML(`
<template>
    <div></div>
</template>
<template>

</template>
`);
/node_modules/linkedom/cjs/shared/parse-from-string.js:60
        node = node.appendChild(document.createElement(name));
                    ^

TypeError: Cannot read property 'appendChild' of null

DOM API Parity bug: no side effects on live collections

Hi there! First of all, I wanted to say thank you for building this lib -- looks super useful. I stumbled upon it while trying to replace jsdom because of its 100 dependencies. Please feel free to close this issue if replacing jsdom is not an actual goal of this lib.

I'm trying to combine linkedom with @mozilla/readability. Line 1251 of Readability.js in particular got me into an infinite loop. Rehashing the critical lines, the code looks like this:

while (someElement.childNodes.length) {
  anotherElement.appendChild(someElement.childNodes[0])
}

At first, I was a little confused about this, how can length change... but from the appendChild documentation, it seems like the DOM implementation updates the array of the previous parent's childNodes -- thus the length of the array with children gets reduced over time.

Maybe I should suggest a patch to the maintainers of @mozilla/readability? In any case, I wanted to let you know of this potential incompatibility! Again, thank you for all the awesome.

Missing some dataset features?

Hi Andrea,

I'm trying to migrate images-responsiver from basicHTML to LinkeDOM, and it's really working well overall, but I'm having an issue with dataset usage.

Here's a reduced test case to understand what I thought would work, but doesn't:

const { parseHTML } = require('linkedom');
const { document } = parseHTML(`<!DOCTYPE html>
<html>
<body>
  <img src="test.png" data-responsiver="transform" />
</body>
</html>`);

document.querySelectorAll('img').forEach((image) => {
  console.log('responsiver' in image.dataset);
  console.dir(Object.keys(image.dataset));
  console.log(image.dataset.responsiver);
  delete image.dataset.responsiver;
  console.log(image.dataset.responsiver);
  console.dir(Object.keys(image.dataset));
});

Here's the result on my computer (macOS Big Sur v11.4 with Node.js v16.0.0):

false
[]
transform
null
[]

What I would expect:

true
['responsiver']
transform
undefined
[]

Did I forget to use something to better support dataset, or is it a missing part in LinkeDOM?

Thanks a lot for your help.

Bug?: window.navigator is undefined

First, thanks for your great work on this project.

While using Linkedom for testing a React app, I've come across this error: TypeError: Cannot read property 'userAgent' of undefined

And it comes from window.navigator being undefined.

Here is how it's defined in JSDOM. For the scope of linkedom, and since it's a read only property, I think providing a default value to avoid crashes is enough for a fix.

Try it here https://runkit.com/haikyuu/60259abfa573fe0019c29a12

Docs: JSDOM to Linkedom?

Hi 👋🏻 ,

Linkedom looks like a great project, i've got a project that spends tens of seconds in JSDOM and I'd love to try Linkedom as a replacement. I sense that's it not a drop in replacement, has anyone written a 'migration guide' - or is a conversion instead of a rewrite far more complex than I think it might be?

`src` getter on `img` not working

img.src should yield img.getAttribute('src').

const { parseHTML } = require("linkedom");

const { document } = parseHTML(`<img src="test.gif">`);

const img = document.querySelector("img");

console.assert(
  (document.toString() == img.src) == img.getAttribute("src"),
  `Should have src ${img.src}`
);

Expose top-level toJSON export as alternative to the non-spec .toJSON method

Request

Expose a top-level toJSON method that accepts a linkedom element instance and returns that element's jsdon serialization.

Use-case

When using linkedom in a TypeScript environment, element instances (including the document) don't seem expose a .toJSON() method. An exploration of the code suggests that this might be because the built-in dom typings from TypeScript are being used for these specced interfaces.

To serialize a linkedom element to its jsdon equivalent, the element needs to be cast to something like any before calling .toJSON. While this isn't a huge problem, I think there's an opportunity to expose a mirror to the existing parseJSON top-level method that accepts a linkedom element and simply calls that element's .toJSON() method in a type-friendly way. This would allow us to continue pretending that these elements are the 'real deal'.

Order of attributes reversed

Minimal example:

parseHTML(`<body id="foo" class="bar"></body>`).document.toString())

produces:

<body class="bar" id="foo"></body>

Similarly, the .attributes getter will return them in reversed order as well.

I've tried to fix this, however this causes a significant amount of tests to fail, so I'm not sure the extent to which this is behaviour is intended?

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.