Memo

While there are some legitimate bugs and differences in state handling even in modern browsers, they are relatively small enough now that you can just use the native HTML5 History API. If you intend to support legacy browsers, then History.js is your bet.

This notice is here as History.js does not receive enough funding to be maintained, so it exists only in legacy condition for legacy browsers. Perhaps it still works for modern browsers, but it could really do with maintenance. Maintenance is very difficult as the library requires manual testing in HTML5 and HTML4 modes, and for each adapter, and for each browser. So that means 2^(# of adapters)^(# of browsers and their versions) tests that need to be run by a human. Tests need to be run by a human as certain failures require browser interactions, such as navigating from the test suite to a different domain and back again, or clicking the physical back buttons, or checking if the physical back buttons actually work. This takes a lot of time.

Despite History.js being one of the most popular JavaScript libraries there is, and has been used by even multi-million-user companies in its time - the reality of economy and company practices seems to be that companies prefer to fork their own internal versions and fix locally with their own devs rather than fund open-source maintainers what they would pay their own devs to make things better for everyone, including themselves, which would be cheaper - but no, that would require too many tiers of company approval that don't understand the need.

As such, if you are an open-source developer, I'd recommend just working on open-source projects that are paid for by your own consulting work or your own company (e.g. every successful open-source project). As otherwise, when they become popular, you better hope they are easily maintainable and testable, otherwise the cost of maintenance is higher than the free time of the maintainers.

So with all that said, this repo still exists for archival purposes, legacy browsers, and a hub for anarachistic issue & fork maintenance.

Cheers, Benjamin Lupton, founder of Bevry, creator of History.js

Welcome to History.js
v1.8b2, June 22 2013

News

22/06/2013: Beta 2 of v1.8 is released. Fixes and uncompressed bundled files.
31/05/2013: Beta 1 of v1.8 is released. Fixes.
14/02/2013: Alpha 4 of v1.8 is released. Fixes.
05/02/2013: Alpha 3 of v1.8 is released. Tests updated.
21/01/2013: Alpha 2 of v1.8 is released. Correct statechange behaviour.
19/01/2013: Alpha 1 of v1.8 is released. Started to categorize old balupton's issues.

History

See the HISTORY.md file for a detailed list of features, changes, solved issues and bugs

Involve

Please create an issue if something doesn't work or if there is a browser specific bug. I'll try to fix it as soon as possible. Please send me your Pull requests if you have a nice solution! I'm also going to review old issues in balupton's repository and try to solve them too.

Aims

Follow the HTML5 History API as much as possible
Provide a cross-compatible experience for all HTML5 Browsers (they all implement the HTML5 History API a little bit differently causing different behaviours and sometimes bugs - History.js fixes this ensuring the experience is as expected / the same / great throughout the HTML5 browsers)
Provide a backwards-compatible experience for all HTML4 Browsers using a hash-fallback (including continued support for the HTML5 History API's data, title, pushState and replaceState) with the option to remove HTML4 support if it is not right for your application
Provide a forwards-compatible experience for HTML4 States to HTML5 States (so if a hash-fallbacked url is accessed by a HTML5 browser it is naturally transformed into its non-hashed url equivalent)
Provide support for as many javascript frameworks as possible via adapters; especially Dojo, ExtJS, jQuery, MooTools, Right.js and Zepto.

Quick Install

Via Ajaxify Script

To ajaxify your entire website with the HTML5 History API, History.js and jQuery the Ajaxify script is all you need. It's that easy.

Via Ajaxify Extension

If you don't have access to your server, or just want to try out the Ajaxify script first, you can install the History.js It! Google Chrome Extension to try out History.js via Ajaxify on select websites without actually installing History.js/Ajaxify on your server.

Via Ruby On Rails Gem

If you are using Rails, then the easiest way for you to try History.js would be to use Wiselinks gem. Wiselinks integrates into Rails application and allows you to start using History.js with three lines of code.

Direct Install

Working with History.js directly

(function(window,undefined){

	// Bind to StateChange Event
	History.Adapter.bind(window,'statechange',function(){ // Note: We are using statechange instead of popstate
		var State = History.getState(); // Note: We are using History.getState() instead of event.state
	});

	// Change our States
	History.pushState({state:1}, "State 1", "?state=1"); // logs {state:1}, "State 1", "?state=1"
	History.pushState({state:2}, "State 2", "?state=2"); // logs {state:2}, "State 2", "?state=2"
	History.replaceState({state:3}, "State 3", "?state=3"); // logs {state:3}, "State 3", "?state=3"
	History.pushState(null, null, "?state=4"); // logs {}, '', "?state=4"
	History.back(); // logs {state:3}, "State 3", "?state=3"
	History.back(); // logs {state:1}, "State 1", "?state=1"
	History.back(); // logs {}, "Home Page", "?"
	History.go(2); // logs {state:3}, "State 3", "?state=3"

})(window);

How would the above operations look in a HTML5 Browser?

Note: These urls also work in HTML4 browsers and Search Engines. So no need for the hashbang (#!) fragment-identifier that google "recommends".

How would they look in a HTML4 Browser?

Note 1: These urls also work in HTML5 browsers - we use replaceState to transform these HTML4 states into their HTML5 equivalents so the user won't even notice :-)

Note 2: These urls will be automatically url-encoded in IE6 to prevent certain browser-specific bugs.

Note 3: Support for HTML4 browsers (this hash fallback) is optional - why supporting HTML4 browsers could be either good or bad based on my app's use cases

What's the deal with the SUIDs used in the HTML4 States?

SUIDs (State Unique Identifiers) are used when we utilise a title and/or data in our state. Adding a SUID allows us to associate particular states with data and titles while keeping the urls as simple as possible (don't worry it's all tested, working and a lot smarter than I'm making it out to be).
If you aren't utilising title or data then we don't even include a SUID (as there is no need for it) - as seen by State 4 above :-)
We also shrink the urls to make sure that the smallest url will be used. For instance we will adjust http://www.mysite.com/#http://www.mysite.com/projects/History.js to become http://www.mysite.com/#/projects/History.js automatically. (again tested, working, and smarter).
It works with domains, subdomains, subdirectories, whatever - doesn't matter where you put it. It's smart.
Safari 5 will also have a SUID appended to the URL, it is entirely transparent but just a visible side-effect. It is required to fix a bug with Safari 5.

Is there a working demo?

Sure is, give it a download and navigate to the demo directory in your browser :-)
If you are after something a bit more adventurous than a end-user demo, open up the tests directory in your browser and editor - it'll rock your world and show all the vast use cases that History.js supports.

Download & Installation

Download History.js and upload it to your webserver. Download links: tar.gz or zip

Include History.js

For Dojo v1.8+

 <script src="http://www.yourwebsite.com/history.js/scripts/bundled/html4+html5/dojo.history.js">script>

For ExtJs v1.8+

 <script src="http://www.yourwebsite.com/history.js/scripts/bundled/html4+html5/extjs.history.js">script>

For jQuery v1.3+

 <script src="http://www.yourwebsite.com/history.js/scripts/bundled/html4+html5/jquery.history.js">script>

For Mootools v1.3+

 <script src="http://www.yourwebsite.com/history.js/scripts/bundled/html4+html5/mootools.history.js">script>

For Right.js v2.2+

 <script src="http://www.yourwebsite.com/history.js/scripts/bundled/html4+html5/right.history.js">script>

For Zepto v0.5+

 <script src="http://www.yourwebsite.com/history.js/scripts/bundled/html4+html5/zepto.history.js">script>

For everything else

 <script src="http://www.yourwebsite.com/history.js/scripts/bundled/html4+html5/native.history.js">script>

Note: If you want to only support HTML5 Browsers and not HTML4 Browsers (so no hash fallback support) then just change the /html4+html5/ part in the urls to just /html5/. See Why supporting HTML4 browsers could be either good or bad based on my app's use cases

Get Updates

For Commit RSS/Atom Updates:
- You can subscribe via the GitHub Commit Atom Feed
For GitHub News Feed Updates:
- You can click the "watch" button up the top right of History.js's GitHub Project Page

Get Support

History.js is maintained by people like you. If you find a bug, report it to the GitHub Issue Tracker. If you've fixed a bug submit a Pull Request and add your fork to the Network Wiki Page.
If you would like paid support and trainings, or have job offers, then refer to the Network Wiki Page. If you are qualified with History.js, then be sure to add your details to that page too.
If your company uses History.js on your projects, and would like to see it grow and prosper (better documentation, bugfixes, upgrades, maintenance, etc.) and would love to become a corporate sponsor then do email [email protected]
If you would like free support for History.js, then post your question on Stackoverflow and be sure to use the history.js tag when asking your question.
If you've created a website that uses History.js, or know of one, be sure to add it to the Showcase Wiki Page.
If you'd love to +1 or like this project, then be sure to tweet about it and click the "watch" button up the top of its Project Page.
For anything else, refer to the History.js GitHub Wiki Site.

Thanks! every bit of help really does make a difference!

Browsers: Tested and Working In

HTML5 Browsers

Firefox 4+
Chrome 8+
Opera 11.5+
Safari 5.0+
Safari iOS 4.3+

HTML4 Browsers

IE 6, 7, 8, 9, (10)
Firefox 3
Opera 10, 11.0
Safari 4
Safari iOS 4.2, 4.1, 4.0, 3.2

Exposed API

Functions

States

History.pushState(data,title,url)
Pushes a new state to the browser; data can be null or an object, title can be null or a string, url must be a string
History.replaceState(data,title,url)
Replaces the existing state with a new state to the browser; data can be null or an object, title can be null or a string, url must be a string
History.getState()
Gets the current state of the browser, returns an object with data, title and url
History.getStateByIndex
Gets a state by the index
History.getCurrentIndex
Gets the current index
History.getHash()
Gets the current hash of the browser

Adapter

History.Adapter.bind(element,event,callback)
A framework independent event binder, you may either use this or your framework's native event binder.
History.Adapter.trigger(element,event)
A framework independent event trigger, you may either use this or your framework's native event trigger.
History.Adapter.onDomLoad(callback)
A framework independent onDomLoad binder, you may either use this or your framework's native onDomLoad binder.

Navigation

History.back()
Go back once through the history (same as hitting the browser's back button)
History.forward()
Go forward once through the history (same as hitting the browser's forward button)
History.go(X)
If X is negative go back through history X times, if X is positive go forwards through history X times

Debug

History.log(...)
Logs messages to the console, the log element, and fallbacks to alert if neither of those two exist
History.debug(...)
Same as History.log but only runs if History.options.debug === true

Options

History.options.hashChangeInterval
How long should the interval be before hashchange checks
History.options.safariPollInterval
How long should the interval be before safari poll checks
History.options.doubleCheckInterval
How long should the interval be before we perform a double check
History.options.disableSuid
Force History not to append suid
History.options.storeInterval
How long should we wait between store calls
History.options.busyDelay
How long should we wait between busy events
History.options.debug
If true will enable debug messages to be logged
History.options.initialTitle
What is the title of the initial state
History.options.html4Mode
If true, will force HTMl4 mode (hashtags)
History.options.delayInit
Want to override default options and call init manually.

Events

window.onstatechange
Fired when the state of the page changes (does not include hash changes)
window.onanchorchange
Fired when the anchor of the page changes (does not include state hashes)

Known Issues

Opera 11 fails to create history entries when under stressful loads (events fire perfectly, just the history events fail) - there is nothing we can do about this
Mercury iOS fails to apply url changes (hashes and HTML5 History API states) - there is nothing we can do about this

Notes on Compatibility

History.js solves the following browser bugs:
- HTML5 Browsers
  - Chrome 8 sometimes does not contain the correct state data when traversing back to the initial state
  - Safari 5, Safari iOS 4 and Firefox 3 and 4 do not fire the onhashchange event when the page is loaded with a hash
  - Safari 5 and Safari iOS 4 do not fire the onpopstate event when the hash has changed unlike the other browsers
  - Safari 5 and Safari iOS 4 fail to return to the correct state once a hash is replaced by a replaceState call / bug report
  - Safari 5 and Safari iOS 4 sometimes fail to apply the state change under busy conditions / bug report
  - Google Chrome 8,9,10 and Firefox 4 prior to the RC will always fire onpopstate once the page has loaded / change recommendation
  - Safari iOS 4.0, 4.1, 4.2 have a working HTML5 History API - although the actual back buttons of the browsers do not work, therefore we treat them as HTML4 browsers
  - None of the HTML5 browsers actually utilise the title argument to the pushState and replaceState calls
- HTML4 Browsers
  - Old browsers like MSIE 6,7 and Firefox 2 do not have a onhashchange event
  - MSIE 6 and 7 sometimes do not apply a hash even it was told to (requiring a second call to the apply function)
  - Non-Opera HTML4 browsers sometimes do not apply the hash when the hash is not urlencoded
- All Browsers
  - State data and titles do not persist once the site is left and then returned (includes page refreshes)
  - State titles are never applied to the document.title
ReplaceState functionality is emulated in HTML4 browsers by discarding the replaced state, so when the discarded state is accessed it is skipped using the appropriate History.back() / History.forward() call
Data persistance and synchronisation works like so: Every second or so, the SUIDs and URLs of the states will synchronise between the store and the local session. When a new session opens a familiar state (via the SUID or the URL) and it is not found locally then it will attempt to load the last known stored state with that information.
URLs will be unescaped to the maximum, so for instance the URL ?key=a%20b%252c will become ?key=a b c. This is to ensure consistency between browser url encodings.
Changing the hash of the page causes onpopstate to fire (this is expected/standard functionality). To ensure correct compatibility between HTML5 and HTML4 browsers the following events have been created:
- window.onstatechange: this is the same as the onpopstate event except it does not fire for traditional anchors
- window.onanchorchange: this is the same as the onhashchange event except it does not fire for states

License

For support see the Getting Support section.

Forgive me if this has been covered elsewhere (although I did do a quick check first).

I have a jQuery web application using History.JS, and I have all my user actions triggering calls to "pushState()" or "replaceState()". Then I have an event hook like:

$(window).bind('statechange', function(event) {
    var state = History.getState();
    History.log('History.stateChange: ' + $.param(state.data) + ' ' + state.url, event);
    // check state object here and control the display of articles or UI elements
    // eg if state.data.page === 1 then hide all pages except for page 1
    event.preventDefault();
    return false;
});

This is working wonderfully. However, I would like to be able to detect whether the Back button was pressed. Specifically, this is so I can use a reverse-animation to emphasis that we are going backwards to a previous page.

Is there a way to identify the difference between a pushState() and a back() once we are in the onstatechange event callback?

I took a look at the History global object, and there are 2 arrays "storedStates" and "savedStates". In testing, however, these always seem to increase in size, no matter the navigation direction, so I cannot simply test the Array.length to see if it shrinks on Back (as I first hoped).

My web application originally had a crudely implemented "back stack" that basically worked like breadcrumbs: increasing in size for each forward navigation, and shrinking in size whenever we went Back and popped the last visited page. Is there any benefit in History.JS adopting similar behaviour?

Alternatively, perhaps a property of the State object can indicate Back-navigation? If we can cull all duplicate states, perhaps the position of the current state in either of the previously mentioned arrays can be used to test for this?

cant-fix

Uncaught Error: History.js Adapter has already been loaded...

Hey Devs!

Very nice plugin/library! Is there a way to get rid of the "Uncaught Error: History.js Adapter has already been loaded... ". I tried with try/catch, but that doesn't work.

I'm using http://labjs.com/ and unfortunately I can't control/check right now if a script was loaded before, so double loading can happen and then historyjs breaks the application with this uncaught error.

Thanks in advance, Matthias
bug resolved-in-dev confirmed

opened by mandrasch 32
try to more consistently handle URI-encoded URLs
use document.URL where possible as it's more consistently URI-encoded across different browsers (e.g. Safari 5.1)

for HTML4 browsers, assume the URI passed to pushState() is URI-encoded, and make sure that every character is encoded like document.URL

fix a spelling mistake in the unsupport-fragment error

this code is based on https://github.com/balupton/history.js/pull/107, but extended to better handle some edge cases in IE and Safari
opened by hrunting 26
URL Encoded percent signs are unescaped by History, causing javascript errors
If the pushed state URL contains a url encoded percent sign (%25), the percent sign is uri decoded causing the URL to sometimes become invalid.

The following snippet indicates that the issue is known but not resolved

History.unescapeString = function(str){ while ( true ) { try{ tmp = decodeURI(result); }catch(e){ // catches a malformed uri error, for some reason, this seems to fix it break; } if ( tmp === result ) { break; } result = tmp; } }

Contrary to the comment in the code this does not fix the problem it just squelches the error.

The real solution is to not unescape URIs in unsafe ways (such as decodeURI).

To reproduce:

History.pushState({}, null, '?query=%23hash%25broken');

For our app, this came into play when users tried to perform search queries containing hashes and percent signs. I have reproduced the issue on other websites using History.js

Try issuing a search containing a hash on the following sites to see it in prod http://www.doyouwantacupoftee.com http://www.collabfinder.com http://www.beatport.com
resolved-in-dev
opened by kevburnsjr 23
Directly going to a hash url

Shouldn't this load the correct content, for example if you clicked this link (html4 browsers) www.example.com/#./page-name shouldn't it load /page-name not the homepage of example.com?

Or is this not something that is supported?

opened by evoactivity 22
IE and iframe problem

When using history.js in an iframe with IE8-9 ( i didn't test with older browser but the same issue is expected ), If we hit the back button, IE go back one state but the change event is not fired.

History.js v1.7 - Windows Vista - IE8 - IE9
resolved-in-dev resolved-in-release unconfirmed

opened by desaintflorent 19
Error msg with IE9

Hi,

I get this error message with IE9 (probably because it's html4): History.js does not support states with fragement-identifiers (hashes/anchors)

What does this error msg mean? In which cases it pops? Any ideas of how can it be fixed?

opened by thejaas 17
Uncaught Error: QUOTA_EXCEEDED_ERR: DOM Exception 22

I was playing around with the mootools.history.js quite a long time. I also save quite a lot content in the state-variable. The problem is that the "Uncaught Error: QUOTA_EXCEEDED_ERR: DOM Exception 22" is counting up all the time. I have already 260 print outs in the console.

I quess that a try catch statement can be needed for the sessionStorage?

try { sessionStorage.setItem(“name”, “Hello World!”); } catch (e) { if (e == QUOTA_EXCEEDED_ERR) { //data quota exceed so throw an error //do some garbage collecting } }
bug resolved-in-dev

opened by zipz 14
detect Back-navigation in onstatechange event callback
Forgive me if this has been covered elsewhere (although I did do a quick check first).

I have a jQuery web application using History.JS, and I have all my user actions triggering calls to "pushState()" or "replaceState()". Then I have an event hook like:

$(window).bind('statechange', function(event) { var state = History.getState(); History.log('History.stateChange: ' + $.param(state.data) + ' ' + state.url, event); // check state object here and control the display of articles or UI elements // eg if state.data.page === 1 then hide all pages except for page 1 event.preventDefault(); return false; });

This is working wonderfully. However, I would like to be able to detect whether the Back button was pressed. Specifically, this is so I can use a reverse-animation to emphasis that we are going backwards to a previous page.

Is there a way to identify the difference between a pushState() and a back() once we are in the onstatechange event callback?

I took a look at the History global object, and there are 2 arrays "storedStates" and "savedStates". In testing, however, these always seem to increase in size, no matter the navigation direction, so I cannot simply test the Array.length to see if it shrinks on Back (as I first hoped).

My web application originally had a crudely implemented "back stack" that basically worked like breadcrumbs: increasing in size for each forward navigation, and shrinking in size whenever we went Back and popped the last visited page. Is there any benefit in History.JS adopting similar behaviour?

Alternatively, perhaps a property of the State object can indicate Back-navigation? If we can cull all duplicate states, perhaps the position of the current state in either of the previously mentioned arrays can be used to test for this?
cant-fix
opened by jokeyrhyme 14
History.store.idToState is full!

Hey, I've been using your library for some time... it is a great library! Now to my issue: Suddenly, when i tried to do something that makes a push in the history the browser crashed (this happened in ff 5 on ubuntu). When i started to inspect why this was happening i found in line 614 of history.js a while (true) loop that tries to find an unused id in History.idToState and History.store.idToState. The thing is that while History.idToState is empty History.store.idToState has 1000 items and the new ids are searched for in a range of 0 to 1000; therefore the while loop went on forever. I worked around this by making the range larger, but what is causing this strange behavior? am i doing something wrong? why is History.store.idToState holding so many items?

Bye!!
bug confirmed

opened by andres-blanco 12
Created a small localStorage wrapper, with similiar API to amplify

Like already discussed, I would like to see less dependencies and more interoperability. With this patch I have introduced a small localStorage wrapper. If localStorage is not available amplify will be used.

So amplify can used similiar to json2 or the developer can decide, that he uses another localStorage polyfill. (amplify only works in same folder and has "only" 100kb).
brainstorm

opened by aFarkas 12
Breathing new life into History.js
Hi Benjamin,

I noticed that History.js appears to be in an interesting state -- it is clearly a great project, but there appear to be a few problems:

Pull requests getting ignored. It's been 8 months since a pull request was closed.

Issues also seem neglected.

It appears that the project needs one of two things:

Add collaborators. Maybe andrew-sayers--slando or someone else who has made recent / multiple contributions.

Pass the torch to a fork.

Anyway, I'd love to see the project growing, so I thought I'd share my thoughts. It seems like a lot of people love what you've done, and are interested in fixing issues and such -- but as it is, it appears there is a bottleneck due to a lack of collaborators.
planned brainstorm you can help
opened by mrienstra 11
Revise tests

Finally there seems some tech out to replace the manual cross browser testing infrastructure. If only they support mobile browsers too.

https://github.com/microsoft/playwright

however what is needed is an actual headful browser where one actually clicks the back and forward buttons on the browser, on desktop and mobile

opened by balupton 0
Back Button Error while using with VueJs Data

I have integrated Vuejs Framework to Store Data from API into some variable and showing it on frontend. Upon clicking a link and reaching to the new page everything is fine, But when going back to the index, I am losing my all data generating from Vuejs Variables.

opened by kartikcool15 0
OnPopState calls in case of section change

In case of section change in the current page I call a link like: http://localhost:8080/page/xxxid#section-How+does+Test+work%3F

We use also tab changes on the page, which look like http://localhost:8080/page/xxxid

onPopState state function calls every time when I use this links, and modify the link on a wrong way when I use section change (remove the id): http://localhost:8080/wiki/section-How+does+Test%3F

I could fix it on that way that I override the onPopState event handler like: History.onPopState = function(event,extra){ if (History.getLocationHref().indexOf("#")!==-1) return; ..

Please fix it!

opened by bcsongi 0
history.goback() is not working for mozilla firefox

<button to="#" className="pull-left back-to-table" onClick={() => createBrowserHistory().goBack()} > <Icon type="double-left" /> Back </button>

I am using react for this.

opened by nichoguimbaolibot 0

History.js gracefully supports the HTML5 History/State APIs (pushState, replaceState, onPopState) in all browsers. Including continued support for data, titles, replaceState

Related tags

Overview

Memo

Welcome to History.js v1.8b2, June 22 2013

News

History

Involve

Aims

Quick Install

Via Ajaxify Script

Via Ajaxify Extension

Via Ruby On Rails Gem

Direct Install

Working with History.js directly

How would the above operations look in a HTML5 Browser?

How would they look in a HTML4 Browser?

What's the deal with the SUIDs used in the HTML4 States?

Is there a working demo?

Download & Installation

Get Updates

Get Support

Browsers: Tested and Working In

HTML5 Browsers

HTML4 Browsers

Exposed API

Functions

States

Adapter

Navigation

Debug

Options

Events

Known Issues

Notes on Compatibility

License

Comments

Owner

Browser State

Query for CSS brower support data, combined from caniuse and MDN, including version support started and global support percentages.

Persistent key/value data storage for your Browser and/or PWA, promisified, including file support and service worker support, all with IndexedDB. Perfectly suitable for your next (PWA) app.

This package generates a unique ID/String for different browsers. Like chrome, Firefox and any other browsers which supports canvas and audio Fingerprinting.

Grupprojekt för kurserna 'Javascript med Ramverk' och 'Agil Utveckling'

Hemsida för personer i Sverige som kan och vill erbjuda boende till människor på flykt

Kurs-repo för kursen Webbserver och Databaser

Master Collection NFT. Mints NFTs on Ethereum containing unique combination of titles for fun.

OnePiece /r/place repo to store the template and script for outlining the place to put titles

GitHub Action to validate that PR titles in n8n-io/n8n match n8n's version of the Conventional Commits spec

AdsPower supports Local API, which has functions like reading and writing account configuration information, opening and closing browsers, searching for accounts.

Javascript client for Sanity. Works in node.js and modern browsers (older browsers needs a Promise polyfill).

Pull sensitive data from users on windows including discord tokens and chrome data.

Phaser is a fun, free and fast 2D game framework for making HTML5 games for desktop and mobile web browsers, supporting Canvas and WebGL rendering.

List all browsers compat data from MDN and filter with browserlist.

GraphQL Hive provides all the tools the get visibility of your GraphQL architecture at all stages, from standalone APIs to composed schemas (Federation, Stitching)

The leaderboard website displays scores submitted by different players. It also allows you to submit your score. All data is preserved thanks to an external API. Technologies used are JavaScript(ES6), HTML5, CSS3, Webpack. Also, the Gitflow workflow was used.

Periksa apakah data browsing history anda bocor?

A utility for cloning all your repos, including issues, discussions, stargazers and more!

This project is a Web application based on an external API. The API provides data about music (including artists, albums, etc) that users can access on-demand. This project was built with ES6, HTML and CSS and it is a SPA.

Welcome to History.js
v1.8b2, June 22 2013