My journey through web development, from 1998 to today.
When I started learning HTML in 1998, building websites was very different from what we do today.
There were no npm packages, complex build tools, cloud services, or CI/CD pipelines to worry about. You created a page, added some styling, uploaded your files to a server, and opened the website in your browser.
Of course, websites couldn't do nearly as much as they can today.
Over the years, I've worked with different technologies, from simple HTML pages to server-side applications, enterprise systems, modern front-end frameworks, and Adobe Experience Manager.
Looking back, I've noticed something interesting.
Every generation of web technology has given us more powerful tools, but those tools have also brought new challenges and complexity.
And after a while, we always seem to look for ways to make things simpler again.
That's what I find interesting about the evolution of the web.
I started with HTML in 1998.
Back then, websites were much simpler. I remember working with HTML attributes, inline CSS, styles inside the page, and eventually moving more of the styling into separate CSS files.
I also worked with tools like Microsoft FrontPage and Macromedia Dreamweaver.
Both made building websites easier, especially for people who didn't want to write every line of HTML manually.
One thing I liked about Dreamweaver was being able to switch between the visual editor and the HTML code. You could design something, change the code, and immediately see the result.
You didn't need a complicated development environment to build a simple website.
That doesn't mean everything was easy. Browser compatibility was a big headache, and many things we take for granted today were difficult or simply not possible.
But there was something nice about how quickly you could go from writing code to seeing your page working.
As the web grew, businesses needed more than static pages.
They wanted databases, user accounts, login systems, search functionality, and ways to manage their websites without changing the code every time.
During those years, I worked with JavaScript, VBScript, and Classic ASP.
I was moving beyond HTML and CSS and learning more about how websites worked behind the scenes.
At the same time, content management was becoming an important part of web development.
Companies didn't want to depend on developers for every small content update.
One of the tools I worked with during that period was Macromedia Contribute.
I still remember the idea behind it. Developers could build and maintain the website, while content editors could update text and images without changing the actual structure.
It was a simple idea, but an important one.
Content editors shouldn't need to understand programming just to update a website.
I also worked with Microsoft Expression Web, which Microsoft introduced in 2006 as the successor to FrontPage.
Expression Web focused more on web standards, CSS, and cleaner HTML. It was interesting to see how even visual web development tools were changing.
Websites were becoming more complicated, but tools like Contribute were trying to make at least part of the process easier.
Looking back, I think this was one of the first times I really noticed that pattern.
Around late 2007 and early 2008, I started working with ASP.NET and C#.
This was a big change for me.
I was no longer just building websites. I was working with applications that had business logic, databases, different user roles, and connections to other systems.
Java and JSP were also popular at the time, especially for enterprise applications.
I remember thinking several times about switching from C# and .NET to Java.
But I ended up staying mostly with Microsoft technologies.
During those years, I worked on enterprise applications, including systems that connected web applications with Android apps and other parts of the business.
I also worked with WordPress and Shopify.
These platforms offered a different approach. Instead of building everything from scratch, you could use an existing system and customize it based on what the business needed.
That saved a lot of development time.
But as projects grew, custom features, integrations, and business requirements made things more complicated again.
Whether we were building an application from scratch or using an existing platform, the same problem kept coming back.
The more a business needed, the more complex the system became.
Around 2018 and 2019, I decided to focus more on JavaScript and modern front-end development.
React became one of the main technologies I started learning and working with.
I also moved into TypeScript, Next.js, REST APIs, GraphQL, and different libraries for state management, UI development, and testing.
This was another big change.
We were no longer building pages the way we used to.
Now we were building applications using reusable components, managing application state, connecting to APIs, and handling much more logic in the browser.
React and the modern JavaScript ecosystem gave us a lot of flexibility.
But they also introduced a lot of new things to learn and maintain.
Sometimes it felt like we needed hundreds of npm packages just to display a button.
Okay, maybe that's a little exaggerated, but anyone who has worked on a large JavaScript project probably knows what I mean.
We could build much more powerful applications than before, but the development process was also becoming more complicated.
Another important part of my recent experience has been working with Adobe Experience Manager (AEM) on large enterprise projects.
I worked on reusable components, React integrations, APIs, content structures, accessibility improvements, and making the authoring experience better for content editors.
Working with AEM gave me a different perspective on web development.
In enterprise projects, it's not just about how a website looks or works.
You also have to think about permissions, publishing workflows, asset management, accessibility, security, and how different teams work together.
Sometimes a change that looks very simple to a content editor can involve several different systems behind the scenes.
Of course, there's a reason for that complexity.
Large organizations have complicated requirements, and platforms like AEM are built to handle them.
But working with these systems made me think about something.
Can we keep all these powerful features while making things easier for the people who actually use the platform every day?
When I started learning more about AEM Edge Delivery Services (EDS) and completed my Adobe training, something about it felt familiar.
Not the technology itself.
EDS uses a modern architecture and a very different approach from the tools we had years ago.
But the idea behind it reminded me of Macromedia Contribute.
Make content publishing easier.
With EDS, content authors can work in familiar tools like Microsoft Word or Google Docs, depending on how the project is set up.
Developers can focus on building blocks, writing clean HTML, CSS, and JavaScript, and improving performance and accessibility.
The platform is also designed with fast content delivery and good web performance in mind.
Of course, EDS doesn't automatically make every website fast. That still depends on how the website is built, the content, and any third-party services being used.
And EDS is definitely not a modern version of Contribute.
They're completely different technologies.
But I find it interesting that, after all these years, we're still trying to solve a similar problem.
How do we let people create and publish content without making them deal with all the technical details?
The complexity hasn't disappeared.
We still need infrastructure, integrations, security, and all the things that come with enterprise development.
Maybe the real improvement isn't removing complexity.
Maybe it's moving that complexity behind the scenes so the people using the system don't have to worry about it.
And now we're seeing another major change in software development.
Agentic AI.
A few years ago, most of us were using AI to answer questions, generate content, or help write code.
Today, AI tools can do much more.
They can examine files, work across different tools, follow multiple steps, suggest changes, run tests, and help evaluate the results.
It's still not perfect, and these tools definitely need human review.
But the way we work is already starting to change.
In some ways, this reminds me of earlier changes in web development.
Visual editors made it easier to build pages.
CMS platforms made it easier to manage content.
Modern frameworks helped us build larger and more structured applications.
Now AI is starting to make parts of the development process easier too.
I don't think this means developers are no longer needed.
We still need to understand business requirements, make architecture decisions, review security, test applications, and make sure things actually work.
In fact, I think good engineering judgment may become even more important as AI tools become more capable.
It's still too early to know exactly where all of this will lead.
But one thing feels familiar.
We have another generation of tools promising to make complicated work easier.
And just like before, I'm sure we'll discover new challenges along the way.
When I look back at my journey since 1998, it's amazing how much web development has changed.
I started with HTML and visual editors like FrontPage and Dreamweaver, moved into server-side development and enterprise applications, and later focused on modern front-end technologies and enterprise CMS platforms.
Today, with Edge Delivery Services and Agentic AI, we're seeing new ways to build applications and publish digital content.
Each generation of technology has helped us solve problems that were difficult before, but it has also introduced new complexity.
And after all these years, I think the main goal hasn't really changed.
We're still trying to make it easier to turn an idea into something real.
Maybe that's what the evolution of the web has been about all along.
Masoud
October 8th, 2026