I've never pursued learning much history. I know it's vital for reference, but I get a bit lost in the facts without some context in mind or a problem that’s being solved. It turns out, trying to build websites on old computers is just the sort of problem that I can firmly set some historic context around.

I found myself discussing the history of web programming with my dad recently and oddly found that explaining it to someone outside of tech helped me simplify. I want to share that with you as best as I could render, as I think it puts some events into perspective and provides us with a glimpse into what’s to come.

The Web Inverted

Before JavaScript

Way back, becoming a proficient programmer was a pretty challenging endeavour. It was challenging because it took a lot of time to make anything happen. It took time to learn systems by inputting commands on hundreds of physical cards (even to do something simple) and waiting to see if your code could run. When it didn't run, you'd have to investigate why, make a change, and repeat. We can often repeat this same cycle in seconds, and, as a result, it's much easier to learn to program today.

I think that the emergence of incredible teenage and young adult programmers in the 80s is partly due to these mechanics. Who else had the time it would take to write and debug a program?

Perl, C Lisp, and COBOL are some early languages that added shortcuts and common structures that helped programmers solve fewer problems to get work done. Battles between languages got fierce as groups tried to settle on the best way to do things. Lisp is a technically better language (faster, mainly) than the rest but was never widely adopted because programmers needed to shift their coding methods dramatically.

None of this was web-centric at the time. I mean, the web wasn't generally around. Networked devices and computers were, but nothing was user-facing in the same way that the web is today.

The "Good Old Days" and the creation of JavaScript

C++, Java, Ruby, and C# brought with them Object-Oriented Programming (OOP). These provided an even simpler shorthand that let people think of their programs as objects sitting on a desk. I call this the "Good Old Days" because this is where many of today's lead programmers came into the coding scene.

It's also around here that the web got its start. We linked hard drives to the web to build pages that didn't change much. Later we realized that we could produce better pages if we had some programs on our servers to change the files sent to users.

For example, a bank's web page only showed a brochure for their services on the web. However, now they could build websites where customers could check their bank balances and even buy other services from the bank. The server just needed to keep track of everything.

Interactivity and personalization expanded the web right up and through the crash in 2000 and into the modern web. Throughout this time, a language called JavaScript was further developed to help manage these new web pages. It was very early still, but JavaScript had started a significant transition.

Inverting the web with the emergence of SPAs

JavaScript dramatically changed how we thought about making websites. Before JavaScript, for a website to do anything interesting, we'd need to create another program to build the webpage. It was similar to a factory where a user would request a webpage, and our factory would figure out how to make the page the user requested. It was a slow crawl to improve user experiences because so much had to be done in the factory. The factory was large, cumbersome, and prone to break down if pushed too far.

With JavaScript, we could send customers code to run on their side! It meant that we could go back to just sending files without a factory, but we needed to provide some means to interact with our servers. So we made APIs that gave these programs a way to get data from our services and trigger processes important to companies.

SPAs (Single-Page-Applications) emerged, which further improved the customer experience on these websites. Before, when users clicked on links, the whole page would go white, and there would be a long pause while they connected to our server and into our hard drive to get the needed files. This was annoying and cost companies money because customers would get distracted and forget that they were purchasing something.

SPAs allowed some of the pages to remain with only part of the page loading as the user moved from page to page. Less had to be retrieved, and some of the data could even be reused! Gmail was one of the first applications to do this and quickly solidified Google as a tech champion in this period. There was a little bit of bloat from the program getting a bit more complicated, but it was still a better experience for the end-user.

JavaScript frameworks like Angular, React, and Vue sprung up to help provide developers with managed paths to build SPAs and other, now standard, web code. These fit the same sort of role as programming languages from before and became, once again, opinionated about "the right way to do things."

Rangle started out using Angular and helped establish many SPAs for our clients as we believed that the web had been "Inverted." Teams trying to push an application through the server "factory" toward customers could start with the customer-facing web program and then develop server programs to help serve that web application.

The present web

It's been a bit of a wild ride so far. We've seen hard-to-test systems simplified by the emergence of programming languages. Then the web's evolution was helped by a change toward building nimble apps over servers. And lately, it's getting even crazier.

New concepts with growing adoption

SPAs have gotten way bigger as mobile devices continue to attract new users. These changes have caused many apps to load slowly and pushed web users to have more expensive network plans. To spur improvement, many major companies like Google have put their weight behind technologies that can help keep more users on the web.

Over the last few years, a concept called "the JAMStack" led to the creation of site-builders like Gatsby and Next.js. These are built on top of a framework, like React, and go further toward simple files served on hard drives (just with more, smarter, steps).

Even more recently, Remix was released, which proposes that we've actually been evolving the web the wrong way all this time. Current SPA application architecture is slow and having smaller, smarter, and more modular factories is really the right approach.

Web 3.0 has us asking what the blockchain can do for us when it comes to the web, and there is some interest there. It's still the early days, but I'm sure someone will find some strange way to solve business problems with it.

Looking ahead

As we look forward, we're evolving with the customer in mind. While we may focus on a single programming language, you can see that there are increasingly specific evolutions within our applications. The entire industry is working to find more efficient means of running applications on the web and the frontend has evolved into an opportunity to tackle more than just presentational information but the entire customer experience for billions of users.

If you're still learning web development, I'd recommend you level up on your fundamentals and get to the forefront quickly and join us where we're solving problems today. Depending on what we discover, a lot could change in the coming years, and you don't want to miss it.

Sign up for our newsletter and stay tuned for the latest blogs, podcasts, and news from Rangle.