Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
29
datasets available to search
ShareScore release 0.7.1
Dataset results
29 results for “javascript”
JavaScript Libraries From Top 1 Million Sites
<p>Scraped data from top 1 million domains as reported by Majestic 1 Million on June 5th, 2022. The homepage of each domain is scraped and all encountered javascript script source URLs are extracted.</p> <p>You can find the source code at <a href="https://github.com/get-set-fetch/scraper/tree/main/datasets">github.com/get-set-fetch/scraper</a> and detailed documentation at <a href="https://getsetfetch.org">getsetfetch.org</a>.</p>
115th U.S. Congress Member Website (Full JavaScript-enabled Scrape) Collection
<p>This data set represents a point-in-time full JavaScript-enabled scrape of all available 115th U.S. Congress member web sites. The data collection originated and completed on 2018-04-13 and the results are in ndjson/jsonlines/streaming JSON format. File format information is in the enclosed README.md file.</p> <p>The data was used to evaluate the privacy profiles of each U.S. Congress members' official (.gov hosted) websites for the discussion in <https://rud.is/b/2018/04/13/does-congress-really-care-about-your-privacy/>.</p> <p>ScrapingHub's "Splash" platform (<https://github.com/scrapinghub/splash>) was used along with the "splashr" R package (<https://github.com/hrbrmstr/splashr>) to retrieve the content.</p>
Developer Expertise Dataset on JavaScript Libraries
<p>This dataset contains an anonymized list of surveyed developers who provided their expertise level on three popular JavaScript libraries:</p> <ol> <li><a href="https://github.com/facebook/react">ReactJS</a>, a library for building enriched web interfaces </li> <li><a href="https://github.com/mongodb/node-mongodb-native">MongoDB</a>, a driver for accessing MongoDB databased </li> <li><a href="https://github.com/socketio/socket.io">Socket.IO</a>, a library for realtime communication </li> </ol>
Enhanced Bug Prediction in JavaScript Programs with Hybrid Call-Graph Based Invocation Metrics (Training Dataset)
<p>This dataset consists of multiple files which contain bug prediction training data.</p> <p>The entries in the dataset are JavaScript functions either being buggy or non-buggy. Bug related information was obtained from the project EsLint contained in BugsJS (https://github.com/BugsJS/eslint). The buggy instances were collected throughout the lifetime of the project, however we added non-buggy entries from the latest version which is tagged as fix (entries which were previously included as buggy were not included as non-buggy later on).</p> <p>The dataset is based on hybrid call graphs which are constructed by https://github.com/sed-szeged/hcg-js-framework. The result of this tool is a call graph where the edges are associated with a confidence level which shows how likely the given edge is a valid call edge.</p> <p>We used different threshold values from which we considered the edges to be valid. The following threshold values were used:</p> <ul> <li>0.00</li> <li>0.05</li> <li>0.20</li> <li>0.30</li> </ul> <p>The prefix in the dataset file names are coming from the used threshold. The the datasets include coupling metrics NII (Nubmer of Incoming Invocations) and NOI (Number of Outgoing Invocations) which were calculated by a static source code analyzer called SourceMeter. Hybrid counterparts of these metrics (HNII and HNOI) are based on the given threshold values.</p> <p>There are four variants for all of these datasets:</p> <ul> <li>Both static (NII, NOi) and hybrid (HNII, HNOI) coupling metrics are included with additional static source code metrics and information about the entries (file without any postfix). Column contained only in this dataset are: <ul> <li>ID</li> <li>Name</li> <li>Longname</li> <li>Parent ID</li> <li>Component ID</li> <li>Path</li> <li>Line</li> <li>Column</li> <li>EndLine</li> <li>EndColumn</li> </ul> </li> <li>Both static (NII, NOi) and hybrid (HNII, HNOI) coupling metrics are included with additional static source code metrics (file with '_h+s' postfix)</li> <li>Only static (NII, NOI) coupling metrics are included with additional static source code metrics (file with '_s' postfix)</li> <li>Only hybrid (HNII, HNOI) coupling metrics are included with additional static source code metrics (file with '_h' postfix)</li> </ul> <p>Static source code metrics which are contained in all dataset are the following:</p> <ul> <li>McCC - McCabe Cyclomatic Complexity</li> <li>NL - Nesting Level</li> <li>NLE - Nesting Level Else If</li> <li>CD - Comment Density</li> <li>CLOC - Comment Lines of Code</li> <li>DLOC - Documentation Lines of Code</li> <li>TCD - Total Comment Density (Comment Lines in an emedded function will be also considered)</li> <li>TCLOC - Total Comment Lines of Code (Comment Lines in an emedded function will be also considered)</li> <li>LLOC - Logical Lines of Code (Comment and empty lines not counted)</li> <li>LOC - Lines of Code (Comment and empty lines are counted)</li> <li>NOS - Number of Statements</li> <li>NUMPAR - Number of Parameters</li> <li>TLLOC - Logical Lines of Code (Lines in embedded functions are also counted)</li> <li>TLOC - Lines of Code (Lines in embedded functions are also counted)</li> <li>TNOS - Total Number of Statements (Statements in embedded functions are also counted)</li> </ul>
Evaluation of JavaScript Instrumentation by OpenTelemetry visualized in ExplorViz
<p>This dataset represents the results of a survey done with a small group, consisting mostly of experts in the research tool ExplorViz. The survey focused on evaluating whether the data that stem from automatic instrumentation by OpenTelemetry of JavaScript applications does benefit software comprehension. </p>
Mining Rule Violations in JavaScript Code Snippets
<p><strong>Content of this repository</strong><br> This is the repository that contains the scripts and dataset for the MSR 2019 mining challenge</p> <p>Github Repository with the software used : <a href="https://github.com/urielfcampos/linting-js-codesnippets">here</a>.<br> =======</p> <p><strong>DATASET</strong><br> The dataset was retrived utilizing google bigquery and dumped to a csv<br> file for further processing, this original file with no treatment is called jsanswers.csv, here we can find the following information :<br> 1. The Id of the question (PostId)<br> 2. The Content (in this case the code block)<br> 3. the lenght of the code block<br> 4. the line count of the code block<br> 5. The score of the post<br> 6. The title</p> <p>A quick look at this files, one can notice that a postID can have multiple rows related to it, that's how multiple codeblocks are saved in the database.</p> <p><strong>Filtered Dataset:</strong></p> <p><strong>Extracting code from CSV</strong><br> We used a python script called "ExtractCodeFromCSV.py" to extract the code from the original csv and merge all the codeblocks in their respective javascript file with the postID as name, this resulted in 336 thousand files.</p> <p><strong>Running ESlint</strong><br> Due to the single threaded nature of ESlint, we needed to create a script to run ESlint because it took a huge toll on the machine to run it on 336 thousand files, this script is named "ESlintRunnerScript.py", it splits the files in 20 evenly distributed parts and runs 20 processes of esLinter to generate the reports, as such it generates 20 json files.</p> <p><strong>Number of Violations per Rule</strong><br> This information was extracted using the script named "parser.py", it generated the file named "NumberofViolationsPerRule.csv" which contains the number of violations per rule used in the linter configuration in the dataset.</p> <p><strong>Number of violations per Category</strong><br> As a way to make relevant statistics of the dataset, we generated the number of violations per rule category as defined in the eslinter website, this information was extracted using the same "parser.py" script.</p> <p><strong>Individual Reports</strong><br> This information was extracted from the json reports, it's a csv file with PostID and violations per rule.</p> <p><strong>Rules</strong><br> The file Rules with categories contains all the rules used and their categories.</p> <p> </p>
Community Docker Hub images and the third-party (JavaScript, Python and Ruby) packages installed in them
<p>This dataset comes with the replication package provided for a study that we carried out on third-party JavaScript, Python and Ruby packages installed in DockerHub images.</p> <p>The replication package can be found in: <a href="https://github.com/neglectos/3dPartyPackages_Docker">https://github.com/neglectos/3dPartyPackages_Docker</a>/</p>
Call Graphs for Javascript IDEs
<p>The authors have run their algorithms on ten real-world subject programs and measured their performance. The programs include medium to large browser-based JavaScript applications covering a number of different domains, including games (beslimed,pacman,pong), visualizations (3dmodel,coolclock), editors (htmledit,mark-itup), a presentation library (flotr), a calendar app (fullcalen-dar), and a PDF viewer (pdfjs).</p>
JavaScript and html Validity Errors
<p>This data is captured by tool ‘Artemis’, which is a test generation tool for javascript based web applications. The data contained here has benchmarks and html validity errors found out by Artemis tool, when ran against live applications. This data can be used to analyse the html coding errors committed by the programmers and see how we can prevent these errors.</p>
Outliers and Missing Gait_Human, IDS, JavaScript vulnerability Datasets
<p>Human Gait Dataset (CASIA-A) [1] is available at: http://www.cbsr.ia.ac.cn/english/Gait\%20Databases.asp, JavaScript vulnerability<br>dataset is publicly available at [2] and KDD CUP 99 dataset is publicly available at [3].</p> <p> </p> <p> </p> <p>[1] Wang L, Tan T, Ning H, Hu W. Silhouette analysis-based gait recognition for<br>human identification. IEEE transactions on pattern analysis and machine<br>intelligence. 2003;25(12):1505–1518</p> <p>[2] Ferenc R, Heged ̋us P, Gyimesi P, Antal G, B ́an D, Gyim ́othy T. Challenging<br>machine learning algorithms in predicting vulnerable javascript functions. In:<br>2019 IEEE/ACM 7th International Workshop on Realizing Artificial Intelligence<br>Synergies in Software Engineering (RAISE). IEEE; 2019. p. 8–14.</p> <p>[3] Tavallaee M, Bagheri E, Lu W, Ghorbani AA. A detailed analysis of the KDD<br>CUP 99 data set. In: 2009 IEEE symposium on computational intelligence for<br>security and defense applications. Ieee; 2009. p. 1–6.</p> <p> </p>
All Your Script Are Belong to Us: Collecting and Analyzing JavaScript Code from 10K Sites for 9 Months
<p>We present a massive dataset (~2 TB) of client-side JavaScript code. Specifically, we have collected and stored on adaily basis JavaScript code from Alexa's Top 10000 web sites (~7.5 GB per day) for nine consecutive months. Our collection involved both inline scripts extracted from each web site's main page and external scripts linked from it. In order to aid researchers identify similar scripts and examine their popularity and evolution, we have produced hashes that represent the scripts' logical structure. Furthermore, we have analyzed the resulting dataset with well-established static analysis tools, generating additional metadata including reports with quality bugs and vulnerable libraries.</p>
On the Usage of New JavaScript Features through Transpilers: The Babel Case | Dataset
<p>JavaScript API Deprecation Landscape: A Survey and Mining Study | Dataset</p> <ol> <li>List of Babel plugin occurrences in GitHub open-source JavaScript Projects</li> <li>Table with Babel plugin occurrences found on GitHub open-source JavaScript Projects (complete version)</li> <li>List of Stack Overflow Questions related to Babel proposal plugins</li> <li>Desktop Browser versions and their compatibility with JavaScript Proposal Features</li> <li>Mobile Browser versions and their compatibility with JavaScript Proposal Features</li> </ol>
Execution trace data from: Cross-boundary mobile tracking: exploring Java-to-JavaScript information diffusion in WebViews
Open the record for dataset details and reuse information.
On the (Un-)Adoption of JavaScript Front-end Frameworks
<p>DBR</p>
NoT.JS: Blocking Tracking JavaScript at the Function Granularity
<p>Anon</p>
Understanding the Adoption of Modern JavaScript Features: An Empirical Study on Open-Source Systems
<p>This repository contains the data and analysis from an empirical study investigating the adoption trends of modern JavaScript features introduced with ECMAScript 6 (ES6) and beyond. By mining the source code history of 158 open-source JavaScript projects, the study identifies efforts to rejuvenate legacy code by replacing outdated constructs with modern ones. The findings highlight the extensive use of modern features, their widespread adoption within one to two years after ES6's release, and ongoing trends in the rejuvenation of JavaScript codebases.<br><br></p> <ul> <li> <p><strong>scripts.zip</strong>: Contains Python scripts used to analyze data and generate the graphs presented in the study's results.</p> </li> <li><strong>scripts-threats-analysis.zip</strong>: Contains the Python scripts used to analyze the projects without applying the study's filtering criteria and to generate the table presented in the Threats to Validity section.</li> <li> <p><strong>jsminer-tool.zip</strong>: Includes the tool developed to analyze GitHub repository history and collect metrics on the adoption of modern JavaScript features.</p> </li> <li> <p><strong>jsminer_database_backup.zip</strong>: Provides a PostgreSQL database dump containing all code review comments from the repositories analyzed in the study.</p> </li> </ul>
To Type or Not to Type? A Systematic Comparison of the Software Quality of JavaScript and TypeScript Applications on GitHub
<p>This repository contains the data and script (sampling, data collection, statistical analysis) for a repository mining study on GitHub to compare the software quality of JavaScript and TypeScript applications. Please refer to the README for more information.</p>
Appendix for "Is JavaScript Call Graph Extraction Solved Yet? A Comparative Study of Static and Dynamic Tools"
<p><strong>Abstract</strong></p> <p>The popularity and wide adoption of JavaScript both at the client and server-side makes its code analysis more essential than ever before. Most of the algorithms for vulnerability analysis, coding issue detection, or type inference rely on the call graph representation of the underlying program. Luckily, there are quite a few tools to get this job done already. However, their performance in vitro and especially in vivo has not yet been extensively compared and evaluated.</p> <p>In this paper, we systematically compare five static and two dynamic approaches for building JavaScript call graphs on 26 WebKit SunSpider benchmark programs and two static and two dynamic methods on 12 real-world Node.js modules. The tools under examination using static techniques were <em>npm call graph</em>, <em>IBM WALA</em>, <em>Google Closure Compiler</em>, <em>Approximate Call Graph</em>, and <em>Type Analyzer for JavaScript</em>. We performed dynamic analyzes relying on the <em>nodejs-cg</em> tool (a customized Node.js runtime) and the <em>NodeProf </em>instrumentation and profiling framework.</p> <p>We provide a quantitative evaluation of the results, and a result quality analysis based on 941 manually validated call edges. On the SunSpider programs, which do not take any inputs, so dynamic extraction could be complete, all the static tools also performed well. For example, TAJS found 93% of all edges while having a 97% precision compared to the precise dynamic call graph. When it comes to real-world Node.js modules, our evaluation shows that static tools struggle with parsing the code and fail to detect a significant amount of call edges that dynamic approaches can capture. Nonetheless, a significant number of edges not detected by dynamic approaches are also reported. Among these, however, there are also edges that are real, but for some reason the unit tests did not execute the branches in which these calls were included.</p>
The Adoption of JavaScript Linters in Practice: A Case Study on ESLint
<p>This is the companion appendix of our TSE paper "The Adoption of JavaScript Linters in Practice: A Case Study on ESLint"</p>
Towards the Migration from JavaScript to TypeScript: Strategies and Quality Assessment
<p>Data used for the paper: "Towards the Migration from JavaScript to TypeScript: Strategies and Quality Assessment"</p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.