This content originally appeared on Bits and Pieces - Medium and was authored by Fernando Doglio
The work of a developer used to be quite different back then
You’re probably wondering: what kind of developer can write an article like this?
Let me answer that for you: an old developer.
Let’s not kid each other, I’m not young, and I’ve been working in the IT industry for almost 20 years now. The good thing is that while I am old enough to write this article, I’m young enough to still remember how differently we used to work. So yeah, I’m old but young at the same time, I’ll take it.
That said, “back in the day” we used to work with very different tools, patterns and heck, even standards. Being IE-compatible wasn’t a joke back then, in fact, being compatible with all major browsers wasn’t easy either.
Let’s take a stroll down memory lane and remember what it used to be, so we can better appreciate the tools we have today.
Netlify? Vercel? AWS? What are those?
Platforms as a Service or even Software as a Service were not a thing when I started working in the industry 20 years ago.
That’s how different it was to develop software. In fact, the idea that “there is an API for everything” was not real back then. Having a service up and running required a lot of work and money, so nobody did it unless they had a very good reason for it.
On top of that, the tools we had were different, Node.js wasn’t a thing, so frameworks like Next.js weren’t available. I started working with PHP 4, which did not come with the ability to create your own web server like Node.js (and others) do now. Instead, we had to install Apache Web Server, or if you were a risk-taker, Internet Information Service, which was (is?) Microsoft’s option if you wanted to have a Windows-based web server (which back in the day wasn’t ideal).
The interesting bit about this way of working was that your application was a set of scripts that would get executed every time a request was received by the server. This meant that you had no “running app” on the server. Every new request turned into a new process running inside your server. Which meant servers had to be powerful to handle lots of requests, because every request was a parallel process taking up a piece of its memory and CPU time.
And of course, database connections (and to other services) had to be established and closed during the lifetime of the script (i.e the duration of the request).
If you wanted to scale, “auto-scaling” wasn’t an option. I remember the pain of having to estimate the amount of server power your e-commerce site would need for a particular holiday. And of course, always falling short and having to do some emergency fixes during the weekend (like rebooting dead databases, or cleaning up log files that grew too big and filled up the disk).
And the front-end stack was a lot simpler
The front-end scene was very different back then as well for a couple of reasons:
- The most important one, I think, is the fact that HTML, CSS and JavaScript were less standard back then. Especially the latter, every browser implemented their own version of it, following their own guidelines and not really caring about the others. It was a race, not a collaboration. So you had functions that were available in Chrome, but neither Firefox nor IE had, and vice-versa. This meant that building something that could be used by anybody had to have a lot of code just to deal with those gaps.
- There were no UI frameworks back then, there were just libraries. To me, that distinction is important, because nowadays, frameworks like React and Vue provide you with an architecture that defines a set of tools and patterns for you to follow. And if you build on them, as Next, Nuxt and others do, then they provide you with a path for you to follow. Back in the day, we had jQuery, underscore (which later was almost replaced by lodash) and Mootools. They were all fantastic libraries, but they wouldn’t really impose a way of working, which lead to thinking that front-end development didn’t require the use of any advanced development methodology or techniques. Heck I remember thinking that JavaScript was meant for adding form validation and some silly animations to an otherwise, static site.
You have to remember, “back then”, we couldn’t even load data asynchronously. It wasn’t until the term AJAX got popular that we found out about this ability (and learned the concept of asynchronous behavior). That was a shift in our working paradigms, something that today is very common.
Now it’s a lot easier
Now deploying an application is a lot easier. Which is great, don’t get me wrong!
You can now hook up your Github account with a Netlify (or similar) account and auto-deploy your application somewhere in the world. Heck, you can take advantage of services like Supabase, or AWS DynamoDB where you don’t even have to worry about maintaining your database or your authentication service.
There are even services that will centralize your logs, like Loggly and Splunk, so you don’t have to worry about filling up the disk space if your log-rotation configuration wasn’t optimal.
Being a one-man band back then was a lot harder, now you can really get close to working truly alone (if you’re willing to pay for it).
And the front-end became harder, which is good
The front-end ecosystem is quite large right now, React, Vue, Svelte and even Angular power, or have inspired, the creation of many frameworks that are pushing the front-end to the next level.
Let me put it this way, back when I was getting started, the “motto” of web development used to be “slim clients, fat servers” or “keep your clients dumb” or variations of those ideas. Essentially, your client code is simply presentational, you were not supposed to be doing anything “hard” in there because the browser wasn’t ready for it. Instead, we kept our “complex” logic in the back end and used JavaScript to show pretty colors and some alert boxes.
We’ve come a long way since then. Of course, that hasn’t happened without a price. Back then our “bundler” was a set of script tags we would add at the top of our HTML and that was it.
Now the amount of JS to power a modern app has grown so much that the ecosystem of tools developed to optimize it has grown accordingly.
Now you need:
- A transpiler if you’re not using pure JavaScript.
- A bundler to put all your code together, remove the unnecessary bits, optimize it for transfer and deliver it in a way that is less “expensive” to the user.
- A linter to make sure every one of the 100k lines of JS is following the same standards across your team.
- A webserver with hot-reload and file monitoring to make sure your development experience is optimized, otherwise changing a single line of code can take quite a long time to refresh.
- A package manager, because as developers we’re done re-inventing the wheel.
- A version control system (usually Git + Github but there are alternatives to both) to make sure teams can easily collaborate on the same project.
- A test runner, because yes, now your front-end business logic is so complex (which is great BTW) that you need a way to make sure everything works as expected.
And I bet you can probably think about a few more. It can be a little bit overwhelming for someone just getting started.
I know it was for me when getting back on the horse after years of not coding.
Thankfully, the industry is still evolving. While they’re still new and trying to break in, tools are being developed specifically designed to simplify the stack once again, while keeping the power and capabilities of today’s complex solutions.
The future of the web development tooling ecosystem
This journey isn’t over, and that’s good.
If you think about it, we do this with our code as well:
- We write a simple solution to our problem.
- We realize it’s not covering all potential edge cases, so we keep adding more code on top of it until it works as it should.
- We realize it’s a damn Frankenstein of code, unmaintainable and hard to understand so we start refactoring and simplifying.
Our toolchain is going through the same process. We’re starting to see step #3 by now. We’re seeing tools like Bit, from bit.dev trying to centralize all the tasks around the development cycle.
In fact, with Bit, you can version your code, lint it, and publish it as individual packages. Heck, you can even manage a full monorepo with it without having to worry about any other tool.
Granted, it’s not like the tool does everything for you, in fact, it “just” manages the whole ecosystem of tools you’d usually have to worry about yourself. And that is a smart way to go about it if you ask me.
Additionally, tools like bundlers are starting to see a trend where they’re not exactly needed anymore. Hear me out, I interviewed Michele Riva (he’s a Sr. Software Architect from Nearform) for the 20MinJS podcast, which I host, and on his episode, Michele mentions how new bundlers like Vite are taking advantage of browsers’ new ability to use the ECMA Script import statement, and load files asynchronously, thus improving the loading speed of JavaScript (instead of having to load one or few very big bundled files).
So if you ask me, the future is looking bright. There is still a lot to work on, but the days of worrying about having to manually set up the platform for our application are long gone. The tooling ecosystem is evolving to a point where we can quickly prototype and deploy ideas and then grow them into full-blown applications without having to change much other than the services we use or the tiers we’re paying for. And if we want to scale them up, because they turned out to be a success, that is also accessible within our reach as long as we’re ready to pay for it.
I think the beauty of the current state of the Web Development industry, is that we have options.
We can still work the “old school way” and do everything by hand, manage our own servers, project the traffic and the workload required for our app and grow the infra accordingly.
Or if we’re willing to trust the tried and tested platforms and services out there, we can pay for them to do the work for us. We’re essentially replacing what would otherwise have to be a full-blown IT team with services, which is a good strategy to bootstrap some companies. Yes, eventually you’ll need that IT team working with you, there is no denying it, but you can get a lot further without one than you used to.
And on top of that, the tooling itself is growing and adapting to the feedback of the community. Developer Experience is a term that gets thrown out during tooling design a lot more every day, and we can see it in how simple it is to use some of these tools. I think that’s a very smart move, and it will push development speeds and capabilities even further.
What do you think? Is the future looking bright from your point of view?
Bit: Build Better UI Component Libraries
Say hey to Bit. It’s the #1 tool for component-driven app development.
With Bit, you can create any part of your app as a “component” that’s composable and reusable. You and your team can share a toolbox of components to build more apps faster and consistently together.
- Create and compose “app building blocks”: UI elements, full features, pages, applications, serverless, or micro-services. With any JS stack.
- Easily share, and reuse components as a team.
- Quickly update components across projects.
- Make hard things simple: Monorepos, design systems & micro-frontends.
Learn more
- How We Build Micro Frontends
- How we Build a Component Design System
- The Bit Blog
- 5 Ways to Build a React Monorepo
The Evolution of the Modern Web Application Development was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Fernando Doglio
Fernando Doglio | Sciencx (2022-08-29T09:37:18+00:00) The Evolution of the Modern Web Application Development. Retrieved from https://www.scien.cx/2022/08/29/the-evolution-of-the-modern-web-application-development/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.