Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
Your customers do not care about the technology behind your app. What programming language, frameworks, libraries, or whatever tooling you’re using, they don’t care. They care about it providing them value and that it has certain characteristics. They want it to work.
YouTube
Check out my YouTube channel, where I post all kinds of content accompanying my posts, including this video showing everything in this post.
Context Matters
Of course, there’s nuance to this—context matters. For instance, if your customers are developers, they likely care about how the application is built.
This blog/video is inspired by a wonderful tweet that illustrates this point. It mentions that if you want to know why an app needs JavaScript on the client side and can’t just rely on the server, just look at Hey or any other Hotwire app where they simulate a slow connection. When you click on the plus icon to add a new entry to your calendar, it shows how long it takes to actually render it.
To explain the slow performance in the example, you’re simulating a slow internet connection in the browser. The app makes a round trip to the server to get the HTML, which is then sent down to the browser for rendering. It’s not that the server was slow; it could be rendering the HTML quickly.
The issue lies in the added latency of making that network call to retrieve the HTML in the first place. This is the crux of the tweet’s argument: if you used JavaScript on the client side, you wouldn’t need to make that network call and could render the content immediately.
It’s not that your app needs JavaScript; rather, it should avoid unnecessary network calls that introduce latency. The industry often ignores the fallacies of distributed computing, acknowledging them at times and ignoring them at others.
For instance, the first three fallacies state that the network is reliable, latency is zero, and bandwidth is infinite. The tweet highlights that latency isn’t zero, and we should be mindful of that.
Now, why has the industry, over the last decade, adopted request-response over HTTP as the de facto implementation of microservices? Are we acknowledging the latency issues or not?
I mentioned earlier that I don’t think your customers care how you build your app with programming languages or tools. They just want it to provide value. If your customers are end users of an email calendar app, for example, they won’t care if it’s built with Ruby on Rails. They want the app to meet their needs and have the characteristics they prefer.
So, does every app need JavaScript? No, it just needs to avoid making useless network calls that add latency. We need to optimize our apps. For example, using live modals that preload content can solve many performance issues.
And for some more fun, this Retweet/comment sparked a larger discussion.
I don’t think people are okay with producing garbage. Gnerally, they are doing their best given the constraints and knowledge they have.
One response from Aaron Francis highlighted the responsibility to provide for his family, which drives his decision-making. If you have to choose between a paycheck and what’s considered great UX, many will choose the paycheck. There are many constraints that inform these decisions, including skill levels, knowledge gaps, and different tastes.
Recognize that context is king. It helps you make informed decisions and understand why others make the choices they do. This conversation began around the slow rendering of a popup. Could client-side JavaScript fix the issue? Absolutely. But the developers resolved it by simply avoiding unnecessary network calls and preloading content.
Can you build an app that people use and find value in, even if some parts are considered garbage? Yes. Conversely, you can also create an app that’s technically perfect but offers no real value, leading to it being ignored by users. In many business systems, the real value lies in capturing workflows and streamlining processes.
Speed is not just about how quickly things render but also how efficiently users can navigate and perform their tasks within the application. As developers, we often focus on rendering speed and latency, but we should also consider the overall workflow experience.
If you’re screaming that you, of course, care about the underlying tech, then I’ll give you another example. If you’re a decision maker deciding to buy an ERP, of course, you likely care about the technology platform the system is built upon. You’re proving my point, context matters.
Join CodeOpinon!
Developer-level members of my Patreon or YouTube channel get access to a private Discord server to chat with other developers about Software Architecture and Design and access to source code for any working demo application I post on my blog or YouTube. Check out my Patreon or YouTube Membership for more info.