DEV Community: Aaron Choo

Relating SOLID principles to CSS and Tailwind

Aaron Choo — Mon, 19 Oct 2020 13:13:34 +0000

This is the second (and last) article in the series. If you haven't read the first one yet, which discussed basic ideas of how to apply OOP concepts to CSS, you might want to catch up on it first:

Applying OOP concepts to CSS

Aaron Choo ・ Oct 16 '20

#css #html #oop #tailwindcss

In this article, we start by introducing the SOLID principles into our CSS, and then relate everything back to Tailwind.

Single Responsibility Principle in CSS

The Single Responsibility Principle (SRP) states that every module, class or function should have responsibility over a single part of that program's functionality, which it should encapsulate. What it means is that every CSS class (or object as we have defined) we write should only have a single function or use, and it should do it well. Going back to our button example in the first article again, the CSS for .base-btn was as follows:

.base-btn {
  border: solid 2px cyan;
  color: white;
}

This class actually violates SRP, because it has two different responsibilities: one to style the border, and another to style the text colour. In OOP fashion, we can say that the .base-btn class has more than a single reason to change (either to change the style of the border, or of the text colour). To try to remedy this, we can split the class up like so:

.btn-border {
  border: solid 2px cyan;
}

.white-text {
  color: white;
}

However, one can say still that the .btn-border class violates SRP, since it actually contains styles for three different aspects of a border, and thus has more than a single responsibility. As such, we can split it up even further like so:

.solid-border {
  border-style: solid;
}

.width-2px-border {
  border-width: 2px;
}

.cyan-border {
  border-color: cyan;
}

.white-text {
  color: white;
}

Now, each class truly has only a single responsibility and a single reason to change. However, the disadvantage is that what once took us 4 lines of CSS, now takes at least 12 lines (3 for each of the 4 classes), 3x more than what we started with! Note however, that this is a trivial example, and not representative of what is seen in practical settings. Since the classes defined here truly has a single responsibility, another person could also argue that you can use these classes in other parts of the HTML, without duplicating a single line of CSS, and therefore save more lines of CSS in the long run.

Remember that the purpose of SRP is so that the styles defined within a class is highly cohesive, thereby increasing the chance of reusing this class somewhere else. What this essentially means is the result of smaller classes, but many more classes, which may lead to more CSS than what we started with.

Always remember, that there is always the tradeoff between developer experience and code size, and always a certain overhead in adhering to any principle. For a small and trivial website, the benefits of adhering to SRP blindly might not be apparent, and may even hamper development.

Open-Closed Principle in CSS

The Open-Closed Principle (OCP) states that classes should be open for extension, but closed for modification. In CSS, it means that if we were to have base classes defined (eg, .white-text, .blue-border), we should try to avoid modifying it directly, but instead extend from it. Implicitly, this makes sense because any modification to the base .white-text class will most certainly affect all the HTML tags which use and depend on this class - something which we want to avoid.

In the previous article, we have already seen the idea of composition, which plays nicely together with OCP. Instead of modifying the base classes which already exist, we should instead compose them together to form our eventual style.

Of course, you could go the other route: use the base classes as defined, but override the undesirable rules using !important. However, this actually violates another one of the SOLID principles (discussed later, don't worry), not to mention the fragility of using !important to override your own CSS.

Liskov Substitution Principle in CSS

The Liskov Substitution Principle (LSP) states that objects of a superclass should be replaceable with objects of its subclasses without breaking the application. If you do not use a CSS processor like Less, Sass, or Stylus, this section might be less applicable to you. I'll admit, however, that this section isn't applicable to me either, not because I don't use CSS processors, but because I much prefer composition over inheritance.

I highly recommend this article, Should You Chain or Extend CSS Classes, which talks in great length about the advantages of composition over inheritance. Of course, this makes me sorely unqualified to talk about this section. Nevertheless, here is an article you can refer to regarding LSP in CSS if you aren't yet convinced about only using composition.

Interface Segregation Principle in CSS

The Interface Segregation Principle (ISP) states that no client should be forced to depend on methods it does not use. In terms of CSS, it can be easily rephrased to say that every block of CSS rule you write should not override any rules being composed.

Similar to previous examples, let's start with the base .base-btn class:

.base-btn {
  border: solid 2px cyan;
  color: white;
}

Now, remember in the OCP discussion, we raised the possibility of overriding the base styles? Let's try that to style a button using base-btn, but with green text:

<button id="base-btn green-text">Press Me!</button>

<style>
.base-btn {
  border: solid 2px cyan;
  color: white;
}

.green-text {
  color: green !important;
}
</style>

This clearly violates ISP, because the button depends on .base-btn, which has a defined rule for the text colour, but which the button actually doesn't want. By adhering to SRP and defining multiple (but very specific) base classes with a single responsibility only, this violation could have been easily avoided.

Again, it's a tradeoff between defining more specific base classes (high cohesion and loose coupling) versus defining one big general one (maybe more code reuse). If you do find yourself constantly overriding base styles like the above example though, it is a clear indication that your base classes are too fat, and that it's time to separate it out into more specific base classes.

Dependency Inversion Principle in CSS

The Dependency Inversion Principle (ISP) states that high-level modules should not depend on low-level modules, and both should depend on abstractions. In the general sense, the point of adhering to ISP is to reduce coupling between modules and promote module independence.

In HTML and CSS for example, it shouldn't matter to the parent div container (higher-level module) how the components within it (lower-level modules) are styled, as long as it doesn't break the layout, and vice versa. With this context, the excessive use of descendent and child selectors is a sign of the violation of DIP, since the descendent element is clearly dependent on its ancestor.

As such, instead of writing nested rules like .container .panel > .card for a nested card, writing a specific class like .first-inner-panel-card is preferable, because this class has a higher chance of further reuse in other parts of the HTML which doesn't have the same structure.

Linking it all back to Tailwind

If you are still reading (thanks!), the conclusion for this series is obvious: linking all of what we have discussed to Tailwind. Like mentioned at the start, this paradigm is not new; one can simply look towards existing frameworks and methodologies like OOCSS, BEM, and Atomic CSS for example. And looking at the reactions toward these frameworks, it is thus not surprising to find the same criticisms surrounding Tailwind.

The truth is, adhering to any framework (or to the principles discussed here) is a legitimate overhead, and one which demands developers to bear the upfront cost of. With a small project, the benefits are not immediately obvious, and may sometimes even be detrimental.

If you are looking into using (or have used) Tailwind, I certainly hope you are able to spot the clear parallels between OOP concepts, SOLID principles, and Tailwind. Tailwind describes itself as a utility-first CSS framework, which really just means that every utility class in Tailwind is designed to respect SRP, where each and every class is as independent and as loosely coupled as possible. If you look back at the last example given in the SRP section, where each class defined only has a single CSS rule and responsibility, we have essentially done up a small version of Tailwind (albeit with different class names).

In other words, Tailwind is actually just a framework which adheres strongly to the SOLID principles. Why bother coming up with your own CSS classes, trying your best to adhere to all the concepts and principles discussed here, when there is already a solid tool out there? This is not to say that once you use Tailwind, you're on your way to cleaner CSS however; there are still plenty of ways to mess it up.

So why the controversy?

As a Computer Science student, Tailwind clicked almost immediately for me, but it wasn't until recently that I found the link between Tailwind and OOP/SOLID. I've found that using Tailwind made my CSS much more maintainable, and for someone who didn't really like writing CSS, Tailwind actually made it enjoyable. So why is it that some people just really dislike it?

If I had to guess, I would say that the people most likely to write CSS are designers (or bootcamps graduates), and not necessarily programmers who are classically trained in Computer Science. Nothing against these people, but it is arguably difficult to understand OOP (we were all there once!) while adhering to the principles stated here. One reason, already discussed greatly by others, is that for someone writing CSS "their way" for all their lives, it takes a lot for them to break their habit and adopt a totally new framework. However, I would argue that if the framework is good enough (which in my opinion, Tailwind is), then there is no reason why someone would not want to change.

My theory is that those who dislike Tailwind are in one of these two groups:

Those who cannot yet relate Tailwind to the OOP concepts and SOLID principles discussed in this article, and thus doesn't understand the benefits of Tailwind
Those who can relate, but simply dislike the OOP way of doing things

If you are in the second group, then it explains why Tailwind is so controversial: because OOP itself is controversial. If you are in the first group, even though I didn't even touch on how to use Tailwind, hopefully this series has given you a deeper understanding of how and why Tailwind works in principle. So go ahead, try it out!

Applying OOP concepts to CSS

Aaron Choo — Fri, 16 Oct 2020 04:30:17 +0000

Series introduction

Recently, Tailwind has seen a large explosion in growth: going from 390,000 npm downloads in Oct 2019, up to 1.8 million downloads just last month. This unprecedented popularity comes with it the Java phenomenon: deeply polarising views within the community where there are those who love it, and those who simply hate it (not to forget those that can't decide as well).

However, this series is not going to be about whether you should or should not be using Tailwind. Rather, this first article will attempt to be an introduction to some OOP concepts, and how they can be applied to writing cleaner CSS. The next article will then dive deeper into the SOLID principles, and how Tailwind relates to all of these. Then, perhaps we can even rationalise why there is such a large divide in the community regarding the use of Tailwind.

Object-oriented programming in CSS

Let's start applying object-oriented programming (OOP) principles to CSS. Firstly, a disclaimer: the idea of object-oriented CSS is not new, and has been around for quite some time. However, there is a lack of articles clearly linking OOP concepts to CSS. If the explanation given here confuses you, you may want to take a peak at the extensive OOCSS wiki. Note, however, that some definitions used here may differ.

Also, there are quite a few concepts related to OOP - and only a couple which can best be applied to CSS. As such, this article will only touch on the following concepts: encapsulation, abstraction, and composition.

Objects in CSS

Firstly, let's define what an "object" is in CSS. In OOP languages like Java, it makes sense to have objects like Car or Elephant which clearly have well defined states and behaviours. What then, represents an object in CSS? For simplicity's sake, let's define an "object" in CSS to be synonymous with selectors.

For example, here is a class selector and an id selector, both with defined styles within them, and which we can refer to as two different objects, .object-1 and #object-2:

.object-1 {
  /* styles here */
  /* ... */
}

#object-2 {
  /* styles here */
  /* ... */
}

Note that this definition is not official, and is nothing more than syntactic sugar made to drive the concept closer to OOP. With that, let's start!

Encapsulation in CSS

Encapsulation is the process of grouping logically related data and operations together in an entity. Basically, things which make sense to be together, ought to be together. Every block of style you write in a CSS selector (or "object" as we have defined) can essentially be taught of as a single encapsulation. Note that there are good ways to encapsulate code and bad ways to encapsulate code.

As an example, let's try building a simple HTML button. This button should have a 2-pixel border that is cyan in colour, white text, and a teal background (yes, gruesome design, I know). In the CSS of the following snippet, we have a #teal-button object, which is an encapsulation of the styles needed to style the button:

<!-- HTML -->
<button id="teal-button">Press Me!</button>

<!-- CSS -->
<style>
#teal-button {
  border: solid 2px cyan;
  color: white;
  background: teal;
}
</style>

Now, what happens if we want to have a similar button, except with a red background this time? Well, if we do not want to refactor our previous code, here's an easy way:

<button id="teal-button">Press Me!</button>
<button id="red-button">Press Me!</button>

<style>
#teal-button {
  border: solid 2px cyan;
  color: white;
  background: teal;
}

#red-button {
  border: solid 2px cyan;
  color: white;
  background: red;
}
</style>

Notice that we have redundantly duplicated portions of the CSS. Is there a need to have the same styles for border and color in two separate places? This is a classic example of the violation of the aptly named Don't Repeat Yourself (DRY) principle. In OOP, we would have said that the #teal-button object and the #red-button object have similar states which could be better aggregated or encapsulated into a common, shared object:

<button id="teal-button" class="base-btn teal-bg">Press Me!</button>
<button id="red-button" class="base-btn red-bg">Press Me!</button>

<style>
/* contains styles common to both buttons */
.base-btn {
  border: solid 2px cyan;
  color: white;
}

.teal-bg {
  background: teal;
}

.red-bg {
  background: red;
}
</style>

As your app grows and as you add more buttons of different background colours, using the first approach means that your CSS will grow extremely fast. Refactoring will also be an absolute nightmare. For example, in the second approach, a single line of CSS has to be modified to make all buttons change their borders to green. How many lines of CSS do you need to modify in the first approach for the same effect?

It is easy to reason to yourself how the second approach promotes code reusability, while reducing unnecessary code duplication. Writing less CSS comes with it two clear advantages:

Smaller bundle size for your built website
Much better developer experience (no more waddling over pages of id selectors, or changing multiple pages of CSS just to have a consistent design)

Abstractions in CSS

Abstraction is the process of hiding the internal working of a process from its end user. Do not confuse this with encapsulation, which is the act of grouping things together in an entity. Abstractions rely on encapsulations: we group things together in an entity via encapsulation, and then expose that entity as an abstraction for the end user to use. This way, there is no need for the user to know how the entity is implemented, only what it does.

In CSS, the end user is actually yourself and your fellow developers. Using the same example above, we have actually practised sound abstractions by defining the teal-bg and red-bg classes. There is no need to look at the actual implementation of the CSS classes to know that the teal-bg class is obviously applying the teal colour to the background.

Similar to encapsulation, there are good and bad ways to abstract things. In the previous example, the base-btn class does not immediately give us a visual understanding of how the button is implemented. Does this mean that the base-btn class is bad? Well... It depends, and we shall leave this to the next article. What we do know is that the act of using semantic names for classes is one of the ways abstractions can be effectively used in CSS.

Ok, you might be asking, but what is the point? Let's have another example, where we want to make a button, and a paragraph, both with blue texts. If you have been paying attention to the previous section, we now know that we should avoid repeating the same code via encapsulation. As such, we can come up with this:

<!-- HTML -->
<button class="blue-text-button">Press Me!</button>
<p class="blue-text-button">Here is some text...</p>

<!-- CSS -->
<style>
.blue-text-button {
  color: blue;
}
</style>

Yes, this fits the design specifications perfectly fine, and we have also managed to not repeat ourselves. But the issue with this is that the HTML/CSS has lost their semantic meaning. Without looking at how the CSS is implemented, do you know what exactly the blue-text-button class does? Should the button word be part of blue-text-button if it does not even style a single part of the button? More importantly, why does the p tag, which clearly isn't a button, depend on the CSS class whose name has button in it?

In order to let your fellow developer (or yourself in the future) understand immediately what you are trying to achieve, a better approach will be to rename the blue-text-button class to blue-text. Now, with sound abstractions, it is immediately obvious what this snippet is trying to achieve, without even looking at the implementation of the CSS:

<button class="blue-text">Press Me!</button>
<p class="blue-text">Here is some text...</p>

Of course, one could argue that the above CSS implementation is trivial, and does not detract one from immediately understanding what blue-text-button does by looking at the CSS implementation. What about this case where your website has a custom colour palette:

<button class="custom-colour-1">Press Me!</button>
<p class="custom-colour-2">Here is some text...</p>

<style>
.custom-colour-text-1 {
  color: #51c6e0;
}

.custom-colour-text-2 {
  color: #5be051;
}
</style>

Even looking at the CSS implementation wouldn't save you (unless of course, you memorised the hex colours...). Assuming the colours are part of your company/brand, and which probably will not change for quite some time, a better approach would be to name the classes like so:

.brand-blue-text {
  color: #51c6e0;
}

.brand-green-text {
  color: #5be051;
}

Now, you can safely use the class brand-blue-text or brand-green-text anywhere in your HTML, where you and your fellow developers will immediately know that what you are trying to achieve.

Compositions in CSS

Composition is the act of modelling a has-a relationship between objects. For example, a car has an engine, and a human being has a heart. Again, if you are sharp enough, the use of composition have already been demonstrated in very our first example. Instead of putting all the styles into #teal-button, we have instead defined two different classes, .base-btn and .teal-bg, from which we then compose together to make the original style of #teal-button.

The whole idea of composition is to reuse existing code, reduce unnecessary code duplication, and to design cleaner CSS (basically the whole point of this series if you haven't got the memo yet). Let's reuse our first example again, except with one more green coloured button this time:

<button id="teal-button" class="base-btn teal-bg">Press Me!</button>
<button id="red-button" class="base-btn red-bg">Press Me!</button>
<button id="green-button" class="base-btn green-bg">Press Me!</button>

<style>
.base-btn {
  border: solid 2px cyan;
  color: white;
}

.teal-bg {
  background: teal;
}

.red-bg {
  background: red;
}

.green-bg {
  background: green;
}
</style>

Now, say for instance we want to add a 8px padding around the teal and red buttons only (ie. the green button should stay as is), what would be the best way to do this?

As our first try, we could define this padding within .teal-bg and red-bg:

.teal-bg {
  background: teal;
  padding: 8px;
}

.red-bg {
  background: red;
  padding: 8px;
}

However, this violates what we've learnt in abstractions: it's utterly confusing for the class teal-bg to also apply padding when the name of the class clearly has no mention of padding in it. To remedy this, we could rename the classes, which would then require us to refactor all the instances in which the original teal-bg/red-bg has been referenced - not ideal.

For our second try, we can instead put the padding style in base-btn, which would require an !important in .green-bg to override the padding (remember that the green button also takes .base-btn as a class):

.base-btn {
  border: solid 2px cyan;
  color: white;
  padding: 8px;
}

.teal-bg {
  background: teal;
}

.red-bg {
  background: red;
}

.green-bg {
  background: green;
  padding: 0px !important;
}

Now, however, we've made our CSS really fragile and dangerous. For a component with a defined padding, applying green-bg to it will lead to that component losing its defined padding - not ideal.

The better approach is to define a class just for the padding, which we can then compose with the teal and red buttons like so:

<button id="teal-button" class="base-btn teal-bg padding-8px">Press Me!</button>
<button id="red-button" class="base-btn red-bg padding-8px">Press Me!</button>
<button id="green-button" class="base-btn green-bg">Press Me!</button>

<style>
.base-btn {
  border: solid 2px cyan;
  color: white;
}

.teal-bg {
  background: teal;
}

.red-bg {
  background: red;
}

.green-bg {
  background: green;
}

.padding-8px {
  padding: 8px;
}
</style>

Now, this looks much better! We have encapsulated the common padding style into a single class, and abstracted it such that the class name padding-8px makes sense. By not modifying the other existing classes, we have further reduced the risk of breaking anything which relies on them. Notice also, that by reading the HTML only (without reading the CSS), we can still visualise roughly how the end product looks like.

Conclusion

That's it, now you're on you way to writing cleaner CSS! We have only just scratched the surface here regarding OOP and object-oriented CSS. In the next article, we shall dive more deeply into exactly why some of the negative examples shown here are bad, and actually start looking at Tailwind and the SOLID principles.

Display LaTeX Math in GitHub Markdown Previews

Aaron Choo — Sun, 16 Aug 2020 13:43:28 +0000

TLDR: install the Chrome extension, or check out the MIT licensed repo:

AaronCQL / katex-github-chrome-extension

A chrome extension to display LaTeX flavoured math in GitHub Markdown previews.

Motivation

As a computer science student, I primarily take my course notes in Markdown, which would eventually be pushed to GitHub. However, it's 2020 and GitHub still does not support $LaTeX\LaTeX$ flavoured math when previewing Markdown content (GitHub please...).

There is already an existing Chrome extension for this exact use case. However, I was unable to load the package via the Chrome store for some reason, and had to load the raw package from the GitHub source.

Initially, I was happy with it, but I soon felt that the rendering becomes really sluggish when the Markdown file grows sufficiently large (probably because it uses MathJax internally). Moreover, GitHub recently revamped their website, and it now behaves more like a SPA. This means that some internal navigation in the loaded web page does not refresh the whole page, resulting in the extension failing to render the math.

Features

This new extension serves to solve the above problems. It uses $KaTeX\KaTeX$ internally for fast and efficient rendering. It is also able to detect and work with the SPA-like internal navigation, and will even render the math when editing Markdown content (when clicking Preview changes). For now, it only targets Markdown previews, leaving code blocks and code previews untouched (since this is my exact use case).

Conclusion

This project is relatively new - if you happen to find any bugs, feel free to open an issue. I have already documented some known issues which I do not yet have answers for (if you happen to have a solution, please open a PR 😁).

Is Vue 3 Composition API Worth It?

Aaron Choo — Mon, 22 Jun 2020 14:04:55 +0000

The short answer is "yes". But I suspect that you are going to need more than a random stranger telling you a one word answer.

There has already been numerous posts and articles talking about the advantages that the Composition API has over the Options API. From the official RFC to this particular DEV post which also discussed about the controversy behind the Composition API when it was first introduced back in 2019.

I am not, however, going to repeat the points about code reusability, or code organisation (both of which have already been discussed in great lengths in the above links). In this article, I am going to focus more on the development experience.

Problems with Options API

As someone who also develops in React, I definitely agree that Vue's Options API is much more intuitive and much easier to grasp for a beginner. I mean, data for your reactive data, computed for data that relies on data, methods for functions that act on data: how much easier can it get? This simplicity was one of the main reason why I gave up on learning React (back when I first started!), and decided to try Vue, and the rest is history.

However, as we all know, the Options API forces us to use the this keyword, and prepending everything with the this keyword leads to various caveats and problems.

Poor Type Inference

Firstly, the IDE (or at least VSC, in my case, which is my daily driver) is unable to infer the type of the variable declared. Take for example, this simple case:

export default {
  data() {
    return {
      arr: [1, 2, 3]
    };
  },
  computed: {
    twiceArr() {
      return this.arr.map(x => x * 2);
    } 
  }
}

While writing the twiceArr computed property, the lack of type inference means that the IDE is unable to bring up suggestions for array methods when you are typing this.arr. Moreover, say a few weeks from now, and somebody decides to change the data arr from an array to an object like {}. This means that this.arr.map() will throw a runtime error (since objects do not have the map method). Ideally, the IDE should warn about this illegal statement, except that it cannot, because it is unable to infer the type of the data arr.

Of course, this may sound more like a minor nuisance than an actual problem. However, when your app grows big (which it will!), and when different developers come into the same project, it will really stymie development speed and add on to the confusion.

Really Weird Bugs

This I am sure many Vue developers have experienced before. Knowing the difference between a normal function function() {} and an arrow function () => {} and how Vue binds the this keyword differently in them is not something I would exactly call beginner friendly. Stackoverflow for instance has more than a few questions asking for this exact same problem (1, 2, 3 to name a few).

For example:

data: () => ({ // arrow function =(
  user: "Timmy",
  userCopy: this.user // undefined!
}),

I remember in my first few months of learning Vue, I made the mistake of writing my data with an arrow function like the above, and pulling my hair out, because I cannot figure out why userCopy was returning undefined!

Yes, to somebody more experienced, these are not weird bugs and are well documented features when you actually learn about how Vue works under the hood. However, you do not really expect a beginner to learn how the framework works when he is just starting out.

Difficult to Collaborate

Which leads me to my last point: collaboration is rather cumbersome. Type inference, type checking, and static code analysis are one of those few things that you only notice when you suddenly have to deal with their absence. If you are not yet a TypeScript convert (or have otherwise not used a statically typed language before), this point might sound foreign to you.

Even so, I believe that anybody who has worked with a non-trivial project with a significantly large codebase (upwards of 10K LOCs) would experience the pain of working with one. Do you often find yourself taking much longer than usual trying to understand and trace the SFC code not authored by you (or which you have written a while ago)? Jumping within the data to the methods section, to the lifecycle hooks and to the actual template before forgetting what the relevant function defined in methods did?

OK, I did mention that I was not going to talk about code organisation. But the point remains: with better type inference and static analysis, it would make collaboration and understanding the code much easier, especially when you have confidence in the types that you are using and/or returning.

Benefits of Composition API

If you did not know already, Vue 3 itself was rewritten with TypeScript. Watch this great talk by Evan You about the design considerations with Vue 3, and why the team have decided to go with TypeScript.

The short summary is: Vue 3, together with the Composition API, solves all of the pain points mentioned earlier, and helps make your developement experience much better. For example. in the setup of the Composition API, the improved type inference means that you get much better IntelliSense within VSC, and have actually useful suggestions which pertain to the string type:

Look, arrow functions too! The blasphemy!

Note that you do not have to be using TypeScript in your Vue 3 projects to benefit from any of this. And if you do want to try out TypeScript, simply change the script tag to <script lang="ts"> so that your IDE knows to lint the code as TypeScript. And voila! It is that simple. Unlike Vue 2, there is no need to learn another Class Based API just to get marginally better TypeScript support. This native TypeScript support is the one change that I am most excited about in Vue 3.

Conclusion

The question remains: is learning or using the Composition API worth it? Even though the Options API will not be deprecated in Vue 3 and can be used together within the same codebase?

Whether to learn it or not is an easy question to answer: learn it. Learning is after all, inevitable, especially in the field of web development where a new tool comes out once every few months.

The question of whether to use it in a production site is a little more complex. Personally, I would, from the moment Vue 3 is production ready, only write new features using the Composition API. Refactoring the "old" Options API code on the other hand, is a decision only you can make. If the feature is continuously being worked on, I would say it makes sense to refactor to the Composition API to take advantage of all the benefits mentioned earlier.

But why take it from me? As of this article, Vite has just released its first beta version, and apps bootstrapped with it comes with Vue 3 and all its glory out of the box (plus, the hot module reloading is amazingly fast). Try it out for yourself and let me know what you think!

DEV Community: Aaron Choo

Relating SOLID principles to CSS and Tailwind

Applying OOP concepts to CSS

Aaron Choo ・ Oct 16 '20

Single Responsibility Principle in CSS

Open-Closed Principle in CSS

Liskov Substitution Principle in CSS

Interface Segregation Principle in CSS

Dependency Inversion Principle in CSS

Linking it all back to Tailwind

So why the controversy?

Further reading

Applying OOP concepts to CSS

Series introduction

Object-oriented programming in CSS

Objects in CSS

Encapsulation in CSS

Abstractions in CSS

Compositions in CSS

Conclusion

Display LaTeX Math in GitHub Markdown Previews

AaronCQL / katex-github-chrome-extension

A chrome extension to display LaTeX flavoured math in GitHub Markdown previews.

Motivation

Features

Conclusion

Is Vue 3 Composition API Worth It?

Problems with Options API

Poor Type Inference

Really Weird Bugs

Difficult to Collaborate

Benefits of Composition API

Conclusion