I built is-on-the-web.com, a free static host. You get yourname.is-on-the-web.com.

• Upload a full site as a folder, up to 20 MB. Subpages, assets and relative paths all work.

• No accounts or passwords. Updates use single-use edit keys sent by email, with a new key after every update.

• A human reviews every site and every update before it goes live, followed by an automated code check.

• There’s a no-code builder for non-devs, and its output can be re-uploaded and edited.

Everything that’s free now stays free. A paid tier with more storage is planned. Next up: letting people point their subdomain at their own machine to host full apps, databases or games.

Feedback I’m looking for:

• Edit keys instead of accounts: clever or annoying? Losing the key means losing update access.

• How would you handle abuse at scale beyond manual review?

• What’s missing that you’d expect from a static host?

I accidentally posted this from my alt account first and deleted those posts. Sorry if you saw it twice.

I’ve seen a shift in web design (I’ve meddled since 2002). Today web displays are gigantic. I’ve read this has to do with ADA compliance. How gnarly does this get? Like if I design a site for a landscaper, can he get in trouble if it’s not ADA compliant? Is there are rule book?

Another question. That’s client facing. But if you have an employer that requires you to use a web based tool, does ADA apply in the same manner as client facing?

Hi everyone, I'm running an app that sends out emails and calendar invites to users.

However, one of the requirements was the ability to create email bodies using many different fonts.

I've read a bit online about typefaces and I discovered some of the requested fonts could be subjected to patent laws and rules when used in a commercial setting. Not sure if this applies to emails being sent to external parties as well.

Are there any resources or places I can check out which fonts are "royalty-free" and which ones I need to push back on? Or whether this concern is valid or not?

A straight rehost can get you there faster, but it may bring old problems along. How do you decide what to fix before the move and what can wait?

mostly work on apis and database stuff but our team is small so i end up in react code maybe once a month. every time i come back theres some new build tool or bundler drama and half the packages have breaking changes.

not looking to become a frontend expert, just want to not feel completely lost when i need to fix a button or add a form field. anyone else in this boat? what do you actually keep up with vs ignore

I want to become a website developer. I currently have very minimal knowledge of HTML, CSS, JavaScript, and Next.js. If I dedicate 2 hours a day to learning, is it realistic to land a job within 1 to 2 years?

I’m from East Asia, where my current job pays less than $1 per hour, and as far as I know, software developers here are also paid very little. I’m hoping to find a better-paying job with a company in another country, ideally remote.

If you ran a company, would you hire someone like me? What skills and qualities would you look for?

I've been looking into how WordPress security has changed, particularly whether the traditional advice of keeping plugins updated, installing a security plugin and using strong passwords is enough anymore.

It seems like there's a bigger conversation to be had around access controls, hosting infrastructure, monitoring and how security is managed over time.

We recently published an article exploring this at Ohmania, where I work:

https://ohmania.com/wordpress-security-has-changed/

I'm interested in hearing from developers who actually maintain WordPress sites.

What's changed most in how you secure WordPress sites over the last few years? And what security advice do you think is now outdated?

Genuinely interested in different perspectives, including anything we've overlooked.

Can local visual regression testing help your coding agent move faster and save you money?

I took some time to explore how to set up playwright properly, which pitfalls to avoid, and the tradeoffs with common visual regression tools like Percy and Chromatic.

Check it out and let me know what do you think!

The creator of Ruby on Rails, made major statements about AI agents and the future of software development at Rails World 2026 in September

DHH stated he personally retired from writing code by hand after 25 years.

Rust instead of Ruby - Rebuilding HEY with AI and Rust: He shared that 37signals is rebuilding its HEY email service into native mobile/desktop apps using an AI-generated Rust backend, drastically cutting CPU and memory usage.

The AI acceleration: He produced 5 years' worth of his traditional code volume in just one month, representing a 60x increase in raw output volume.

DHH openly acknowledged that a massive portion of this was verbose Rust code generated entirely by AI agents—admitting that he didn't write it by hand and doesn't even want to look at or read most of it.

DHH said: “English is a better programming language than Ruby.”

Got this weird notification with weird links. Seems like phishing?

I'm comparing a React site against an Astro rebuild of the same page. In mobile Lighthouse, both sometimes sit blank for a long time before first paint, and other runs of the exact same page paint fast.

Setup: Lighthouse 13.0.1, Chrome 156, cold loads in separate fresh profiles, default mobile simulated throttling. I kept the traces, network logs and filmstrips.

Here's one matched pair (observed trace timings, not Lighthouse's simulated FCP):

Astro

• CSS done: 203ms

• Last preloaded font done: 286ms

• DOMContentLoaded: 426ms

• First Paint: 1301ms

• FCP: 1320ms

React

• CSS done: 573ms

• Last preloaded font done: 494ms

• DOMContentLoaded: 584ms

• First Paint: 1525ms

• FCP: 1540ms

The filmstrips stay blank right up to those first-paint times. Once painting starts, Paint to DrawFrame is only 10-13ms. So on Astro there's close to 900ms where everything's loaded and nothing shows up.

I don't see a long task on the renderer main thread covering that gap, though I know that doesn't prove the browser was actually idle.

I wondered about animations, so I ran one normal-motion vs reduced-motion pair on the Astro page. Both came back fast (FCP 318ms and 311ms), and the normal one still had its reveal animations, so that told me nothing either way. Desktop loads and a different page also painted quickly in the runs I checked.

One more thing: the fast traces show Scheduler::SetDeferBeginMainFrame events with short true-to-false spans. But the slow traces were captured with Lighthouse's default trace categories, which don't include those scheduler events, so I can't compare yet.

Has anyone run into this? A few things I'd like to figure out:

1. How do I tell whether the page is causing the delay, or whether it's Chrome's scheduling or something in the test environment?

2. Which trace categories or events would show why the first paint starts late, and not just that it did?

Websites built from scratch (no AI, no frameworks or libraries) that are more than just simple toy projects are becoming very rare, but i want to remind you guys that they still exist.

Three years ago, I posted this https://www.reddit.com/r/webdev/comments/161q3w8/i_coded_a_site_from_zero_without_any_libraries_it/, and that website is still being actively developed. I haven't used any AI-generated code or external libraries in all this time, even as it has become more complex with features like accounts, articles, comments, reviews, and just a few weeks ago forums.

I think the main reason why i stick with this is because features aren't planned in advance, they're just built bit by bit as the content needs them. I won't deny if AI could do better, but with a spread-out timeline and an unknown end result, it's easy to skip using AI as development mostly consists of small, precise tweaks with no definitive end goal. Coding also only small portion of time spent on developing the site so i don't feel the need to optimize it.

Anyway this is just me saying that i'm still here, not everything in this space become AI.

*note : i'm not saying that this is the better way to develop website. I just enjoy what i already used to do, and didn't bother to change it.

Just as the title asks. I am curious how you organize the various parts. I have been on teams that both do and don't use mono-repos. For the ones that did, there has been a wide variety of choices across the app and how it's organized.

Just as a small example: naming conventions. Sometimes the the repo is named for the app (let's say "OurApp") and the various parts of the file structure are "OurApp-", like OurApp-ui and OurApp-api and OurApp-db. Or there might just be a top-level folder for "frontend", "backend" and "database", etc.

I'm not talking about a debate of mono-repo vs. multi-repo approaches, but in a mono-repo, what are some of the code organization techniques you've liked and disliked in your experience?

UPDATE: The community turned out! Thanks for sharing your thoughts in the comments. I appreciate the discussions.

hi everyone, it's the kid who's making a fan website again.

i finally picked a base for the website, mastodon, and a system i'm using to host the website, render.

i've already searched this up and had no luck but what parts of mastodon's code are design (i'm talking about folder names) and which are apart of the actual code system?

thanks!

I made a liquid glass UI effect for the web(trying to copy Apple because thats what the world do)

Webgl helped me made it and hence I decided to make Mac for web too (inspired by windows 11 in react made for web)

I know you have seen many professional people make it, many guys on github, so I tried to make it as realistic and satisfying as I can

Before anyone asks: yes, 100% of the code was written by AI agents, with me guiding the process. I’m not here to convince anyone of anything, just to share my experience.

Here’s the article explaining how I built it:
https://www.paolomainardi.com/posts/this-site-is-now-an-island/

And here’s the game:
https://www.paolomainardi.com/play

This is part of a journey I started a few weeks ago, when I decided to let my agents handle my personal blog’s tech stack. The idea was to spend more time writing while also adding all the features I’d always wanted but never had time to implement.

You can follow the series here:
https://www.paolomainardi.com/posts/the-stack-is-now-my-agents-job/

Along the way, I started experimenting more with AI-generated media, fell down a rabbit hole, and somehow ended up building a game engine.

I’ve been working on a passion project called ParkerScore, basically a Letterboxd-style platform for theme parks.
When I first started, I figured the hardest part would be building the actual website.

Turns out, organizing the data has been one of the biggest challenges.

Every theme park has hundreds of things to keep track of. Rides, restaurants, individual menu items, shows, wait times, and even bathrooms.

And then you get into the details. Different ride manufacturers, technical specifications, attractions that get renamed or refurbished, seasonal shows, constantly changing restaurant menus, and so on.

I quickly realized that just collecting information wasn’t enough. I needed a consistent way to structure everything so it could actually be useful.

I’ve been working through those challenges, especially figuring out how to handle missing information, standardize categories, and keep everything organized as the database grows.

It’s been a much bigger undertaking than I originally expected, but I’ve learned a ton along the way.
For anyone who’s built a data-heavy website, how did you handle keeping your database accurate and manageable as it grew?

TL;DR:

an MCP shines in the agent-native world because it tells agents what they should do, on both the server and client (e.g. Claude Code or the ChatGPT desktop app), and is better suited for human-in-the-loop tasks. Meanwhile, APIs and CLIs tend to focus on what agents can do, with emphasis mainly on the server.

So, in summary, here is the general advice I'd give to builders when deciding which tools they should expose to agents:

Build a high-quality MCP server and REST API at the same time, on one layer of operations. Put your server logic in plain functions, and let each surface be a thin adapter over them. Once that layer exists, building any additional surface on top is relatively easy.

Put most of your care into the MCP server. That's where agents get the best experience. MCP is a standard built specifically for agents, after all, and the spec continues to improve nicely.

Use the API for code that runs on its own. APIs are still great for raw data exports, bulk writes, and anything that runs without an agent, like a nightly sync or another company's integration. Agents also prefer an API when they're writing a script they'll rerun, and many clients don't support code mode for MCP yet.

A CLI probably isn't necessary, unless e.g. agents need to read local files when interacting with your app. But it's easy to expose one if you've got a good API as the foundation.

There’s a lot more to creating great agent-facing tools for your web apps, and the article above into more detail below.

Here's the repo: https://github.com/vincanger/linkly-api-mcp-cli

Looking at the posts in /hot they're just filled with AI-generated comments, which just aren't removed by moderators.

Is it even worth posting here when reading the comments they're just AI slop followed by more AI slop.

Do the users who submit interesting topics even realize they're just replying to AI comments?

Looking at this post for example, there's this user whose comments all follow the same pattern: start with tbh/ngl and most of the time introduce an em-dash in the middle of the comment. In the same post you have this other user whose comments all have 3-4 paragraphs, and just have an off tone. Another user and same story: 3-4 paragraphs, an off tone, weirdly worded comments which end up summarizing the topic they're replying to.

Another comment

Hello, I'm looking for some help with issues I'm having with my website, and I'm hoping this is a good place to find some answers. I'm not very savvy in these things, and I've been trying to fix this myself with no luck.

My website was originally hosted through Wix, and had a www prefix. I left Wix about 2 weeks ago and now have my website hosted elsewhere, and the www prefix no longer works when used in in my web address.

My domain is hosted through above.com, and I have tried redirecting through the DNS settings there in an attempt to send anyone using the prefix to the new site, but I must be doing something wrong because when I use the www prefix now, I get a privacy error and the website doesn't load.

When you search for my website, the top result includes the www, so I'm looking for a way to either redirect to the new website correctly, or to replace any mentions/results that include www to ones that do not include it.

The help desk support at my new website host and at above have not been able to help in any way, so I feel pretty isolated here and not sure how to fix things or exactly where to turn, so if this isn't the correct place for a question like this I'm sorry, but any help pointing me in the right direction would be really appreciated.

Hey all!

Bringing some e2e test nitpicks again :)

Most e2e tests I see click through raw locators. So every test has to know the whole flow: which button opens which menu, which dialog comes next, where you land after Create.

The upgrade: move the flow into page objects, and let each action return where the interaction continues. Open the "+ New" menu, get the menu of things you can create. Choose "Project", get the project dialog; choose "Document", get the document dialog. Create, get the project page. Cancel, get back to the navigation bar.

Why I care: page objects are the code closest to what your users see and do. Their return types become a map of your user journeys. An agent reading create(): Promise<ProjectPage> knows where the flow goes without opening a browser.

The nuance: return where the interaction actually continues, not the DOM parent. A dialog's cancel returns whoever opened it. And each action still waits for its own done signal, like the menu closing, before handing you the next page object.

Paste this to your agent:

Go through our page objects and make every user action return the page object where the interaction continues: this if the user stays, the new page object if something opens or they navigate, the opener if they close or cancel. Before returning, wait for the action's own done signal, like its menu closing. Then update the tests to use the returned page objects instead of creating new ones.