The Vue.js introduction video #
I've heard really good things about Vue.js, so I had an interest in poking around. I'm not strong in Javascript. My expertise is centered around HTML & CSS. I'm not usually in the need of a framework, but I still like to know what is out there for use, in case a need should arise. So, I watched the introductory video.
The presenter in the video talks about how it is possible to use Vue to create “a richer, more interactive experience” by using it for a portion of your application. Yeah, I can get behind that. I used jQuery like that, back in the day. It's what drew me to DOM Scripting. I wanted a bit more interaction. In the early part of my career, the separation of concerns were listed as the following:
- Markup (HTML): defining the content as semantically as possible.
- Stylesheet (CSS): defining how the content should look and be presented.
- Script (JS): defining how the content should behave based on some triggers.
Progressive Enhancement encouraged writing the code to render a website, in that order. I still encourage this today.
It is my understanding that the lines began to blur between style and interaction very early on—when links could be altered with a:hover & a:active styles defined. Puritans said this was interaction and belonged in Javascript's domain. The ship has long since sailed on this one, so arguing about it is of no value here, but I can't fault the logic in the statement. This occurred long before the days of CSS animation and transforms. As more of this kind of functionality becomes part of CSS, I find fewer reasons to need Javascript. I am aware of the implications and muddiness in separation of concerns as CSS gets more powerful and, seemingly, interactive. But I digress...this post is supposed to be about Javascript frameworks, not CSS. That's a different post for a another time.
The presenter in the video made a comment that spurred me to write. He said, “Or if you want to build more business logic into your front end from the get go, Vue has the core libraries and the ecosystem you'll need to scale.” That's the sentence I would really like to dig into in this post.
Business logic in the front end #
Why? Seriously, I'm asking. I am not, nor do I have any desire to be, a back end developer. I love that I have friends and coworkers who specialize in this area. I heavily rely on them to be good at that, so I can hone my craft on the front end. They (back end devs) handled the business logic, while I (front end dev) handled the interface. That was quite a lovely separation of concerns in its own right. It's not as though either side didn't have enough work to keep busy, right?
I have been around long enough to hear the purveying thought that putting the business logic on the front end allowed the web app to be more performant because it didn't have to make a trip to the server to do anything. It was all right there, ready to be called upon. Ok, I can see some merit to that idea, but is it a reality?
According to HTTPArchive for the past 3 years sites have been getting bigger:
- Total kilobytes are up 77.8% for mobile and 28.1% for desktop.
- Total requests are up 16.7% for mobile, but down 8.5% for desktop.
Focusing just on Javascript, HTTPArchive reports:
- Transfer size of kilobytes is up 50.8% for mobile and 36.3% for desktop.
- Number of external requests is up 26.7% for mobile and 11.1% for desktop.
It stands to reason that because so many people use mobile devices for just about everything these days, that sites are doing stuff for mobile and the stats reflect that. I have to wonder, is the development community paying attention to all the advocacy reminding us that mobile's network speeds and wild fluctuations at any given point in the transfer make it less reliable to get the data to the user to begin with?
Let's focus on mobile for a moment... #
HTTPArchive shows that the median time it takes for the page's primary content to appear on the screen takes 5.8 seconds, up 20.8% over the past 3 years. Google has been warning us for awhile now that 53% of mobile visits leave a page that takes longer than 3 seconds to load. That means that a large number of visitors probably abandoned these sites because they were staring at a blank screen for 3 seconds, said “fuck it,” and left approximately half way before the page showed up. The fact that the next page interaction would have been quicker—assuming all the JS files even downloaded correctly in the first attempt—doesn't amount to much if they didn't stick around for the first page to load. What was gained by putting the business logic in the front end in this scenario?
Scale, the almighty #
The presenter in the video introduction for Vue also mentioned building for scale. Not growth, but scale. I am of the opinion that web apps focused on scale have over-optimized in anticipation of a reality that may never come. As a result, bloat happened.
How many features are built-in to a framework or library that your app doesn't need yet (and may never need)? How much can you hold back from the package you send to the web? How dependent are these modules and bits of code on one another? To me, that sounds like a lot of analysis up front to pick apart a tool before I even write a single line of code to be truly productive. It is also the antithesis of Progressive Enhancement, which strives to start with the bare minimum necessary to make it work and build up from there.
For example, HTML works all by itself. Literally. CSS and Javascript are not required to build an entire interactive website. It's not going to be charming or fit your brand, but it will work. That's about as MVP as MVP can get! It also doesn't require a swath of node_modules to start building something.
So, the question really is: does your project need to think about scale at this point in the building process? I think the assumption is that it is never too soon to prepare for scaling. I disagree. Make it work first. Then think how to scale, because if you don't work in this manner, scale isn't actually happening in reality, only in theory. See the Google stat I mentioned earlier about 53% of the traffic likely bailing on the website/app. Chances are, you're losing potential visitors, customers, and revenue.
There was a mini discourse about scale on Twitter. It is these conversations that support the notion that if you are building for scale before there is an actual need to, you are likely stunting the growth of your product/app/service, preventing it from actually succeeding.
Bridget, why do you hate joy? #
I don't. It's just that the Vue introductory video was the unfortunate catalyst to this diatribe, based on a single sentence less than 50 seconds in. As an industry, we need to get better at applying critical thinking and thoughtful analysis before we start writing code.
My friend, Chris Miller, has a sign hanging in his office that says, “First, solve the problem. Then, write the code.” According to a web search, it appears that John Johnson said it. I smile every time I see it, at least on the inside. Too many times the tooling gets selected, then the code gets built, then sharing the work for admiration, then find a problem that it might solve. Not every situation is like this, but too many are. It's tiring.
I'm going to return to the introductory video now, to see if I can imagine when I might find a good use for something like Vue.