The Cloudflare Workers website.
Home Page: https://workers.cloudflare.com
📖 See the Remix docs and the Remix Vite docs for details on supported features.
Run the Vite dev server:
npm run dev
First, build your app for production:
npm run buildThen run the app in production mode:
npm startNow you'll need to pick a host to deploy it to.
If you're familiar with deploying Node applications, the built-in Remix app server is production-ready.
Make sure to deploy the output of npm run build
build/serverbuild/client
Via b47ef18, if a project isn't in a collection, we have no "related" projects to show in the "Also built with..." section. What should we show instead? It's pretty trivial to just pick a random selection of projects and show it there, but I want to make sure that we're on the same page as to what we think makes sense to show there.
On project pages, the "Also built with Workers..." section near the bottom is hard-coded to display a bunch of dummy projects. Instead it should be driven from real data (some sort of "related" projects concept—which can be just a list of random projects to start if we’d like).
Currently, wrangler.toml is configured to deploy to my personal workers.dev instance (signalnerve.workers.dev) – pre-launch, my personal credentials should be replaced w/ my @cloudflare creds so we can publish to workers.cloudflare.com
@signalnerve This came from a conversation @ashleygwilliams and I had earlier today. We felt like it would improve moderation ergonomics to have a project.live property (or isLive?—up to you) which we can use to filter projects from inclusion in collections on the homepage.
Currently, if you mark a project as a draft (to achieve a similar end goal), Sanity tells you that this will break the collections that project is a member of (which makes sense). So instead, if you were able to keep it "published" (as far as Sanity is concerned) but with the live flag turned off, we could still generate a /built-with/projects/slug page for it, but prevent it from showing on the homepage.
We already plan to mention licensing in this repo and on the content submission form. But we’re considering mentioning something to the effect of "All project content licensed under CC By-SA" on the site somewhere.
cc @signalnerve
It’s subtle, but:
Observe that the list view images render blurry for at least 1 render frame, sometimes more.
It might be worth it to periodically grab screenshots for websites featured on Built With Workers so they don't need to be manually updated every time a dev pushes a change.
After some weirdness with a collection being cleared out yesterday, @ashleygwilliams had a great idea – we should be backing up our data just in case – because it's all JSON, we can probably script something in GitHub Actions and then upload it to a KV namespace
This is just an idea, feel free to close if it seems bad/not worth it but I thought it would be cool to have a "Feature on Built With Workers" badge that we can give out to sites that are featured with the number of times they've been bookmarked
We could maybe even incorporate these badges on the marketing landing pages for products like Access, AMP Real URL, etc.
When using the native browser back functionality, it does, but when clicking the link, it doesn’t. I can see an argument for both, but I’m leaning towards making the link consistent with the native browser behavior.
@signalnerve would love your thoughts.
When viewing the site at https://built-with-workers.signalnerve.workers.dev/built-with, if you click a project, then hit the browser back button, you’re not taken back to the homepage, but instead to the page you were on before (e.g. this Github issue page if you click the link from here, or about:blank if you open the page fresh).
This differs from the behavior locally (localhost:8000/built-with), in which hitting the back button correctly returns you to the built-with.js page.
"Features" (features of Cloudflare Workers) are not shipping as a first class citizen in the MVP, so we’re going to delete the template for these (for now).
@signalnerve I’d love your help figuring out how to fix the issues with references to assets via url() in CSS files, e.g. https://github.com/cloudflare/built-with-workers/blob/3cc6e304d0cafcad498af5553048cbfb23d8af44/src/vendor/workers-brand-assets/css/components/unordered-list.css#L1-L18
For now I manually replaced them with inlined assets to workaround the issue, but once #41 happens we’ll need a real solution.
I’m not sure if Gatsby/Sanity/React/(Our setup) offers this level of control, but I’d love to be able to reference the files externally but then have the bundling inline them or not depending on our preferences. (In some cases, inlining may have the best performance trade-off characteristics.) Looking forward to hacking on this stuff together @signalnerve!
When you hit back from an individual project page, you lose your horizontal scroll position for the collections on the index page.
I can't click and drag and I don't have a horiz scrolling mousewheel right now (travelling) so I got stuck trying to move the carousel to the right.
Trackpad works fine, but without a scrollbar or some arrow on the sides, this feels like a bad pattern.
I would add subtle arrows on the sides for desktop with a hover that makes them bolder so they don't get in the way too much. User clicks and it should slide the carousel over about 80% of screen.
We should finalize the URL for this project so we can prepare accordingly for:
gatsby-config.js) - this will affect how the production URLs are generatedworkers.cloudflare.com, for instance, we should figure how to correctly have both the landing page and built-with URLs render from two different deploysThese are not original ideas (they're @adamschwartz's from our past convos about this project), but I have two open questions around this topic:
workers.cloudflare.com.workers.cloudflare.com, can we just move the landing page (workers.cloudflare.com) into this codebase? It's two pages with extremely similar CSS that we could just drop wholesale into pages/, wrap in a React component, and be ready to go (I think 😅 – I would block off a day to get it working)Adam's proposal for this project's URL was workers.cloudflare.com/built-with, which I think looks super cool and is easy to remember.
The other options URL options I've considered or heard mentioned in passing are:
www.built-with.workers.dev (using the www hack that @EverlastingBugstopper discovered recently). I don't know if we want to promote this hack, but it does look cool :)built-with.workers.cloudflare.com – no script clashes between the landing page and this Workers Sites project, and it matches the name of the project. My understanding is that the landing page and this subdomain wouldn't share SEO juice, so that would be a potential downside for this option.Other ideas? cc @ashleygwilliams @rita3ko, feel free to @ anyone else who wouldn't get the Workers DevEx Team ping for this issue being opened. Sorry that there's a few questions interleaved in here!
We’re doing pretty well on the others, but SEO is struggling.
e.g. It appears we’re not SSR-ing the <title/> element, and we’re serving a 500 status code for /robots.txt.
Allows us to use for Product Hunt releases, Show HN posts, etc.
@signalnerve would appreciate your help with these.
Create a contribution guide that outlines:
Here we’ll discuss the initial plan for the design of the Built with Workers site. This document was put together by @adamschwartz and @signalnerve with help from @remyguercio and based on research and input from the broader Workers team.
Each goal is listed in a rough priority order. Meaning, for our MVP, we seek to achieve goal 1 stronger than goal 4. Note though that these are somewhat overlapping goals, and design is an art as well as a science, so it’s OK if we’re not strict here.
These are also sorted in rough priority order. Same lack-of-strictness applies.
order property similar Cloudflare Apps)[1]: We’re particularly excited about using Workers KV to build this (and showcasing that as Built with Workers itself will likely be a featured project of the site—yes, how meta of us).
Here are a few of the things we considered building but decided against for the MVP. By no means should this list be considered exhaustive. We are happy to consider them after we slap down a v1.
We think feature badges are going to be really fun. But we’re not sure exactly how they’ll work. We may have categories of these which could be distinguished e.g. by color.
We plan to take a content-driven approach for the initial design. This is generally a solid approach to design, but it’s especially critical when designing a site whose content is generated by someone other than the designer.
The main content of course are the projects. So, with the help of @remyguercio we generated an initial list. If you know of know of any projects we missed, please let us know!
I know y’all want to see pretty pictures. I promise, they will soon exist. However, at this stage we feel it’s more important to share the plan, get feedback, and build consensus before drawing a bunch of rectangles.
(As deployed on https://built-with-workers.signalnerve.workers.dev/built-with/ ATTOTI.)
This has a few consequences for the CSS, perhaps the main one being that none of the theme color CSS is applied until JS adds the attribute.
The normalizeCollection function (https://github.com/cloudflare/built-with-workers/blob/master/src/utils.js#L3-L23) is a pretty big hack for a limitation in the Sanity/Gatsby GraphQL integration, where we don't have access to belongsTo-style data modeling. Instead of normalizing it at the component layer, my friend at Sanity has suggested implementing it in gatsby-node.js, so that by the time the component makes the GraphQL query, the data has already been normalized in the way we need it to be. This isn't a blocker but a good refactor to consider after v1.
Some of the existing issues:
The way <Bookmark/> is non-transparently morphed/overloaded to represent both <BookmarkIndicator/> and <BookmarkButton/> is confusing.
The Project components is not "aware" of its bookmarked status (there’s no project.bookmarked) which is why we end up needing to use CSS classNames like Project--bookmark inside of the Bookmark component. This means you can’t properly render the DOM for <Project/>s not bookmarked, and it means the Bookmark component is not reusable.
The render path also produces a different DOM structure depending on whether the component is rendered in the browser vs. at the edge.
My rough proposal would be the following:
Break up Bookmark into two components, BookmarkIndicator and BookmarkButton, and they would share code from a "helper" JS file called bookmark.js placed somewhere else in src (not the src/components directory), to handle the ES vs. browser logic.
Move the bookmark status storage into a helper or into Project, and pass a boolean into the Bookmark component to allow it to determine how to render itself.
cc @signalnerve
as per convo with @adamschwartz on Friday, the project schema should resemble the following:
title: '' // text
shortDescription: '' // text
longDescription: '' // markdown
links: [
link: {
url: 'https://workers.cloudflare.com' // url
type: 'website' // `website`, `twitter`, `code`, `blog-post`, etc.
primary: Boolean
},
//...
]
developer: {
image: { /* ... */ },
name: '' // text
}
claps: 0 // number – unsure if this will actually live in sanity
On project pages, the "Developer" metadata field is hard-coded to "Cloudflare".
e.g.:
We should take a similar approach to workers-docs and build the project on all pull requests to master: see https://github.com/cloudflare/workers-docs/blob/master/.github/workflows/main.yml for an example of how to do this.
Per #9, we should configure the application to build URLs in the format workers.cloudflare.com/built-with*
Currently we display "This app works best with JavaScript enabled." at the top:
We can deliver a better user experience for this.
We should probably have something simple at the very least to get us through the initial release. Currently on mobile, you can click the logo to go back to https://workers.cloudflare.com and there’s a login button as well. But there’s no way to get directly to the Docs from the /built-with e.g. I won’t set this as a blocker for the MVP release, since once you tap the logo then you can get anywhere. But the current situation is certainly less than ideal, and I don’t want to let the "Docs Redesign" project hold this up. We should be using this site as a way to experiment while we work on the grand nav plan for the long term.
Only https://github.com/cloudflare/built-with-workers/tree/0dd54aceeb36a35e5cb4a481c8516084a551d21b/src/vendor/workers-brand-assets should be necessary since https://github.com/cloudflare/built-with-workers/tree/0dd54aceeb36a35e5cb4a481c8516084a551d21b/src/vendor/workers.cloudflare.com/css/components should be taken care of by #15.
Assigning @ashleygwilliams for the moving https://github.com/ashleygwilliams/workers-brand-assets to @cloudflare part and @signalnerve for the NPM ./node_modules-y stuff after that. 🎉
There’s two (I believe related) issues with the display behavior of the Clap component.
If you navigate from any page into a page which has a clap in it, the clap won’t load. But if you load that page directly, it does:
I think this may be because the <script id="claps_json"/> is in the DOM when the worker returns SSRs the page directly, but not when you navigate there from another page.
When a page with a clap in it loads, the page renders a frame without the clap in it before it renders the clap in it, effectively creating a FOUC.
Outside of React-world, I’d easily work around this by e.g. putting a placeholder wrapper element which has a fixed height, waiting for the clap to "fill in" the placeholder. But in this case, doing that would break the component paradigm as it would have to be code outside of the clap component itself (I assume because of the way useEffect and setESR are working together). Moreover, in the case where we’re doing a direct load of the page SSR is inlining the clap JSON, so nothing asynchronous should need to be happening.
This is where 1) and 2) become intertwined. Once 1) above is solved, that would necessitate solving 2) in an additional way. We not only need to avoid FOUC on the direct project page loads, but also when navigating to a project page from another page (e.g. the /built-with page, or one day, other parts of this Gatsby site which may deep link to a project).
The light/dark theming logic is being loaded when the React application boots up, meaning that there can be a slight flicker before the current theme is processed. We should put it pre-React app/component load (maybe even in just public/index.html or the Gatsby equivalent) to fix that flicker.
Current code:
Implement the icon refactor from my mock in #63 (e.g. https://github.com/cloudflare/built-with-workers/pull/63/files#diff-895b2966d5478f1ca4a0e332edff6021) but in master.
When we load a page like https://workers.cloudflare.com/built-with/projects/web-scraper, the SEO component should receive props from the project template and render a specific project image, description, etc.
We should use the same one that’s on https://workers.cloudflare.com, which is currently vendor’d into this repo from https://github.com/ashleygwilliams/workers-brand-assets:
Per #9, we are exploring moving the landing page content into this codebase, which will serve as the new home for everything on workers.cloudflare.com.
My early attempts at getting the content from that site (two pages) to load has been fairly successful: this is after about 20min of work.
There's a bunch of vendored CSS in this repository that is shared with the landing page – Adam and I have been discussing how to effectively move it back into the landing page repo (or vendoring the assets appropriately so that it can be shared between them), but by merging that content into this repo, we're effectively putting off that problem for the immediate future, as this repo can become the definitive source for the CSS and the content for both sites.
Before we move ahead on this, we'll need to explore a couple additional things:
/docs* requests to the Workers docs (developers.cloudflare.com/workers). The code for that is in workers-site/index.js. We should either move that into the script for this project, or potentially compose a new script that just lives on /docs* and takes higher precedence over the script for this application. The benefit there would be that potentially we could show off this project as a pure JAMstack app using the default Workers Sites script ("It works with no additional config – look!").I noticed this just now as I was changing some project images.
If in Sanity I upload a new image for a project and then hit publish, I see this in my terminal:
/Users/[redacted]/.nvm/versions/node/v8.12.0/lib/node_modules/gatsby-cli/node_modules/yoga-layout-prebuilt/yoga-layout/build/Release/nbind.js:53
throw ex;
^
TypeError: Cannot read property 'write' of null
at Zlib.callback (zlib.js:499:33)
The list view needs something above the fold to establish the page.
Could be just "Built with Workers", could have an illustration or animation, or something fancier. For MVP, a stylized h1 may be good enough.
Collections should be a new top-level schema that is used on the homepage to compose collections of projects. This should be fairly open-ended so we can do things like "Ecommerce" or "Built with HTMLRewriter".
My proposal is that collections should have two modes, one where you can set a tag (e.g. "Build with HTMLRewriter"), which will automatically inherit all the projects for that tag, and manual, where we can specify our own set of projects (such as "Featured", "Staff Picks", etc) and manually order them how we'd prefer.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.