agraddy.com (Anthony Graddy)

RSS | Twitter | IndieHackers

1. NumbersQ | 2. NetRiv

Introducing TACE

Introducing TACE

Modern web development has become selfish. We moved from an explosive period of growth where the focus was making websites and all of their technologies as open and accessible as possible to a new era where the focus is on developer satisfaction and productivity at the expense of end users.

  1. Background
  2. History
  3. Complications
  4. Current State
  5. TACE
  6. Final Thoughts
  7. Addendum: Learning TACE
  8. Addendum: Framework Compatibility

Background

It has become standard these days to assume front end web developers are using a framework. The original way to build a website using vanilla HTML, CSS, and JS are nowhere to be found. Framework surveys don't even acknowlege this method of development:

If you develop using vanilla HTML, CSS, and JS it is hard to even answer "What is your front end stack?" type questions because even saying you use vanilla JS could mean anything (you could have built a completely custom JS library that generates all the HTML and CSS using no other code libraries and written it by hand in JS). When you answer "vanilla JS" that usually invites other questions like "How?" or "What do you mean?"

History

As a result of the framework emphasis, traditional forms of website development are ignored and many of the principles that formed those foundations are now missing in development conversations. Companies that have a vested interest in creating walled gardens and vendor lock-in are now driving many of the modern JavaScript and design libraries.

The principles that powered a really explosive era of growth in the internet (principles like "separation of concern", the "semantic web", "end user satisfaction", and "open standards") have been replaced with principles like "developer satisfaction", "streamlining collaboration", "managing intellectual capital", and "developer productivity" which have all the hallmarks of development being driven by large technology firms whose main goal is to drive down developer costs and increase output.

As a sidenote, I don't necessarily have a positive or negative issue with those goals, but I do not think they are the proper goals for a healthy, successful, collaborative web community that was being built in the 2000-2010 decade.

Complications

The focus has shifted from the open web and making everything accessible and customizable for the end user to focusing on the developers and making sure the developers can quickly output projects at the expense of the end users.

It has created longer load times due to bloated code, difficult to access interfaces (most of the content isn't loaded until after the JavaScript is loaded which means to parse the contents you can no longer use a simple command line download program, you now must use a browser or simulate a browser with JavaScript functionality), less customizability from the end user, and from my experience, higher chances of a browser crashing or slowing down.

A good example is to compare Twitter (a site developed with modern front end techniques) with Nitter (a site developed with traditional front end techniques) (Nitter is an open source alternative interface for Twitter - it is free and open source and may be down from time-to-time due to Twitter API restrictions or simply server overload on a free service). Try opening these two links using incognito browser windows on your phone (incognito so that you are not logged in):

When this free service is stable, Nitter loads much faster for me (if that Nitter link is not loading properly, you can use this alternative link: https://nitter.it/indiehackers). Now try scrolling as far back as you can on the Twitter link - eventually my browser slows down and/or crashes (note at the time of publishing, it looks like Twitter now puts up a banner to sign up if you scroll too far). If you do the same on Nitter, you can navigate from page to page until there are no longer any posts.

Another test you can run is to use your browser's View Page Source option when you right click and compare the easy to read Nitter output versus Twitter's output. The output of Twitter is a modern mess of complicated scripts while the Nitter output is clean, easy to understand HTML.

I'm not picking on Twitter, they are just one example where it is easy to compare with the alternative. If you want another example, try Reddit and compare it with the free alternative Teddit:

Why are all these popular websites having alternative interfaces created for them? When these sites first came out, alternative interfaces were being created off the free and open API interfaces which offered unique takes on interacting with the sites. These days, companies no longer value the open web or their end users and alternative interfaces are now created to try to escape the increased control of these platforms.

Current State

If you look at the reasons why most companies switch to a modern web stack, it is because their developers wanted to try out the latest technology, or because they wanted to be able to onboard developers as quickly as possible, not because the latest technology actually helps their end users.

Web developers used to be proud of how neat and clean their HTML was displayed when a user viewed the source. Some companies would advertise job openings where only people who viewed their source code would see the job opening. Easy to access source code made it easy for people to learn new techniques and to just learn web development in general. Now when users view the source, they see a link to a JavaScript file that will later load the HTML.

Despite this "developer focus", many developers are frustrated with the constant churn of modern JavaScript front end libraries - most of the reasons for the churn are due to trying to solve problems created by these very same frameworks. Concepts like SSR (server side rendering), HMR (Hot Module Replacement - needed because reloading a web page takes a long time with modern frameworks), Tree Shaking (getting rid of all the bloated code that is not needed), and Lazy Loading (only loading code as needed because it takes too long to load all the code at once). Most of these solutions are really ingenious but they wouldn't be needed if traditional web development was used.

To sum it up, modern web development has become selfish. The only way to resolve this issue is to change the focus from "developer productivity" back to "end user satisfaction."

TACE

If you don't have a name for something, it doesn't exist.

With that in mind, I would like to introduce you to the TACE Front End Framework (rhymes with "ace", pronounced /tās/). The word "tace" is an obscure alternative word for "tasset" which is a type of armor. When you use the TACE framework, you are building sites that are protected from obsoletion (when built properly, they are easily maintainable and updateable in the future) and you are also protected from the constant churn in the industry.

The TACE Framework has four basic principles:

If you follow the above principles, then you are using the TACE framework. Now when asked what framework do you use, instead of saying "I use vanilla JS", you can just say "TACE" to answer the question.

Final Thoughts

There appears to be a shift currently happening again in web development. Statically generated websites are becoming much more popular (it is almost like a violent reaction in the opposite direction of bloated single page apps). Most of these statically generated sites are still using a lot of the modern build tools that I believe cause a lot of developer frustrations (especially for people who are new to web development and trying to figure things out). I would like to see more people move to hand written HTML, CSS, and JS but I think statically generated websites (even if they are built using complicated tooling) is a good direction for the web development community.

For anyone looking to get into web development, I would highly recommend taking a look at writing your HTML, CSS, and JS by hand. It may initially sound awful, but if you are using a solid text/code editor, it will become very enjoyable and give you confidence that you have complete control of your site (you won't have to spend time figuring out why your build tool is throwing an error). Following the TACE Front End Framework principles will help you understand the basics of what is happening when the browser loads your code.

If you have no idea where to start. Start with HTML. Write HTML to match your content and only your content. Once you are happy with your HTML, then write CSS to add styling to your content. Every now and then you may need to make a minor adjustment to your HTML (add a class or move some tags around) but overall you should be able to fully style the page without having to adjust the HTML. Lastly, if you want to add interactivity to the page, then add JavaScript. All the hooks you need should already be there based off of the CSS you've written.

In my opinion, it is much easier to move up a level to modern frameworks when you understand the basics of HTML, CSS, and JS rather than starting with a modern framework and then trying to move down to lower levels of code. What I have found over the years of development is that you learn a lot more and your confidence grows when you understand lower level functionality. But be careful, once you understand the lower level workings, you may not want to move up to higher level frameworks.

So next time you are asked, "What front end framework are you using?" be sure to answer "I'm using TACE."




Addendum: Learning TACE

So if you are just starting out, how do you learn TACE? First, don't get too caught up on trying to learn techniques. Figure out what you want to accomplish, then learn the techniques needed to accomplish what you want.

If you are completely brand new, generally there are at least three file types used, each with a specific purpose. The only one you have to have is HTML:

I recommend visiting sites that breakdown the basics of HTML, CSS, and JS. Here are a few sites I recommend:

General

HTML

CSS

JavaScript (also abbreviated as JS)

JavaScript is an actual programming language used for many purposes outside of web development so the learning can be a bit more complicated and confusing. The good news is that you can build some great websites using just HTML and CSS and then you can sprinkle in Javscript when you need it.

Another thing that makes JavaScript difficult to learn is that is has evolved over the years. The old style code still works, but there are now new ways to write code that works in modern browsers. If you come across JavaScript code that has "var" in it, then it is probably classical style JavaScript and if the code has "let" or "const" in it, then it is more modern style JavaScript. Either style works (I personally prefer writing in classical style JavaScript, but if you are learning, you should probably learn modern style JavaScript since that is what everybody is using these days - also, no one refers to them as "classical style" and "modern style" - those are just my own terms).

Miscellaneous

Addendum: Framework Compatibility

I would encourage you to write your HTML, CSS, and JS directly as much as possible and keep things as simple as possible. That being said, there are frameworks that can help.

Each of my projects for the 12 Startups in 12 Months (Open Source Edition) challenge will be using TACE.

That being said, below is a categorization of various libraries and frameworks. If you know of a modern framework that you believe is TACE compatible, please let me know so I can add it to the list. Also note, that I may have miscategorized projects below. Some of them I know better than others, but I may not be familiar with the latest version as things are constantly changing.

Note, just because a framework listed below is not TACE does not mean I don't think you should use it or that I think it is a bad project. I'm simply trying to define what falls within the TACE framework and what does not.

So what are some practical examples of this.

TACE Compatible

Borderline TACE Compatible

Not TACE Compatible (most of these do not fulfill the Triad principle due to the JS generating HTML)

TACE Compatible Backend Frameworks (these play well with TACE and would be considered compatible or borderline compatible with TACE):

My recommendation is to always write by hand if you can because you have much more direct control of the end result, but if you feel you need to use a framework, hopefully the above list will clarify where the frameworks stand in regards to TACE compatibility.