{"id":13989793,"url":"https://github.com/ustwo/ustwo.com-frontend","last_synced_at":"2025-05-15T11:03:45.543Z","repository":{"id":31647842,"uuid":"35213122","full_name":"ustwo/ustwo.com-frontend","owner":"ustwo","description":"The New \u0026 Improved ustwo Website","archived":false,"fork":false,"pushed_at":"2022-06-04T18:28:09.000Z","size":220386,"stargazers_count":1819,"open_issues_count":6,"forks_count":269,"subscribers_count":102,"default_branch":"master","last_synced_at":"2025-04-07T03:19:18.639Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"http://www.ustwo.com","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ustwo.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE.md","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2015-05-07T10:09:25.000Z","updated_at":"2024-12-09T19:24:34.000Z","dependencies_parsed_at":"2022-07-26T06:32:10.056Z","dependency_job_id":null,"html_url":"https://github.com/ustwo/ustwo.com-frontend","commit_stats":null,"previous_names":[],"tags_count":215,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ustwo%2Fustwo.com-frontend","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ustwo%2Fustwo.com-frontend/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ustwo%2Fustwo.com-frontend/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ustwo%2Fustwo.com-frontend/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ustwo","download_url":"https://codeload.github.com/ustwo/ustwo.com-frontend/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248868766,"owners_count":21174758,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-09T13:02:04.258Z","updated_at":"2025-04-14T14:53:56.101Z","avatar_url":"https://github.com/ustwo.png","language":"JavaScript","funding_links":[],"categories":["JavaScript","📦 Legacy \u0026 Inactive Projects"],"sub_categories":[],"readme":"# ustwo.com website\n\n[![Circle CI build status][16]][17]\n\n## Overview\n\nThis repository contains all the front end code for the current [ustwo.com][1]\nwebsite and the toolset required to build and deploy it.\n\nIn order to be able to have full control over all aspects of the website –\nincluding transitions between pages – and to make navigation super fast by not\nhaving to reload the browser, we decided to build the site as a\n[single-page application][2]. We chose [React.js][3] as a main JavaScript\ntechnology enabling us to do this, since it has built in support to render\npages on the server side too (called isomorphic rendering). This way we could\nkeep the initial rendering performance snappy on mobile and let visitors\nsee content without an extra data loading step which usually happens with most\nclient side JavaScript framework. To enable server side rendering and to have\nproper URLs, we put a small Node backend server behind our app.\n\nOur content management system behind this is a Wordpress instance which doesn't\nactually render the pages itself, but instead serves content up via [WP API][4]\nthrough a mixture of standard and customised JSON REST API endpoints, making the\nvast majority of the content editable.\n\n## Tech stack\n\n### React SPA\n\nWith the current set of challenges and available browser features we found\nReact.js to be a great solution to templating and events on the UI. The\ncomposability of components with the one way binding and \"queryless\" event\nhandling offered by JSX templates is solving the right problems, without trying\nto do too much and become a framework. The easy to implement server side\nrendering combined with the ability to prevent rerendering on client side (by\ninternally doing a comparison to the virtual DOM) is also a great feature to\nmake it a viable solution on mobile.\n\nTo make it a single-page application we put Flux Routes and Store behind the\nReact front end, so that it can take over the navigation from the browser and\nload data from Wordpress by itself.\n\nSince we need to precompile JSX anyway, in our quest to minimise the number of\nlibraries (like Underscore, etc) and push a future-proof way of working with\nJavaScript, we adopted a lot of ES6 features by transpiling the code with Babel.\n\nAs for the CSS, we're using Sass to be able to split our styles and store them\ntogether with the components. But in general we're trying to minimise the\nreliance on Sass language specific features and instead write as much pure CSS\nas possible, getting ready for a CSS Next / PostCSS world just as we did with\nES6.\n\nFor the animated illustrations on the site we use SVG sequences, controlled by a\nsmall React component. This is unfortunately only possible with inlining SVGs,\nbut all the static vector symbols are stored in one, external SVG sprite,\npolyfilled for old Internet Explorers with [SVG for Everybody][15].\n\n### Node app\n\nSince all the heavy content work is done for is in Wordpress, our Node / Express\napp is kept as light as possible. The only two main responsibilities are\ndelivering fully baked HTML files through running React rendering on the\nprefetched content and responding to the same routes as the front end app does.\n\n### Nginx\n\nAs we had quite a lot of components (or microservices if you will) to tie\ntogether – multiplied by production + staging + dev environments – we didn't\nwant to overburden our Node server and decided to put an Nginx proxy in place.\n\n### Build tools\n\nWhile we started out using Gulp for our frontend builds which was a very\nconvenient start point for quickly iterating different combination of tools,\nin the end we settled on shell scripts using the fastest command line builds of\nlibraries.\n\nFor JavaScript we're using Browserify (plus Persistify caching) to process our\ncode with Babel and resolve dependencies using Aliasify. Our Sass code is\ncompiled using SassC with PostCSS's Autoprefixer taking care of vendor\nprefixing. All this happens in a dedicated compiler Docker image, so that we can\nkeep the production application as lean as possible.\n\nTo get the Docker environment up and running and to tie all of the above\ntogether, we created a fleet of Makefiles to get some extra flexibility with\nshared variables and task composition on top of shell scripting.\n\n### CDN\n\nWe have *everything* served up from a CDN, and by that we mean that ustwo.com is\npointed at the CDN URL on a DNS level! Needless to say this guarantees great\nload speeds across the globe and at very little cost. Call it the \"CDN first\"\napproach if you will – check out our [blog post about this here](https://ustwo.com/blog/open-sourcing-our-website).\n\nUnless you have a lot of user dependent dynamic content (and it's not feasible\nmoving these areas to subdomains) the trick is to remove caching from all layers\nof the stack, while keeping the client side cache / expiry short (we're using\nonly 1 hour or effectively one session).\n\nThis way the only place you need to worry about and manage cache is the CDN. Of\ncourse for this you need to have a decent CDN which has an API to purge and\nprefetch content. At this point all the servers and applications behind can be\nscaled down to no cache and minimum resources as they'll only be accessed by the\nCDN network for an occasional update.\n\n### The big picture\n\nSo here's how all this fits together and creates a working setup with our\nWordPress backend and CDN.\n\n[![ustwo.com infrastructure diagram][5]][5]\n\n## Inclusion\n\n### Browser compatibility\n\nWe're aiming to support all evergreen browsers (Chrome, Firefox, Edge and Opera\non all platforms), Safari on Mac and iOS, Internet Explorer 10-11 and Android\nBrowser 4.2-4.4.4.\n\nIn case you were wondering, we've chosen these as we wanted to be able to use\n[Flexbox][6], and they also happened to conveniently overlap our historical\nvisitor profiles from Google Analytics.\n\nIf you see any misbehaviour with one of these browsers please open an issue!\n\n### Performance\n\nBeing a studio which is passionate about delivering a great user experience\neverywhere and early champions of mobile, we kept performance in the front of\nour minds throughout the process of building the websites.\n\nThis means that we are continuously reviewing both hard metrics and perceptual\nperformance. To get reports and keep an eye on things, we found [GTmetrix][14]\nto be a great tool with a generous free tier. It calculates both PageSpeed and\nYSlow scores, generates a network waterfall, renders a filmstrip view and sends\nan automated report of all these regularly.\n\nThere are too many things to list here, but we mentioned a lot of optimisations\nthroughout this README and might cover some of them specifically in blog posts\nlater.\n\n### Accessibility\n\nOfficially supporting only modern browsers doesn't mean that we ignore people\n(and browsers) with special needs.\n\n* We're delivering prerendered HTML, so content is delivered to and rendered on\nclients without Javascript (or with overzealous ad blockers)\n* Clean, standards compliant markup\n* WAI-ARIA tags (TODO: test more comprehensively and with real users)\n\n## Setup\n\n### Docker\n\nIn order to get up and running you need Docker. The best way to install\nDocker is to follow the current\n[Docker documentation](https://docker.github.io/engine/installation/)\n\nThen add the following aliases to your `/etc/hosts` file:\n\n```\n127.0.0.1 local.ustwo.com\n127.0.0.1 staging.ustwo.com\n```\n\n*Note*: For setup without the native docker client, skip this step and see\n[DOCKER-SOURCE.md][18].\n\n### Credentials / Vault\n\n* Open a Terminal window and go to the project folder.\n\nThe easiest way is to load the vault image from a tar. If you receive the image\ntar from someone in the team just do:\n\n        $ make vault-load VAULT_PATH=path/to/vault-2015.tar\n\nIf you do not have access to this tar then you can proceed by generating your\nown self-signed certificates.\n\n        $ make vault-generate-cert\n        $ make vault-build\n\n*Note*: If you use self-signed certificates you probably want to use your\ndocker IP (e.g. `docker-machine ip dev`) instead of a custom `ustwo.com`\ndomain.\n\n\n## Develop\n\n*Note*: Check the [MAKE.md][11] for an explanation of how the Make\ntasks are structured.\n\n* Open a Terminal window and go to the project folder.\n\nPrepare a new environment:\n\n        $ make compiler-build build\n\nCompile the assets (you can use only this when you're only recompiling on front\nend stuff):\n\n        $ make stuff\n\nOr target specific subtasks:\n\n        $ make css             # compiles SASS files\n        $ make spa             # compiles the React app\n        $ make vendors         # compiles app dependencies\n\n*Note*: `css` and `spa` combined with `VERBOSE=true` will create sourcemaps.\n\n*Note*: `spa` and `vendors` combined with `FLUSH_CACHE=true` will skip any\ncache created by browserify. Ex:\n\n        $ make spa VERBOSE=true FLUSH_CACHE=true\n\nDeploy app (when you need to restart services):\n\n        $ make -i love LOCAL_FS=true VERBOSE=true\n\n*Note*: Add the flag `LOCAL_FS=true` if you want to use your local files instead\nof the ones inside the containers.\n*Note*: Add the flag `VERBOSE=true` if you want the JS and CSS expanded and more\nlog output on the services.\n\nAs long as `LOCAL_FS=true` is set a convenient way to refresh the environment\nis:\n\n        $ make -i love stuff LOCAL_FS=true\n\nAs it will rebuild the assets (`stuff`) and recreate the containers (`love`)\nremounting all necessary files from the host environment.\n\nClean the environment:\n\n        $ make clean\n\nSee Node app logs with:\n\n        $ make app-log\n\nAnd Nginx logs with:\n\n        $ make proxy-log\n\n\n### Watch and reload\n\n* Open a Terminal window and go to the project folder.\n\nCSS has extra tasks to speed up the development cycle. `css-watch` starts a\n`fswatch` process in _the host machine_ watching any scss or css file under\n`scr/app`.\n\n        $ make css-watch\n\n*Note*: `brew install fswatch` to install `fswatch` in your machine.\n\n`sync` starts a dockerised `browser-sync` proxy listening by default to port\n`3000`. So you can combine the two:\n\n        $ make -i sync css-watch\n\nOpen `http://192.168.99.100:3000` in your browser and start editing scss and\nlet the toolchain compile and push changes to the browser.\n\n*Note*: `browser-sync` uses a self-signed certificate so using `local.ustwo.com`\nor the raw IP will make the browser complain. If you need to overcome this\nplease add a forward rule to Virtualbox so you can use `http://localhost:3000`.\n\n## Test\n\n* Open a Terminal window and go to the project folder.\n\nRun all tests:\n\n        $ make test\n\n### Sandbox\n\nWe believe that every component should hold a single responsibity, and which\nfunctionality must be working independently from the context the component is\ninstantiated in.\n\nTo enforce best practices – like storing functionality and styles in the\ncomponent they belong to – we created a sandbox to test components in an\nisolated environment.\n\nTo prepare the sandbox run:\n\n        $ make sandbox-build\n\nAnd start the sandbox server with:\n\n        $ make -i sandbox LOCAL_FS=true\n\nThe sandbox will be available at https://local.ustwo.com:9443/sandbox\n\n### Unit\n\nWe're using Mocha + Chai + Sinon to run unit tests against JSDOM as this setup\nworks well with React and executes fast.\n\nRun the unit tests:\n\n        $ make assets-unit-test\n\n### Integration\n\nTo keep setup simple and still be able to test Internet Explorer and mobile\nbrowsers running on real devices, we're running integrations tests using Sauce\nLabs with a Sauce Connect tunnel. This unfortunately means that if you want to\nbe able to run these tests, you'll need to create an account and set up\n`SAUCE_USERNAME` and `SAUCE_ACCESS_KEY` as environment variables.\n\nAlso to minimise context switching, we're running our simple sanity testing\nsuite using Mocha + Chai + Chai Promises + WD.js.\n\nRun the integration tests:\n\n        $ make assets-integration-test\n\nIf you need more info on what's happening with the tests, you can either log in\nto the Sauce web UI to see the Selenium logs to understand more details about\nthe browser interactions or run verbose mode locally for more info on the API\nrequests and their results:\n\n        $ make assets-integration-test VERBOSE=true\n\nTODO: add flow diagram about git branches -\u003e CI, etc\n\n## Release\n\nWe're using Docker Hub and Docker Machine to tag and deploy Docker images, for\nmore info see [RELEASE.md][12].\n\n## Contribution\n\nTo read up on our coding style and general contribution guide, have a look at\n[CONTRIBUTING.md][13].\n\n## License\n\nustwo.com website front end and tools\nCopyright (C) 2015-2017 ustwo fampany limited.\n\nThis program is free software: you can redistribute it and/or modify\nit under the terms of the GNU General Public License as published by\nthe Free Software Foundation, either version 3 of the License, or\n(at your option) any later version.\n\nThis program is distributed in the hope that it will be useful,\nbut WITHOUT ANY WARRANTY; without even the implied warranty of\nMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\nGNU General Public License for more details.\n\nYou should have received a copy of the GNU General Public License\nalong with this program.  If not, see \u003chttp://www.gnu.org/licenses/\u003e.\n\n[1]: https://ustwo.com\n[2]: https://en.wikipedia.org/wiki/Single-page_application\n[3]: https://facebook.github.io/react/\n[4]: http://v2.wp-api.org/\n[5]: ./docs/infrastructure.png\n[6]: http://caniuse.com/#feat=flexbox\n[7]: https://kitematic.com/\n[8]: https://docs.docker.com/machine/install-machine/\n[9]: https://docs.docker.com/installation/\n[10]: https://www.virtualbox.org/wiki/Downloads\n[11]: ./docs/MAKE.md\n[12]: ./docs/RELEASE.md\n[13]: ./CONTRIBUTING.md\n[14]: https://gtmetrix.com/\n[15]: https://github.com/jonathantneal/svg4everybody\n[16]: https://circleci.com/gh/ustwo/ustwo.com-frontend.png?circle-token=6b4747fb91e70c0c1e3050879f6b5eebdf34dec3\n[17]: https://circleci.com/gh/ustwo/ustwo.com-frontend\n[18]: ./docs/DOCKER-SOURCE.md\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fustwo%2Fustwo.com-frontend","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fustwo%2Fustwo.com-frontend","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fustwo%2Fustwo.com-frontend/lists"}