…when all we ever needed was a text box
or how 2025 will be back to basics for the web
All of my articles are free to read, read for free by clicking this link.
A few times each year, in discussions with fellow developer friends, we all agree we’re just building the same things over and over again, and they all have one thing in common: text inputs.
Now, as well as 20 years ago we have always been wizards of the text boxes, experts at turning HTML form elements into magical web experiences.
In this post I will try to look back at my career in coding text boxes, in search for the answer to the question:
Why did we bother building all these fancy web interfaces, when all we ever needed was a text box?
Hold on friends! Before you get upset, let me elaborate on that.
Recent development, especially the past few years has had us all enchanted by the seemingly magical powers of AI in general and LLMs (Large Language Models) in particular. New services specialized in different kinds of content generation are now being launched at light speed. ChatGPT for text, Midjourney for images, Suno for songs, Copilot for coding just to name a few. Judging from the output from these services they would categorize as extremely powerful and complex systems. They create things in milliseconds that was not even possible just a few years back.
And they all have one thing in common.The main interaction with them is done via one of the simplest type of html component we have:
<input type="text">
This particular trend has occupied my thoughts for a while now.
What if users just want to use their natural language when interacting with systems, just as we expect when interacting with other humans?
Which opens for followup questions like:
- Did we deliberately make the web more complex than it needed to be?
- Why did we spend decades adding complexity, when the most powerful tool we’ve ever built might just be a single text box?
Looking Back
See when I started coding we had developers, or coders if you may. No backend, no frontend, hell I even heard of such a thing as an architect years into my career. We just did it all without bothering what we were called.
The interfaces were simple and often performed very simple tasks, like sending a mail or signing up to something. Wew used plain HTML, form tags and at best some CSS. Things were posted to some perl script at the backend via the action attribute.
<form action="/cgi-bin/script.cgi" method="POST">
<label for="name">Name:</label>
<input type="text" id="name" name="name">
<input type="submit" value="Submit">
</form>
The interfaces were fugly and sometimes quite hard to use, but that didn’t matter. It worked, and that was enough for us.
App #1: “CMS”
For me it started with reading the CGI Bible back in 1996, building HTML forms posting stuff to a CGI backend. In my case I built something that today probably would be described as a CMS. But back then we hadn’t invited all those webzy cool acronyms we are so familiar with today. I just saw a problem that needed a solution. Nevertheless, it was just a a simple form application where you entered text and pressed a button and things got posted.
Aa few years pass and those simple text boxes turned into radio buttons and checkboxes, making it easier and faster to input text into the machine we now called the web.
App #2: Peking Pizza
So moving on to 2001, and university studies. This meant moving my beloved desktop PC from Gothenburg to Norrköping. A few weeks in me and some friends saw the urgent need of knowing where the best pizzas were made, so we created “Peking Pizza”, named after the nickname of Norrköping.
The website? A form application with checkboxes of pizza ingredients. The user selected what they wanted on a pizza and the web machine spitted out the places where this particular pizza could be ordered, along with ratings for the pizza place etc.
Backend was made in php, but let’s not tell anyone.
App #3: Snapshot
If I told you me and a university friend created Instagram two years before Instagram you would probably laugh. But I would argue this is exactly what we did. We had this crazy idea that with the new world spanning web technology people will probably want to share things online. For the world to see what their lives looked like.
The only problem was this was before fast web communication via phone, aka 3G, existed. So people had to send their images via MMS, which turned out to be a shit protocol that was too slow and too expensive to base a photo diary app on.
But we certainly built it, and in november 2004 we launched snapshot.se (thank you waybackmachine). Hell, we even went to the folks at the city officials advicing new companies and pitched the app. Do I need to say they did not quite get it.
The site was in Swedish at launch, but heres the start page text in english:
At snapshot, we believe it should be easy to share your experiences. That’s why we created this site. Here, your friends or family can easily, with just a few clicks, see the things you want to share. It can be a funny monkey you managed to capture on camera in Thailand or your latest pike catch in the country. You choose what you want to share.
After you’ve registered here at snapshot, it’s just a matter of sending in pictures, and creating posts on snapshot is as easy as putting on your shoes.
But now, to the point. The site was based on forms and text boxes where you could upload you images in an easy way, either by using the website or by MMS:ing or emailing (look, another text based application) an image to the system.
App #4: Get on that bus
Oh yes, enter the world of handheld web! Although testing this out early by connecting my Ericsson T39 to my pocket computer and browsing the web via GPRS, the handheld web was not really useful to access until Apple released the iPhone. Shortly following the first iPhone launch, Google launched their counterpart.
And with that, I downloaded the Android SDK and began developing my very first app: Get on that bus.
Get on that bus was an app helping lazy people knowing when to leave your home to get in time for the bus or tram.
And yes, you guessed it. The main input method was the text box for finding from where you were leaving, and how many minutes left until you needed to walk, or most often run, to the bus.
Hello Javascript — Goodbye Simplicity
Most of my humble coding contribution to the world has been spent building web and mobile applications. As years have passed the user interfaces has gotten more and more complex, demanding more code on the frontend parts of the systems. This is where javascript came to the “rescue”.
Interfaces needed partial updates in real time, we invented words like infinite scroll, and every web page of any dignity had an image carousel part in the top of the page. And with this, code complexity moved to large extent from the backend to the frontend. When the script.js file, where we put all javascript into one single file became impossible to maintain we started seeing frontend build tools like grunt, gulp and webpack. Building frontend code! We laughed, complexity grew.
Developers like me found themselves building web api’s to support the increasingly complex user interfaces. And with us spending time on the “backend” of things, a new type of developer arose:
The Frontend Developer. These folks loved interfaces and things that moved. When you finished a signup form there were fireworks. When you typed something wrong in the text box a message magically appeared claiming you messed something up in your email address.
And then the styling. Suddenly those form elements we got so used to were boring and ugly. They needed style. And since CSS was too rudimentary we invented CSS extensions like SASS and LESS adding even more complexity to the already complex frontend applications.
With the increasing complexity the user interfaces got harder and harder to use, which of course was a huge problem for sites like e-com stores wanting to sell as much as possible to the users. This called for the rise of a few new roles in web development.
The User Experience Designer (UX) and the User Interface Designer (UI). UX Designers represented and empathized with the users of the complex interfaces we created. They liked the users so much they would even offer themselves to do interviews and and test interfaces with them. Sometimes face to face! With their newly found knowledge and user insights, the interfaces created by the User Interface Designers and the Frontend Developers could be made a bit less confusing to the users.
As 2016 turned 2017 I actually wrote a post on the challenges of getting all of these roles working together in teams. It’s quite a good side story so if you need a pause from my ranting here, I’d recommend you read it.
As things continued to evolve we even started fiddling around with the way things are rendered in the web browser, and the DOM (Document Object Model) became the main character. When engineers at Facebook grew tired of the problems attached to building user interfaces at scale, they created React, and with that introduced the Virtual DOM, an in-memory representation of the real DOM. Instead of directly manipulating the DOM (a slow process), React updates the Virtual DOM, calculates the most efficient way to apply changes, and updates only the necessary parts of the real DOM. This approach dramatically improved performance, especially for dynamic and interactive applications.
With this came also the pattern to build web applications with components, that made it easier to re-render parts of a web page and maintaining code updates in complex user interfaces.
At the crossroads?
Continuing along this path for years, we now find ourselves with large design systems, consisting of hundreds of complex components, and millions of lines of code. Heck, we even have guides on how to calculate design system costs, to be able to choose the right design system, or worst case, build your own. And they all serve one purpose; Helping the users making sense of an over engineered world wide web.
So what do you think? Do I have a case here, stating that maybe we have created a web that just might be a bit over engineered? A bit too complex?
And maybe, just maybe, it is not only in response to user insights, but also because we like to over complicate things?
We are at the crossroads and here are my thoughts on what 2025 and coming years have in store for us.
2025 — Back to Basics
Just looking at the new tools released the past year I think it’s clear the web is heading back to simplicity. LLMs (Large Language Models) and AI-driven applications is now showing how to use natural language as an interface, reducing complex designs to a single input. You guessed it: the text box.
So what does this mean for the future of the web?
Major Changes In Roles And Responsibilities
Developers as Problem Solvers
Much like in the early days of web development, when developers needed to solve problems regardless of language, frontend or backend, developers in 2025 will focus less on building intricate user interfaces and more on solving problems through functionality and efficiency. This will most probably change the developer role.
I think we will see an evolution of what we usually refer to as micro service architectures, where these micro services now instead become agents, powered by large language models, that have a clear purpose and
Developers need to be aware of what services to use, what to build ourselves and what to buy by the token. The move to api based systems has already pushed us in this direction and this is the next big leap. We will be the jigsaw puzzle masters, putting different already made pieces together into complete systems that will serve the users with relevant data. Here, programming language matters less. You will use what’s relevant in every specific case. And with tools like Copilot and others now widely available, this is a problem of the past. Forget long hours of online courses, instead focus on solving real problems together with your new smarter best friend.
Framing, understanding, dissecting and then solving problems has always been the key skill for a good developer, and tomorrows landscape will put even more emphasis on this.
Us developers will need to put a lot of work into how AI-related systems are built, tested and deployed. We will be responsible for making sure these systems are secure to use, user data is handled correctly and that users understand the systems, not to mention all the ethical aspects of utilising AI systems. It will require a lot of upskilling, so make sure you use every hour you can to educate yourself. Try as many tools as you can. Read about the latest advancements. But most importantly; just build stuff.
I promise you, it will be fun!
Designers as Empathy Architects
I know, cheesy, but bear with me. The move towards text-based, conversational systems reduces visual complexity but amplifies the need for strategic, empathetic design.
User Interface Designers will need to transition from creating decorative interfaces to becoming architects of meaningful and efficient interactions. This involves focusing on the clarity and intuitiveness of conversational flows, ensuring that users can navigate systems seamlessly through natural language, both with text and voice. Designers will need to create interactions that are not only functional but also engaging and human-like.
I believe designers will play a major role in complementing text or speech based systems with contextual interfaces, navigating, guiding and making sense of responses and generated content.
User Experience Designers will need to learn how natural language input changes the way we interact with systems. In 2025 I think we will see a lot of new voice to text enabled applications. UX designers will need to learn how to create user interfaces that encourages the user to stay of the keyboard, and instead rely on using voice. Yes, we’ve had assistants like Siri and Alexa for years, but it isn’t until now we are starting to get close to having actual conversations with such systems, and this opens up a pandoras box of new possibilities, where UX can play a crucial part in guiding the users.
All in all, the things I wrote in early 2017 still applies. To succeed we need to work in teams, cross functional teams. Developers need to understand, value and respect the empathetic approach of the UX and UI designers, and the designer need to understand the complexity that goes into developing a system, especially an AI powered one.
Wrapping up
So did we overcomplicate the web?
Absolutely — but not without reason. Every evolution, from static HTML to complex JavaScript frameworks, was a response to a challenge or a trend.
But to some extent I do think much of the complexity was unnecessary. The basic goal — helping users get what they need — is achievable with far less.
Users want interactions that feel intuitive and human, not cluttered menus and overly styled interfaces. Text based tools and image generators available today shows clearly that simplicity is a key element. Instead of creating complex UI components and workflows, we’re moving toward enabling conversations with systems. A simple text box, paired with powerful AI, might just be the most reasonable way to get things done.
TLDR;
In 2025, the web will increasingly rely on:
- Simple Inputs: Text boxes, voice commands, and other natural interfaces.
- AI-Driven Logic: Backends that understand and execute complex tasks without requiring complex UI.
- Scalable Solutions: Systems that adapt to user needs without requiring new interfaces for every problem.
This all means a lot of challenges for us working in this industry. We will need to navigate a world where new tools and services are released every day. All claiming to have the power to optimize and revolutionize, yes even replace us. In some cases this will be true, and we need to find the sweet spots where human hands will still be needed.
And oh, the text box, that beautiful little HTML element, is making a well deserved return. And maybe, just maybe, that’s all we ever needed in the first place.
So a happy new year fellow web loving friends! I surely hope 2025 has a lot to offer, and I look forward to what we all can create together with the extreme advancements in technology we get to experience. Please don’t be shy to show and tell the world about the things you create. I know I will, and I have quite a lot of ideas that deserves to be tested!
It’s a good time to be a developer! 2025 — Bring it!