DEV Community: Anders Björk

EV home charger site

Anders Björk — Tue, 20 Oct 2026 09:09:57 +0000

A while ago I created a Swedish site called Laddboxguiden where you can browse and compare different EV home chargers. The site is using a nocode tool called Spreadsimple and I love how quick and easy it was to get this site up and running. I've experimented with quite a few website builders and nocode tools over the years, but SpreadSimple is one of those tools that really surprised me with how simple it is to use. It doesn't try to do everything, and I think that's actually one of its biggest strengths. Instead of overwhelming you with hundreds of settings and complicated workflows, it focuses on making it incredibly easy to turn a Google Sheet into a fully functional website. For someone like me who enjoys building small websites and experimenting with different ideas, this is a pretty fantastic approach. I don't necessarily want to spend weeks developing a website every time I come up with a new idea. Sometimes I just want to see if something works, get it online, and improve it along the way. That's exactly where SpreadSimple shines, and it's the main reason I decided to use it for this particular project.

The idea behind Laddboxguiden was pretty straightforward. There are lots of different home chargers for electric vehicles on the Swedish market, and figuring out which one to buy isn't always easy. Different chargers have different features, charging capacities, connectivity options, and prices. Some support dynamic load balancing, others have different smart features, and some are simply better suited for certain installations. I wanted to make it easier to get an overview of the available options without having to jump between dozens of manufacturers' websites. A website where visitors could browse different chargers, see their specifications, and narrow down the alternatives based on what they were looking for. Normally, building something like this would require a fair amount of work. You would need some kind of database to store the products, a way to manage the content, and a frontend that displays everything nicely. You would also need to implement features like filtering, searching, and sorting. None of these things are particularly groundbreaking from a technical perspective, but they all take time to build, test, and maintain. With SpreadSimple, most of that functionality is already there, which meant that I could spend more time focusing on the content and less time worrying about the technical side of things.

The whole concept behind SpreadSimple revolves around Google Sheets, which essentially becomes the content management system for your website. Instead of logging into a traditional CMS and creating individual product entries, you manage everything in a spreadsheet. Each row represents an item, and each column contains a particular piece of information. For a website about EV chargers, you might have columns for the manufacturer, product name, price, charging capacity, connectivity, load balancing, images, descriptions, and links to retailers. Once you connect the spreadsheet to SpreadSimple, the platform reads the information and uses it to create your website. What I particularly like about this approach is that Google Sheets is something most people are already familiar with. You don't need to learn an entirely new system for managing your content. If you know how to add a row, edit a cell, and organize information into columns, you're already most of the way there. And since it's Google Sheets, you can also take advantage of formulas, sorting, and other spreadsheet features to organize your data before it's displayed on the website. It's a remarkably simple concept, but it makes a lot of sense for websites that are built around collections of products, businesses, properties, or other types of structured information.

Getting started with SpreadSimple is refreshingly straightforward. You can choose one of the available templates, connect an existing Google Sheet, or use its AI website creator to generate a starting point. If you choose the spreadsheet approach, you simply provide the link to your Google Sheet, and SpreadSimple generates a website based on the information it contains. From there, you can start customizing how everything looks and decide which information should be displayed in different parts of the website. One of the central features is something called column mapping, which basically means connecting columns in your spreadsheet to elements on the website. For example, you might have a column called "Product Name" in your spreadsheet. You can map that column to the title element in SpreadSimple, and the product names will automatically appear as titles on your website. The same applies to images, specifications, descriptions, prices, and buttons. You don't have to follow a particular spreadsheet structure either, which gives you quite a bit of freedom to organize your data in whatever way makes the most sense for your project. Once you've mapped everything correctly, SpreadSimple takes care of displaying the information in a consistent layout, and you can start experimenting with the available design options.

One of the things that makes this approach especially useful is how easy it becomes to update the website later. Let's say a manufacturer releases a new home charger that you want to include in your comparison. Instead of creating a new webpage from scratch, you simply add another row to your Google Sheet and fill in the necessary information. SpreadSimple then picks up the changes and displays the new product on the website. The same thing applies when you want to update a price, change a product description, or correct a specification. You edit the information in the spreadsheet, and the website reflects those changes after the data is synchronized. For a website that displays information about many different products, this is a huge advantage, especially if you're managing everything yourself. It also means that the content is kept separate from the design. You can work on the data without having to worry about accidentally messing up the layout of your website. Likewise, you can experiment with the design without touching the underlying product information. I think this separation is one of the reasons SpreadSimple feels so easy to work with. Instead of having everything mixed together in a complicated editing interface, you have one place where you manage the content and another where you control how that content is presented.

Another feature I really appreciate is the built-in filtering and sorting functionality. This is particularly important for a comparison website like Laddboxguiden because visitors usually have some idea of what they're looking for. Someone might want a charger that supports dynamic load balancing, while another person might care more about charging capacity, connectivity, or price. Without filters, visitors would have to scroll through every product and manually compare the specifications, which isn't a particularly enjoyable experience. With SpreadSimple, you can create filters using columns from your Google Sheet. You select which columns should be filterable, and the platform generates the corresponding controls on your website. The available filter values are based on the information in the spreadsheet, so you don't have to create every filtering option manually. There are also different types of filters, including options for working with numerical ranges, which can be useful when comparing products by price or other measurable attributes. Search and sorting functionality make it easier for visitors to find particular products or organize the results according to their preferences. These might sound like fairly basic features, but they're exactly the kind of things that can take a surprising amount of time to implement when building a website yourself. Having them available without writing any code makes SpreadSimple particularly attractive for directories and comparison websites.

Something else that works well is the way SpreadSimple handles individual product pages. You can display products in a grid or list on the main page, with each item showing the most important information. Visitors can then open a dedicated details page to see a more complete description, additional images, specifications, and other relevant details. For Laddboxguiden, this type of structure makes a lot of sense because the main page can focus on helping people discover different charging stations, while the individual product pages provide more detailed information about each model. It's a nice balance between keeping the overview simple and still being able to include a reasonable amount of information. SpreadSimple also gives you options for customizing the URLs of individual pages, which is useful if you want clean and descriptive links instead of random identifiers. Because the product pages use the same underlying layout, you don't have to design every page individually. That consistency is something I appreciate, both from a maintenance perspective and for the visitor experience. When you add a new item to the spreadsheet, it can follow the same structure as the products that are already there, making it much easier to grow the website over time without creating additional design work.

Of course, the actual design is another important part of building a website, and this is an area where SpreadSimple takes a slightly different approach compared to more advanced website builders. You get a selection of layouts and design settings that allow you to change the appearance without having to work with HTML or CSS. You can customize colors, images, card layouts, headers, and various other elements to make the website feel more like your own. However, I wouldn't say that SpreadSimple gives you unlimited creative freedom, because it definitely doesn't. If you're used to building fully customized websites, you'll eventually come across things that you can't change exactly the way you want. But I actually think that limitation can be a good thing. One of the biggest problems with many website builders is that they give you so many customization options that you end up spending far too much time adjusting tiny details. You move something a few pixels, try another font, change the spacing, and suddenly you've spent an entire afternoon working on something that probably doesn't matter very much. With SpreadSimple, you can make the website look good without getting lost in endless design decisions. For a directory or comparison website, the content is usually much more important than having a completely unique design anyway. The goal is to help visitors find the information they need, and as long as the website is clean, easy to navigate, and works well on mobile devices, that's already a pretty good starting point.

Another thing worth mentioning is that SpreadSimple takes care of hosting, which removes quite a few of the technical responsibilities that normally come with launching a website. You don't have to set up a server, install a content management system, configure a database, or worry about keeping plugins updated. The platform hosts the website for you, and you can connect your own domain name if you want to use a more professional address. SSL is handled by the platform as well, so that's another thing you don't have to configure separately. This might not sound particularly exciting, especially if you're already comfortable working with hosting providers and traditional website platforms, but it removes a lot of the small tasks that can slow down a project. When you're experimenting with a new idea, reducing that kind of friction makes a big difference. I think it's easy to underestimate how much time is spent on things that have very little to do with the actual purpose of a website. Setting up infrastructure, fixing configuration issues, updating software, and troubleshooting compatibility problems can all be necessary when building a traditional website. With a hosted nocode platform like SpreadSimple, most of those concerns disappear, allowing you to focus on what you're actually trying to create.

I also like that SpreadSimple isn't limited to simple directories and comparison websites. Although the Google Sheets approach is particularly well suited for listings and catalogs, the platform includes functionality for creating online stores as well. You can add shopping carts, order forms, payment integrations, product variations, and other ecommerce features, depending on the type of website you're building and the plan you're using. There are also integrations for analytics, automation, and other services, which can be useful if you want to connect your website to additional tools. For Laddboxguiden, the main goal is to help people browse and compare products rather than to operate a traditional online store, but it's interesting that the same platform can be used for a variety of different projects. You could build a directory of local businesses, a real estate listing website, a collection of digital resources, a job board, or a simple product catalog. As long as the content can be organized into rows and columns, there's a reasonable chance that SpreadSimple could be a good fit. That's probably one of the reasons I find the tool so interesting. It's not necessarily about building one particular type of website, but about being able to turn structured information into something useful on the web with very little effort.

There are also some options for search engine optimization, which is obviously important if you want people to discover your website through Google. SpreadSimple offers settings for things like page titles, meta descriptions, and URLs, along with support for connecting analytics and webmaster tools. These features are useful, especially for a content-driven website where organic search traffic could eventually become an important source of visitors. That said, I wouldn't expect SpreadSimple to provide the same level of SEO flexibility as a fully customized WordPress website or something built from scratch. There are naturally some limitations when you're using a hosted platform with a predefined structure, and you don't have complete control over every technical aspect of the website. If your project depends heavily on advanced technical SEO, highly customized page templates, or a large amount of editorial content, it's worth looking into those limitations before committing to the platform. For a relatively straightforward product directory, however, the available functionality may be perfectly sufficient. I also think it's worth remembering that SEO isn't just about the technical platform. Having useful, well-organized, accurate information is at least as important, and a website that makes it easy for visitors to find and compare products already has a good foundation to build on.

One limitation that becomes apparent when you start working with SpreadSimple is that it isn't intended to replace a fully custom web application. If you wanted to build a highly specialized comparison tool with complicated calculations, unusual user interactions, and advanced dynamic functionality, you might eventually run into problems. There are ways to extend the platform with custom styling, scripts, and integrations, but you're still working within an existing system rather than having complete control over the underlying application. This is the trade-off with most nocode tools, and it's something I think you have to accept from the beginning. You're giving up some flexibility in exchange for being able to build something much faster and with less technical effort. For certain types of projects, that exchange is absolutely worth it, while for others it might not make sense at all. Personally, I think SpreadSimple works best when you have a relatively clear idea of how your information should be structured and displayed. If your website is essentially a collection of items that people need to browse, search, filter, and learn more about, the platform covers a lot of what you need. If the entire idea depends on functionality that SpreadSimple doesn't support, trying to force it into the platform would probably create more problems than it solves.

There's also an interesting trade-off when using Google Sheets as a database. On one hand, it's incredibly convenient because you can add new information, reorganize your content, and make changes without touching the website builder itself. On the other hand, you need to be a little disciplined about how you structure your data. For example, if you're going to use a particular column for filtering, it's important that the values are consistent. If one product says "WiFi", another says "Wi-Fi", and a third says "Wireless", you might end up with several different filter options for essentially the same feature. The same applies to prices, product categories, charging capacities, and other specifications. You also need to think about how missing information should be handled, because not every manufacturer provides exactly the same specifications in exactly the same format. This isn't really a problem with SpreadSimple itself. It's simply something that comes with using structured data, and you'd have to think about it regardless of which platform you used. Still, it's worth taking the time to organize your spreadsheet properly from the beginning. For a comparison website, the quality of the underlying data ultimately determines how useful the website becomes. You can have the nicest design in the world, but if the product information is incomplete, outdated, or inconsistent, visitors aren't going to get much value from it.

This also brings me to something that I think is important to mention when talking about nocode tools in general. Just because a website is easy to build doesn't necessarily mean it's easy to run successfully. SpreadSimple can take care of a lot of the technical work, but it can't automatically make your website useful or interesting. For a project like Laddboxguiden, the real work is collecting accurate information about different EV chargers, deciding which specifications matter, presenting everything clearly, and keeping the content up to date. New products are released, older models disappear, prices change, and manufacturers introduce new features. If you want the website to remain useful, you have to keep working on the information behind it. What SpreadSimple does is make that process considerably less complicated. Instead of spending time maintaining a custom database and updating individual product pages, you can focus on the spreadsheet and the information it contains. And if you eventually want to automate parts of that process, Google Sheets provides a convenient starting point for connecting other tools and workflows. I wouldn't necessarily recommend trying to automate everything from the beginning, though. Sometimes the simplest solution is to maintain a well-organized spreadsheet manually, especially when the website is still relatively small.

Another advantage of this setup is how easy it is to experiment. Because the website is based on a spreadsheet, you can try different ways of organizing information without making major changes to the underlying structure. You might start with a fairly basic product catalog and later decide to add more detailed specifications, new categories, or additional filtering options. As your understanding of what visitors are looking for improves, you can gradually adjust the content and presentation. This makes SpreadSimple particularly suitable for small projects and side projects where you might not know exactly what the final website should look like from the beginning. With a more traditional development approach, you might feel pressured to plan everything carefully before starting, especially if changing the database or frontend later would require additional development work. SpreadSimple makes the process feel much more flexible because so much of the website is driven by the spreadsheet. You can start with something relatively simple, publish it, and make improvements over time. I think this is one of the most appealing aspects of nocode tools in general. They make it possible to test ideas without committing a huge amount of time or money before you even know whether anyone is interested.

Pricing is another thing worth considering when deciding whether SpreadSimple is the right choice for a project. The platform offers different plans, and the features available depend on which one you're using. There's a free option for getting started, while more advanced functionality, higher limits, and certain customization options require a paid subscription. I won't go into the exact prices here because they can change, but I think it's important to look at the long-term cost rather than just how inexpensive it is to launch the website. A subscription can seem like an unnecessary expense when you're technically capable of building something yourself, but there's also value in not having to maintain everything. Hosting, updates, functionality, and a lot of the technical infrastructure are handled for you. On the other hand, if you're planning to run a large number of websites or need features that require more expensive plans, those subscription costs can add up. As with most tools, it comes down to what you're trying to accomplish and how much time you're willing to spend on development and maintenance. For a small directory or comparison website, I think the convenience can easily justify the cost, particularly if your alternative is spending several weeks building a custom solution.

One thing I find interesting about SpreadSimple is that it represents a slightly different way of thinking about websites. Traditionally, you start by choosing a website builder or CMS, creating pages, designing layouts, and then filling those pages with content. SpreadSimple almost reverses that process. You start with the information, organize it into a spreadsheet, and let the platform turn it into a website. For certain types of projects, that approach feels much more natural. If you already have a spreadsheet containing hundreds of products, businesses, events, or other entries, you might be surprisingly close to having everything you need to publish a website. You don't necessarily need to import the information into a complicated system or manually recreate it somewhere else. You can use the data you already have and build the presentation around it. I think there's something quite appealing about that simplicity, especially at a time when many tools seem to become more complicated with every new feature they introduce. SpreadSimple takes a familiar tool that millions of people already use and turns it into something much more powerful, without requiring users to become developers.

Looking back at the process of building Laddboxguiden, what stands out to me most is how little friction there was between having the idea and getting a working website online. That's something I value a lot, because I tend to get ideas for different websites and online projects quite frequently, and I know how easy it is for those ideas to remain unfinished. Sometimes the biggest obstacle isn't that the project is particularly difficult. It's simply that there are too many small things to take care of before you have anything to show for your work. You need to choose a tech stack, set up hosting, design the interface, build the database, implement the functionality, and make sure everything works together. By the time you've finished all of that, some of the initial excitement might already be gone. SpreadSimple removes a large part of that process. You still have to create the content and make decisions about how the website should work, but you can get to the interesting part much sooner. For me, that's probably the biggest selling point. It makes building certain types of websites feel more like putting together a useful resource and less like managing a software development project.

Would I use SpreadSimple for every website I create? Definitely not. There are plenty of situations where I'd prefer WordPress, another nocode platform, or a completely custom solution. But that's not really a criticism of SpreadSimple, because I don't think it's trying to replace all those alternatives. It has a fairly specific approach to building websites, and when your project fits that approach, it can be incredibly efficient. I also appreciate that it doesn't require you to become an expert in the platform before you can create something useful. The basic concept is easy to understand, the connection to Google Sheets makes content management straightforward, and many of the features you'd expect from a directory or catalog website are available without additional development. There are limitations, of course, and it's worth understanding them before getting too invested in a project. But for someone who wants to turn a spreadsheet into a searchable, filterable, publicly accessible website, I think it's a tool worth exploring.

For me, Laddboxguiden has been a nice example of how much you can accomplish with a relatively simple setup. The website doesn't need a complicated backend or a custom-built content management system to serve its purpose. It needs organized product information, a clean interface, and a convenient way for visitors to browse and compare different EV chargers. SpreadSimple provides the foundation for all of that, while Google Sheets makes it easy to manage the content. I still need to put effort into researching products, improving descriptions, and keeping the information relevant, but those are exactly the things I'd rather spend my time on. That's what I like most about this kind of tool. It doesn't eliminate the work involved in creating a useful website, but it removes a lot of the unnecessary technical work that can get in the way. If you have an idea for a directory, product catalog, comparison website, or another project built around structured information, SpreadSimple is definitely worth a look. It might not be the most powerful website builder out there, but sometimes having the right features and being able to launch quickly is much more valuable than having complete control over every little detail.

PHP, markdown and no dependencies

Anders Björk — Mon, 28 Sep 2026 15:22:49 +0000

I’ve been thinking about building a travel site called romantic-weekend.com, focused on romantic weekend destinations in Europe and the United States. The basic idea is deliberately simple: people search Google for things like “romantic weekend in Paris”, “romantic weekend in Rome”, “romantic getaway in Napa Valley” or “romantic weekend in France”, and they land directly on a highly focused destination page. The site would contain broader landing pages for regions and countries, such as Europe, France, Italy and the United States, alongside individual destination pages for places like Paris, Venice, New York and San Francisco. Because I expect most visitors to arrive through Google rather than navigate from the homepage, each destination page needs to work well on its own, while still belonging to a clear overall structure.

The more I thought about the technical side of the project, the less interested I became in using a traditional CMS. Romantic-weekend.com is not meant to be a complicated application. It does not need user accounts, comments, dashboards, workflows, permissions or a complex database model. At its core, it is an editorial website made up of structured pages. That made me wonder whether the simplest possible architecture might also be the best one: PHP for the site engine, Markdown files for the content, the filesystem for the hierarchy and ordinary PHP templates for the output.

I imagine the content directory looking something like this:

/content
    /europe
        index.md
        /france
            index.md
            paris.md
            nice.md
            annecy.md
        /italy
            index.md
            rome.md
            venice.md

    /usa
        index.md
        /california
            index.md
            san-francisco.md
            napa-valley.md
        /new-york
            index.md
            new-york-city.md

The nice thing about this structure is that the filesystem itself describes the site. A file at /content/europe/france/paris.md naturally becomes the page /europe/france/paris/, while /content/europe/france/index.md becomes /europe/france/. I don’t need a database table that says Paris belongs to France and France belongs to Europe, because the location of the file already tells me that. I also don’t need to repeat the URL, the parent page, the country and the region in every content file. PHP can derive most of that automatically from the path.

A Paris page could then be very simple:

---
title: "Romantic weekend in Paris"
description: "Plan a romantic weekend in Paris."
image: paris.jpg
---

# Romantic weekend in Paris

Paris is one of the classic destinations for a romantic weekend.

## Where to stay

...

## Romantic things to do

...

## Where to eat

...

The Markdown file only describes the content. PHP handles everything around it: the URL, breadcrumbs, metadata, templates, related destinations, canonical URLs, sitemap entries and navigation. That separation is important to me because I want the content files to stay readable even if the site becomes quite large. If romantic-weekend.com eventually contains hundreds of destinations, I still want adding a new one to be as simple as creating a new Markdown file in the correct directory.

For example, adding Lyon should ideally mean creating /content/europe/france/lyon.md and nothing else. The France page should automatically discover it. The sitemap should automatically include it. The breadcrumb should automatically become “Europe › France › Lyon”. A “More romantic weekends in France” section should automatically be able to link to it. The system should understand the hierarchy without me having to maintain the same information in five different places.

That is also why I like the idea of country and region pages being proper content pages rather than just technical category archives. /europe/ could target searches around romantic weekend destinations in Europe. /europe/france/ could target romantic weekends in France. /usa/california/ could target romantic weekend getaways in California. These pages could contain their own editorial introductions, recommendations and internal links, while PHP automatically inserts the relevant child destinations. This gives the site a clear SEO structure without forcing visitors to navigate through every level before reaching the page they actually want.

My first instinct for handling Markdown was to use a mature package such as league/commonmark. That would certainly work, and for many projects it would be the sensible choice. But romantic-weekend.com made me question whether I really need a complete Markdown implementation at all. I control every content file myself. There are no users pasting arbitrary Markdown into a form. I do not need to support every edge case in the CommonMark specification. In practice, the editorial content probably only needs headings, paragraphs, bold and italic text, links, lists, blockquotes and maybe images.

That means I could write a deliberately small Markdown parser instead of pulling in a dependency. The distinction matters: I would not be trying to write a standards-compliant Markdown parser. I would be defining a small markup format for this specific website that happens to use familiar Markdown syntax. If the site supports #, ##, **bold**, [links](...) and simple lists, that is the specification. Anything more complicated simply does not belong in the content format unless I consciously decide to add it later.

The same goes for the metadata block at the top of each file. I do not need a complete YAML parser just to read three or four simple values. A lightweight parser that reads key: value lines is probably enough. That keeps the project extremely portable. In the simplest version, the entire runtime dependency stack could be nothing more than PHP itself.

That idea appeals to me more than I expected. The Markdown files become the database. Git becomes the version history. The directory tree becomes the taxonomy. PHP becomes the rendering engine. If I move the site to another server, I copy the project and it works. There is no database dump to import, no CMS installation to upgrade and no long dependency tree that needs to be restored before the site can even render a page.

I would probably still build an index of all the content files rather than recursively scanning the filesystem on every request. A small build command could walk through /content, read the metadata from every page and generate a PHP array containing URLs, titles, file paths, parent relationships and perhaps some tags. That index could then power routing, breadcrumbs, country listings, related destinations and the XML sitemap.

The generated index might contain entries like this:

return [
    '/europe/france/paris/' => [
        'title' => 'Romantic weekend in Paris',
        'file' => 'europe/france/paris.md',
        'type' => 'destination',
    ],

    '/europe/france/lyon/' => [
        'title' => 'Romantic weekend in Lyon',
        'file' => 'europe/france/lyon.md',
        'type' => 'destination',
    ],
];

At that point, routing becomes trivial. PHP receives /europe/france/paris/, finds the matching entry, reads the file, converts the Markdown, passes the result through the destination template and returns the HTML. If performance ever matters, I could cache the fully rendered page and serve that cached HTML directly until the source Markdown changes. The end result would behave almost like a static site while still giving me the flexibility of PHP.

One of the more interesting possibilities is to go slightly beyond ordinary Markdown and add a few site-specific constructs. Internal links, for example, could use identifiers rather than hard-coded URLs. Instead of writing Paris, I could write [[paris]] and let PHP resolve that identifier to the current URL. If I ever reorganize the URL structure, the content would not need to change. The same approach could work for dynamic sections such as [[related]], [[destinations]] or [[hotels]], where PHP replaces the token with a generated component.

That would turn the content format into a tiny domain-specific language for romantic-weekend.com. The Markdown would still be readable as plain text, but it would also be able to express relationships that are meaningful to this particular site. A France landing page might contain its editorial text followed by [[destinations]], and PHP would automatically insert all French destinations. A Paris page might include [[related]], and the engine could select other destinations based on geography, tags or manually supplied relationships.

I also like the idea of storing structured attributes in the content files that are useful for recommendations rather than just presentation. A destination could be tagged as city, food, culture, luxury, beach or countryside, and could have values for best months, typical trip length or general price level. Those fields would make it possible to create useful internal links such as “More romantic city weekends”, “Romantic destinations for autumn” or “Similar destinations to Paris” without manually maintaining those sections on every page.

The main thing I want to avoid is turning this small system into a framework of its own. That would defeat the purpose. If the Markdown parser starts trying to support every corner of the CommonMark specification, I should use a proper Markdown library. If the metadata format starts growing into a complex schema language, I should probably use a real parser. If the site eventually needs multiple editors, workflows, permissions and a large editorial backend, then a CMS may become the right answer.

But for the site I have in mind right now, those problems do not exist. Romantic-weekend.com is fundamentally a collection of editorial landing pages organized into a predictable hierarchy. Most visitors will probably enter through Google on a specific destination page, so the real challenge is not application complexity. It is creating good pages, organizing them sensibly and making the relationships between them useful to both search engines and visitors.

For that problem, I find the idea of a very small PHP system surprisingly compelling. A few classes, a directory full of Markdown files, some templates, a generated index, an XML sitemap and an HTML cache may be all the infrastructure the site actually needs.

There is something refreshing about a system where I can understand the whole thing by opening the project folder. No hidden database structure. No plugin ecosystem. No framework conventions I need to remember. No package that suddenly requires a newer version of another package.

Just files in, HTML out.

For romantic-weekend.com, that might be exactly the right level of technology.

Finding real purpose with impact mapping

Anders Björk — Sun, 17 May 2026 16:48:00 +0000

I’ve always had a soft spot for structured thinking tools, but there’s one that stands out when it comes to bringing real clarity into messy product work: Impact mapping.

Most projects don’t actually fail because teams can’t build things. They fail much earlier, at the point where nobody has really agreed on why they are building anything in the first place. There is often a surface-level purpose, usually something like “replace legacy system X” or “build a new app for customers”. That kind of goal sounds concrete, but it hides a bigger problem: it describes activity, not value. It explains what we are doing, not what we hope will change.

What’s usually missing is the real purpose. The uncomfortable but necessary question: what do we want this investment to give us in return?

That question is where things start to get interesting, and also where many teams accidentally skip ahead. Because the real purpose is rarely about the system itself. It lives one level above it. It could be something like reducing customer effort, increasing conversion, lowering support dependency, improving retention, or enabling faster decisions. And importantly, it has to be something that matters outside the delivery team. If the purpose only makes sense inside IT or product, it tends to drift into output thinking again.

Finding that purpose is less about creativity and more about structured conversation. It usually starts with pulling the right people into the same room, especially those who understand the business side, not just the technical constraints. Then it becomes a process of asking slightly uncomfortable follow-up questions. What changes if this succeeds? Who benefits? Why does that matter? And if we achieved that, what would that enable next?

It helps to keep stripping away layers until you reach something that still feels meaningful without referencing the solution. If the discussion keeps returning to features or systems, it is often a sign that the real goal is still hiding underneath.

Once that purpose starts to feel real, the next challenge is making sure it is actually something the product can influence. A purpose that is too broad, like “increase company profitability”, is not useless, but it is too far removed from day-to-day design decisions. On the other hand, a purpose that is too narrow, like “reduce number of clicks in form X”, risks becoming local optimization without strategic relevance.

The sweet spot is when the purpose is clearly connected to business outcomes, but still reachable through changes in user behavior and experience. It should feel like something the product can genuinely move, even if it does not fully control it.

From there, the thinking naturally shifts into mapping. This is where Impact mapping becomes especially powerful. You take that purpose and start asking who needs to act differently in order for it to happen. Not abstract personas, but real actors with intentions. Customers, internal users, partners, support staff. Then you ask what behaviors from those actors would actually create the desired outcome.

This is where things start to become measurable, because behavior is observable. Not opinions, not intentions, but actions. If customers complete a purchase without contacting support, that is measurable. If users return weekly instead of dropping off after the first session, that is measurable. If employees resolve tasks without escalation, that is measurable.

The important shift is that success stops being defined by whether features were delivered, and starts being defined by whether real-world behavior changed in the direction of the purpose. That question becomes central: if all this happens, will we be considered successful?

And that is where the most useful measures tend to emerge. Not vanity metrics or isolated activity counts, but signals of actual usage over time. Because real value shows up when people interact with the product in their everyday life, not in a demo, not in a workshop, not in a test environment.

It is in the repeated patterns that meaning appears. Do users come back without being pushed? Do they rely on the product to complete tasks they previously did manually? Do they trust it enough to make it part of their routine? These are the kinds of signals that tell you whether the product is actually doing its job in the world, not just whether it works technically.

When teams get this right, design work becomes less about debating features and more about shaping behavior. Every design decision can be traced back to a chain: this supports this behavior, which contributes to this impact, which serves this purpose. It doesn’t remove complexity, but it gives it direction.

And that is why Impact mapping keeps feeling so valuable. It doesn’t pretend to simplify reality. It just makes sure everyone is aiming at the same version of it.

A quiet idea taking shape

Anders Björk — Sun, 17 May 2026 15:51:20 +0000

There’s something special about the feeling right after registering a new domain. That mix of anticipation and possibility. This time it became vaggvisor.com (Swedish word for lullabies), and even the name alone starts triggering a whole stream of ideas. It feels like it could become something warm, calm and a bit nostalgic, but also modern and genuinely useful.

Right now it’s all very bare bones. A simple one-pager, mostly just to signal that something is coming. A bit like placing a sign on an empty plot of land: “Something nice will be built here.” But even at this early stage, the ideas are already branching out into what it could become. A collection of classic lullabies? Original recordings? Lyrics, sheet music, maybe even tools for building personalized bedtime playlists.

One direction that feels especially interesting is treating each lullaby as more than just a song with audio attached. Almost like a small content experience. That naturally leads to thinking in terms of structured content, and here markdown files start to feel surprisingly powerful. Each lullaby could live as its own markdown file containing the lyrics, metadata like language, mood, tempo, origin, and maybe even references to different versions of the same song. It would keep everything very portable and human-readable, while still being flexible enough to evolve.

From a technical point of view, there’s something appealing about building it from scratch in PHP. Not because it’s the most fashionable choice, but because it would be a good way to deepen skills and stay close to the actual mechanics of how everything works. A simple file-based system where PHP reads markdown files, parses them, and turns them into pages could be enough for a strong start. It would also keep the architecture transparent, which feels right for something that should stay lightweight and calm.

On top of that, Bootstrap could handle the layout without overcomplicating things. A soft, responsive interface with just enough structure to make the content feel intentional, without getting in the way. The focus would stay on readability and mood rather than heavy interaction patterns.

And then the ideas start to get more playful. Each lullaby could include multiple interpretations, maybe different tempos or arrangements depending on context. Not just a static page, but a small adaptive experience. You could even imagine background layers like subtle audio textures or gentle variations in rhythm depending on the time of night or user preference.

Personalization also becomes an interesting layer. A simple account system where parents can assemble bedtime routines, selecting a sequence of lullabies that play in order with soft transitions. It could even allow recording a personal voice message directly in the browser, stored and tied into the playlist. There’s something powerful about the idea of a parent being away but still present at bedtime through something so simple and familiar.

There’s also a more experimental direction where parts of the content could be generated. Not to replace the classics, but to complement them. Mood-based generation like “calm”, “safe”, “nature”, or “space”, producing either variations of melodies or accompanying text. Maybe even ambient layers like rain, wind or soft noise blended underneath.

Visually, it would be just as important to keep things restrained. Slow animations, subtle color shifts, almost imperceptible motion in the background. The kind of interface that doesn’t demand attention but instead lowers the pace of everything around it. Something that feels like it gets quieter the longer you stay.

At the same time, there’s a strong pull toward keeping it simple in the beginning. Starting with a small, carefully curated set of high quality lullabies, focusing on presentation and clarity rather than volume of content. Letting it grow organically based on what actually resonates.

And that brings it back to the technical decisions again. GRAV feels tempting as a file-based system that already solves a lot of structure, but building it in raw PHP has its own appeal, especially for learning. A custom markdown pipeline where content lives in folders, maybe with a simple parser layer, caching, and a clean separation between content and templates. VZY.co sits on the other end of the spectrum, fast and visual, great for getting something polished quickly, but less flexible if the idea grows into something more complex and custom.

There’s also something healthy in not locking everything down too early. Starting simple, testing ideas, and letting the project itself influence the architecture over time. Often what you think you are building changes once it starts to exist in the real world.

So vaggvisor.com is still just a beginning. A quiet surface with potential underneath. And right now that’s enough. A space to experiment with content, structure and code at the same time, and slowly figure out what it actually wants to become.

There’s also a realistic chance it never turns into anything more than this early spark, just another shiny domain that felt full of promise at the moment of registration. History has a way of showing how easily attention drifts, and how many ideas quietly fade once the novelty wears off.

Bedtime stories

Anders Björk — Mon, 13 Apr 2026 22:00:00 +0000

I recently registered the domain bedtimestories.kids and I'm excited about the possibilities, though I'm still figuring out exactly what to do with it. The idea of creating a dedicated space for cozy bedtime stories feels right, especially since this is a format I already love working with.

My initial thought is to write original bedtime stories and publish them on the site. Nothing too complex or overstimulating, just warm, gentle tales that help children wind down at the end of the day. The kind of stories with soft imagery, reassuring themes, and that perfect drowsy rhythm that makes eyelids heavy.

I'm also considering producing audiobook versions of the stories. Having worked with narration before, I know how much the right voice and pacing can add to a bedtime story. There's something special about a spoken story that a child can listen to in the dark, letting the words paint pictures as they drift off to sleep.

For now, I've put up a simple landing page using Carrd, which I've started experimenting with recently. It's perfect for getting something online quickly, and the one page format works well as a placeholder while I plan the real site. But Carrd's limitations are obvious when you're thinking about a content site with multiple stories, categories, and possibly audio players.

That's why I'm planning to build the actual site using GRAV. It seems like a good fit for this project, offering the flexibility I need to organize stories properly, handle media files efficiently, and create a pleasant reading experience without the overhead of a database-driven CMS. Plus, being file-based means I can keep everything simple and focused on the content itself.

I've really come to appreciate working with GRAV for several reasons, and it keeps proving itself as the right choice for my projects.

The flat-file architecture is probably the biggest draw for me. No database to maintain, no MySQL configurations to worry about, no backup complications. Everything is just files and folders, which means I can version control the entire site with Git if I want to. It's straightforward and transparent in a way that feels refreshing after years of wrestling with WordPress databases.

The Markdown-based content system fits perfectly with how I like to write. I can draft a story or article in any text editor, format it with simple Markdown syntax, and drop it into the right folder. No need to log into an admin panel unless I want to. For someone who writes a lot of content across multiple sites, this workflow feels natural and fast.

GRAV's flexibility is another strength. It's lightweight enough to stay out of your way, but powerful enough to handle complex site structures when you need them. I can start simple and add functionality as the site grows, without feeling locked into decisions I made at the beginning. The modular approach with plugins means I only add what I actually need.

The templating system using Twig is clean and logical. When I need to customize something, I'm working with actual code that makes sense, not trying to decipher some proprietary theme framework. And because everything is file-based, I can simply copy a template file, modify it, and see the changes immediately.

Performance is solid right out of the box. Without database queries slowing things down, pages load quickly. For content-heavy sites like my children's story collections, where I want parents and kids to have a smooth, pleasant experience, this matters.

The learning curve was gentler than I expected. The documentation is thorough, and the community, while smaller than WordPress, tends to be helpful and focused. I didn't need to become a GRAV expert to get productive with it.

So why focus on bedtime stories for kids?

Well, bedtime stories are a special part of childhood. They help children slow down after a busy day, relax their minds, and feel safe and close to the person reading to them. A bedtime story can also become a comforting routine that children look forward to every night.

A good bedtime story does not need to be complicated. The best stories often have a simple plot, lovable characters, and a gentle sense of adventure. A little mystery or excitement can keep children interested, but the story should gradually become calmer as bedtime approaches. Stories about animals, magical places, friendly monsters, or everyday childhood experiences are often especially appealing.

The language matters too. Short sentences, repetition, and familiar words make a story easy for young children to follow. A warm rhythm can make the story almost feel like a lullaby, especially when the reader slows down and uses different voices for the characters.

A good ending is perhaps the most important part of a bedtime story. Children should be left with a feeling of comfort and security rather than suspense. The characters might find their way home, solve a small problem, or simply settle down for the night. A peaceful ending helps children make the transition from listening to sleeping.

Most of all, a bedtime story is about connection. The story itself can be wonderful, but the quiet moment of sitting together, listening, imagining, and sharing a few minutes before sleep is what makes bedtime stories so meaningful. A good bedtime story does not just entertain a child. It creates a little world where they can feel safe, loved, and ready to dream.

One-page about Skiathos using Carrd

Anders Björk — Mon, 13 Apr 2026 09:34:38 +0000

I've been experimenting with Carrd.co to build a simple one-page guide to Skiathos, one of my favorite Greek islands in the Sporades archipelago. The tool turned out to be perfect for this kind of project since I wanted something clean and straightforward without getting bogged down in code.

The site opens with a hero image of Koukounaries Beach, that stunning stretch of golden sand backed by pine forest that makes Skiathos so distinctive. I kept the introduction brief, just a few lines about why the island stands out: incredibly accessible beaches, lush green landscapes, and that perfect balance between developed tourism infrastructure and genuine Greek character.

I structured the guide into sections to keep everything on one page without overwhelming visitors. The beaches section was essential, covering everything from the famous Lalaria Beach with its white pebbles and natural rock arch (accessible only by boat) to the more family-friendly options like Vromolimnos and Agia Paraskevi. I made sure to mention Banana Beach for those looking for a livelier scene.

For practical information, I added sections on getting there (flights to Skiathos airport, which has one of the most dramatic runway approaches in Europe, or ferry connections from Volos and Thessaloniki), getting around (rental cars, scooters, or the island bus that connects most beaches), and where to stay. I highlighted both Skiathos Town with its charming old quarter and the quieter options along the southwest coast.

Carrd's simplicity really shone here. The drag-and-drop interface made it easy to add image galleries, embed a Google Map showing key locations, and create a clean, mobile-responsive layout. I used one of their minimalist templates and customized the colors to match the island's palette: deep blues for the Aegean, warm terracotta for the traditional rooftops, and soft greens for the pine forests.

The whole project took maybe two hours from start to finish, and the result is a clean, focused resource that loads fast and works beautifully on phones, which is exactly what you want for a travel guide people might reference while actually on the island.

Looking back at what it took to create a website 20 years ago versus what I just did with Carrd, the contrast is almost absurd.

In 2005, if I wanted to build even a simple one-page guide to Skiathos, I would have been writing HTML by hand in a text editor, probably Notepad or maybe Dreamweaver if I was willing to pay for it. Every <div>, every <table> (because that's how we did layouts back then), every bit of CSS had to be typed out manually. Want to center an image? Good luck with the browser compatibility issues between Internet Explorer 6, Firefox, and whatever else people were using.

And that's just the markup. Getting the site online meant finding a web host, figuring out FTP credentials, uploading files through FileZilla or some similar client, and hoping you didn't break anything in the process. If you wanted to update a single line of text, you had to edit the HTML file locally, save it, re-upload it via FTP, and then clear your cache to see if it actually worked.

Responsive design didn't really exist yet. Mobile web was WAP and flip phones. You built for desktop monitors at 800x600 or 1024x768 resolution and called it a day. If someone tried to view your Skiathos guide on their Nokia phone, they'd get a tiny, barely-readable version of the desktop site.

Image optimization was manual. I would have needed Photoshop or GIMP to resize and compress photos, save them as JPEGs at the right quality level, and hope the file sizes weren't too large for people on dial-up or early broadband connections.

With Carrd, I dragged and dropped. The tool handled responsive breakpoints automatically. Images got optimized on upload. The site was SSL-secured and CDN-hosted without me thinking about it. Form integrations, if I wanted them, were just toggles. The whole thing was live on a custom domain within minutes.

What took specialized knowledge, multiple software tools, and genuine technical skill two decades ago is now something anyone can do in an afternoon with zero coding knowledge. The democratization is remarkable, honestly. But there's also something I miss about that era: the constraint of having to actually understand how things worked under the hood made you a better builder, even if it was slower and more frustrating.

Ramen.tools: Yet another beautiful way to flex your SaaS subscriptions

Anders Björk — Sun, 12 Apr 2026 15:42:26 +0000

Look, we need to talk about our collective addiction to "show your stack" websites. And yes, ramen.tools is absolutely one of them, and yes, I'm about to spend several paragraphs gushing about it because I have no self-control.

The Phenomenon

Somewhere between LinkedIn humble-bragging and actual productivity, there exists a special corner of the internet where people lovingly curate lists of the 47 different SaaS tools they pay for monthly. It's like Pokemon, except instead of catching them all, you're paying for them all, and your bank account is crying softly in the corner.

First there was StackShare. Then there was uses.tech. Then someone made YC companies share their stacks. Then indie hackers started posting theirs. Now we have ramen.tools, and honestly? We're probably three weeks away from "show me your Notion templates for organizing your stack-sharing profiles."

Why Ramen Though?

The name is actually kind of brilliant in that startup-cutesy way that makes you simultaneously cringe and smile. Ramen is cheap, scrappy, bootstrapper food. The irony of using a ramen-themed site to show off your $3,000/month SaaS budget is chef's kiss. It's like calling your luxury car dealership "Beans on Toast Motors."

What Makes This One Different?

Here's the thing about ramen.tools: it's clean, it's simple, and it presents your tech stack like it's a Michelin-starred tasting menu instead of a screenshot of your browser's bookmark bar. Each tool gets a little card. There are categories. Everything is organized. It's beautiful.

Is it necessary? Absolutely not. Could you just... write a blog post? Sure. Make a GitHub gist? Yep. But would any of those options make your use of Superhuman and Linear look quite as impressive? I think not.

The Real Question

How many of these sites will AI spawn? Oh buddy, buckle up. We're going to see:

AI-generated stack recommendations based on your vibe
Sites that auto-populate your stack by scanning your credit card statements (terrifying)
"Stack dating" where you match with other developers based on tool compatibility
NFTs of famous developers' stacks (please no)
A site that tells you which YC batch you would have gotten into based on your tooling choices

The AI slop tsunami is real, and "show your stack" sites are the perfect victim because they're 90% template and 10% content. We're going to drown in them.

Why We Love Them Anyway

But here's why we keep clicking, keep sharing, keep making new ones: there's something deeply human about wanting to peek inside someone else's workflow. It's the digital equivalent of checking out what's in someone's grocery cart. We're nosy. We want to optimize. We're convinced that if we just find the right combination of tools, we'll finally be productive enough to justify spending four hours setting them all up.

Plus, let's be honest: half the fun of being a developer/founder/creator in 2026 is having opinions about tools. Vim vs VS Code? Notion vs Obsidian? Whether Vercel's pricing is highway robbery? These are the debates that sustain us.

The Verdict

Ramen.tools is good, actually. It's well-designed, it serves its purpose, and if you're going to waste time comparing your stack to other people's stacks (and you are, don't lie), you might as well do it somewhere pretty.

Will we need 50 more of these? No. Will we get them anyway? Absolutely. Will I check out every single one and probably add my stack to at least three of them? You know I will.

Now if you'll excuse me, I need to go update my ramen.tools profile to add that new AI-powered clipboard manager I just signed up for. It's essential. Revolutionary, even. I'll definitely use it.

The Wild West of ASP: A Love Letter to the Early Web

Anders Björk — Sat, 28 Mar 2026 10:56:06 +0000

The Wild West of ASP: A Love Letter to the Early Web

There was something gloriously chaotic about learning ASP in the late 1990s and early 2000s. No bootcamps, no TypeScript configs, no package.json files with 47,000 dependencies. Just you, Notepad, and a burning desire to make things happen on the server side.

The Learning Landscape

The internet back then was a different place for developers. You didn't have Stack Overflow. You didn't have thousands of YouTube tutorials. What you had were a handful of websites run by enthusiasts who genuinely loved this stuff and wanted to share what they knew.

4GuysFromRolla.com was the crown jewel. Scott Mitchell and his crew weren't just writing documentation, they were building a community. Their tutorials had personality. They'd walk you through creating a guest book, building a simple CMS, or implementing user authentication, and they'd do it in plain English with working code samples you could actually copy and paste. The site had this warm, collegial feeling, like you were learning from friends who happened to be a few steps ahead of you.

Then there were sites like ASPToday, which ran daily articles (an ambitious publishing schedule even by today's standards), and the various forums scattered across the web. Dev Shed, WebDeveloper.com, and countless personal sites with names like "Bob's ASP Corner" or "The ASP Zone." These weren't slick, venture-capital-backed platforms. They were hobbyist sites with garish color schemes, animated GIFs in the headers, and genuinely helpful people answering questions.

You'd bookmark dozens of these sites. You'd print out tutorials on actual paper. You'd keep a binder of code snippets because searching your hard drive was less reliable than just flipping through printed pages.

The Code Itself: Beautiful Chaos

ASP code from that era was wonderfully, terrifyingly free. There was no webpack, no linting, no CI/CD pipeline complaining about your coding standards. You just wrote code, uploaded it via FTP, and refreshed your browser.

A typical ASP page might look like this:

<%@ Language=VBScript %>
<html>
<head><title>My Cool Page</title></head>
<body>
<%
Dim conn, rs, sql
Set conn = Server.CreateObject("ADODB.Connection")
conn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Server.MapPath("database.mdb")

sql = "SELECT * FROM products WHERE category = '" & Request.QueryString("cat") & "'"
Set rs = conn.Execute(sql)

While Not rs.EOF
    Response.Write "<h3>" & rs("ProductName") & "</h3>"
    Response.Write "<p>Price: $" & rs("Price") & "</p>"
    rs.MoveNext
Wend

rs.Close
Set rs = Nothing
conn.Close
Set conn = Nothing
%>
</body>
</html>

Look at that. SQL injection vulnerability right there in the open. Presentation logic mixed with data access. No separation of concerns. Connection handling that would make a modern DBA weep. And yet... it worked. You could build something functional in an afternoon.

The coding style was utterly unstructured by today's standards. Everything lived in one file if you wanted it to. You'd have a page that handled form submission, database queries, business logic, and HTML rendering all mixed together in a glorious spaghetti of <% %> tags and HTML.

People would create "libraries" by just including other ASP files:

<!--#include file="header.asp"-->
<!--#include file="database_functions.asp"-->
<!--#include file="user_functions.asp"-->

These includes would just dump their code right into your page. Variable scope? Session variables everywhere. Global state? Sure, why not. It was the Wild West, and we were all cowboys.

The Access Database Era

And then there were Access databases. Beautiful, maligned, wonderful Access databases.

For small projects, Access was perfect. You didn't need to install MySQL. You didn't need to configure anything. You just created a .mdb file in Microsoft Access, designed your tables with the GUI (relationships and all), and boom, you had a database. Upload it to your web server, point your connection string at it, and you were in business.

conn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Server.MapPath("mydb.mdb")

That was it. No credentials, no server configuration, no port numbers to remember. The database was just a file sitting in your web directory (hopefully in a folder outside the web root, but let's be honest, not always).

Access databases could handle thousands of records just fine. For a small business website, a personal blog, a community forum with a few hundred users, they were absolutely adequate. They got a bad reputation because people would try to use them for high-traffic applications, and yes, they'd fall over. But for what they were designed for, they were brilliant.

The Access interface itself was approachable. You could design forms, create queries visually, build simple reports. Non-programmers could maintain the data. It was democratic in a way that PostgreSQL command-line tools could never be.

The Speed of Development

Here's the thing nobody talks about when they reminisce about the old days: you could build something useful incredibly fast.

Need a contact form that saves to a database? Thirty minutes, maybe an hour if you wanted it to look nice. Need a simple content management system? A weekend project. Want to add user authentication to your site? Copy some code from 4GuysFromRolla, modify it for your needs, done.

There was no ceremony. No setting up Docker containers, no configuring webpack, no deciding between seventeen different JavaScript frameworks. You opened Notepad (or if you were fancy, HomeSite or Dreamweaver), wrote some code, saved it as .asp, uploaded it, and you were live.

The feedback loop was immediate. Change code, hit F5, see results. No build step. No compilation. No waiting for hot module replacement to kick in. Just instant gratification.

The Community Spirit

The ASP community had something special. It was small enough that you'd recognize the same names helping people on different forums. There was no snark, no "let me Google that for you" responses. People genuinely wanted to help.

When someone posted a question, they'd often include their entire code file. Not a minimal reproducible example, just all 300 lines of their product catalog page. And people would actually read through it and help. They'd spot the error on line 187 where you forgot to set an object to Nothing, or notice that you were opening a database connection inside a loop.

There were personalities. The "ASP gurus" who seemed to know everything. The newcomers asking basic questions. The intermediate folks helping out while still learning themselves. It felt like a real community, not just a Q&A marketplace.

What We've Gained

Today's web development landscape is objectively better in many ways. The tooling is incredible. TypeScript catches errors before they reach production. Modern frameworks handle state management in ways that make sense. Package managers mean you don't have to reinvent the wheel for every common task.

Security is taken seriously now. We have HTTPS everywhere, proper encryption, frameworks that sanitize inputs by default. The SQL injection vulnerability in that code sample above would never make it past a code review today.

The databases are better. PostgreSQL, MySQL, SQL Server, they're all powerful, reliable, and can scale to millions of records. ORMs handle the tedious parts of data access. Migrations track schema changes.

Development environments are sophisticated. VS Code with its extensions, IntelliSense, debugging tools, Git integration. The modern developer has superpowers compared to someone in 1999 with Notepad and an FTP client.

Testing is built into the workflow. CI/CD pipelines catch issues before deployment. Monitoring tools tell you when things break. The entire ecosystem around professional software development has matured enormously.

What We've Lost

But we've also lost some things, and not all the changes are pure progress.

We've lost simplicity. A new developer today faces an overwhelming landscape. Which framework should they learn? React? Vue? Svelte? What about the backend? Node? Python? Go? What about databases, deployment, cloud providers, containerization? The barrier to entry is so much higher now.

We've lost immediacy. The edit-save-refresh cycle has been replaced with build processes, transpilation, bundling. Yes, hot reload helps, but there's still something between you and the metal. You can't just FTP a file and see your changes live in seconds.

We've lost that scrappy, make-it-work attitude. Today's best practices are genuinely better practices, but they also add ceremony. You're supposed to write tests first. You're supposed to separate concerns. You're supposed to use dependency injection. These are all good ideas, but they slow you down when you just want to make something.

We've lost some of the community intimacy. Stack Overflow is fantastic, but it's transactional. You post a question, someone answers it, you move on. The old forums had ongoing relationships. You'd see the same people week after week. You'd graduate from asking questions to answering them. It felt like growth.

We've lost the personal websites. Those individual developers who'd post tutorials on their own domains, with their own personality shining through. Now everything is on Medium, Dev.to, or corporate blogs. It's more polished but less personal.

What Still Rocks from the Early Days

Some things from the ASP era deserve recognition, even reverence:

The directness of it all. You could look at an ASP page and understand the entire flow from request to response. No magic, no framework abstractions, just code executing from top to bottom. That transparency was pedagogically valuable.

The completeness of simple solutions. An Access database application was completely self-contained. You could zip up a folder and hand someone a working application. Try doing that with a modern web app and its node_modules folder, database migrations, environment variables, and cloud dependencies.

The low stakes experimentation. You could try things without committing to an entire ecosystem. Want to experiment with e-commerce? Just add a shopping cart table to your Access database and write some checkout code. No need to evaluate payment processing SDKs, comply with PCI requirements from day one, or set up a secure key management system. You could prototype fast and learn.

The view source culture. You could right-click on any page, view source, and see how it was built. Yes, you only saw the HTML output, not the ASP code, but people would share their actual code liberally. Today's minified, bundled, compiled output is technically superior but pedagogically opaque.

The 80/20 solutions. Access databases and simple ASP code got you 80% of the way there for probably 5% of the effort. Yes, the last 20% was hard, but most projects didn't need that last 20%. Most projects just needed to work well enough.

The Verdict

Is everything better today? In terms of capability, scalability, security, and professional software engineering practices, absolutely yes. Modern web development produces better software, more reliably, at greater scale.

But we've paid a price in accessibility and joy. The early web was a place where a curious teenager could view source, learn some ASP from 4GuysFromRolla, spin up an Access database, and build something real. That ladder into programming still exists, but it's gotten longer and more complex.

The truth is, we need both. We need the rigor and sophistication of modern development for the applications that run our world. But we also need to preserve some of that early-web spirit: the idea that someone with curiosity and determination can build something without asking permission, without a computer science degree, without mastering a dozen tools first.

Maybe that's what still rocks most about those early days. Not the specific technologies, which were genuinely limited in many ways, but the feeling that the web was this open, malleable space where anyone could make something. Where the barrier between user and creator was permeable. Where "I wonder if I could build that" was answered by opening a text editor and just trying.

The 4GuysFromRolla.com crew and all those other tutorial writers weren't just teaching ASP syntax. They were teaching a mindset: that the web is yours to shape, that building things is learnable, that imperfect working code beats perfect planning every time.

That spirit, more than any specific technology, is what deserves to survive from those early, chaotic, wonderful days.