Webflow Frameworks: Lumos vs Client-First

When building a website in Webflow one of the most important things to consider is what framework to use. Utilizing a framework is important for making your website scalable and easily maintainable. It can also help speed up your build process. But what framework should you use? 

Two of the most popular frameworks within the Webflow community right now are Lumos and Client-First. While both of these frameworks can accomplish the goals above, they each take a different approach. I’ve traditionally used Client-First for all my website builds but after hearing a lot about Lumos over the past 6 months and having a little free time I decided to take a dive in to see what it was all about. While I don’t consider myself a master of Lumos as of yet, I’ve spent the last couple weeks learning everything I can about it. Below is an in depth comparison of each of these frameworks and some things to consider when adopting one over the other.

‍

Lumos and Client-First Background

First a quick background on each of these frameworks.

What Is Client-First?

Client-First is a Webflow specific framework that was created by the Webflow agency Finsweet. The framework, as the name implies, was created to keep the client at the forefront of the development. By creating a clearly understood naming convention, projects can be more easily managed by both clients and those who may be managing the Webflow project post-launch. In Finsweet’s own words, “By making our clients our top priority, we have created a style system that satisfies their needs and makes us better Webflow developers.” 

What Is Lumos?

Lumos is a Webflow framework that was developed by Webflow Guru / Wizard Timothy Ricks. Even if you’re new to the Webflow community you’ve probably stumbled upon Timothy’s Youtube channel. He’s known for creating efficient, scalable, and accessible solutions within Webflow and the Lumos framework is no different. According to the Lumos documentation, “[Lumos is] designed with efficiency, scaleability, and accessibility at its core.” 

‍

High Level Comparison of Lumos and Client-First

The biggest thing that stood out to me between the two frameworks was the learning curve. If you’re new to Webflow I would recommend learning Client-First before jumping into Lumos. Client-First is great for anyone who has a basic understanding of HTML and CSS. It’s also relatively easy to set up via Finsweet’s starter project. As I already mentioned, Client-First adopts the approach of putting clients (not developers) first. This makes the class system easy to understand for both web designers and clients that are looking to manage their own website.

Lumos overall has a much steeper learning curve than Client-First. This is especially true if you don’t have a lot of experience with CSS since a lot of the framework relies on custom embedded CSS blocks. Rather than being created with clients in mind, Lumos was created for developers, or more specifically Webflow Developers. As someone who does not consider themselves a coder but has a basic knowledge I had a challenging time getting up and running with Lumos.

Lumos also relies on utilizing custom attributes. Learning how to apply custom attributes can be a little bit foreign if you’re a designer with limited coding experience such as myself. I definitely struggled a little bit to understand when custom classes vs custom attributes should be applied within the framework. In addition to this I found limited resources outside of Timothy Rick’s Youtube channel and the Lumos documentation for understanding how to use the framework. With a much higher adoption, there are plenty of blogs and Youtube videos to help answer any questions on Client-First.

Ultimately, I found Client-First to be much easier to understand initially as well as set up within a Webflow project. This isn’t to say that Lumos doesn’t have plenty of benefits. When it comes to customizability, scalability and responsiveness I think Lumos has a lot on Client-First. If you’re able to put in the time and learn the framework I can see how it unlocks a lot of design flexibility and scalability that Client-First does not.  Let’s jump into how each framework compares more specifically.

‍

How Client-First and Lumos Differ

Class Naming

How classes are named and structured is one of the most basic aspects of any framework. It’s required to know how to use it effectively and efficiently. It’s also required to understand how new classes will inevitably need to be named when they are created. In fact, this is the first section in both the Lumos and Client-First documentation. While the following section may be a little overly meticulous I find it helpful in order to have a solid understanding of the structure as well as the different types of classes that each employs.

Utility Classes

Let’s first start with Utility classes. Utility classes generally do the same thing when it comes to Client-First and Lumos, but their syntax is slightly different. For example, a common utility class in Client-First is [font-size-large], this can be applied to any text or heading throughout a project. While there aren’t exact rules for how utility classes are named, Client-First generally aims to make these as descriptive as possible and no more than 3 words. Utility classes do not use underscores as a rule in Client-First. Another couple of examples are heading-style-h1, background-color-primary.

Lumos also has set utility classes though the naming is slightly different. Within Lumos, utility classes should always start with “u-”. This denotes that it is a utility class. Utility classes should always be stacked on a component class and should not be used by themselves or applied directly to an element. The idea behind this is that because the utility class is stacked on another class it’s a combo class and not its own standalone class (more on combo classes in a minute). This gives some flexibility for making adjustments to the class down the road if we need to rename it or make any adjustments without impacting where the other utility classes have been used.

Components or Custom Classes

Components are essentially custom classes that are created for specific sections or blocks within a design. Both Lumos and Client-First utilize components to modulate more advanced layouts. A hero section, a footer section, a card or even a whole page layout could all be considered components.

When it comes to naming Client-First, components follow a basic naming convention. Custom classes are named using underscores to differentiate between the component and the element. When creating a component the element being targeted may change but the component will stay consistent to show that the custom class is related to the component. Here’s an example:

With Lumos the naming and structure is similar but with some distinctions. Lumos does not utilize dashes for component classes, it sticks exclusively to underscores. Similar to Client-First, Lumos precedes the class name with the name of the component to show the relationship. To signify the start of a component, the custom class name should be ended with _wrap. Lumos also includes a variation within this naming structure to allow for component variations. Here’s an example taken from the Lumos documentation:

One other important differentiator is that all elements within the Lumos framework must have a component class applied. No utility classes can be directly applied to an element without first having a component class applied. As I mentioned before, the idea behind this is that it allows for style updates without impacting other elements unintentionally.

Global Classes

Global classes are as they sound–global. They can be used throughout a project. Client-First and Lumos both have global classes and can generally be applied globally, though I believe Lumos is a little more explicit with this.

Within Client-First, global classes can be both utility classes and can be created custom. Global classes can be stacked on another class as a utility class or they can be used as a standalone component. For example, margin-large is a global utility component that can be applied directly to an element without being stacked. Faq_item is also a global class that is a custom, standalone class that defines what the FAQ item looks like throughout a project. In my mind the lines start to get a little blurred here of how this is different from a component but I think this flexibility is one of the benefits of Client-First.

Lumos on the other hand is much more specific with what classes are global and how they are used. All global Lumos classes are specifically named by starting with g_. Remember, utility classes always start with u-, and must be applied directly to a component class, this keeps them as a combo class and prohibits them from being global.

Combo Classes

Combo classes are one of the areas where Lumos and Client-First are pretty much identical. Finsweet describes a combo class as, “a  variant to a base class. A combo class inherits styles from the base class and adds more styles on top of it.

Both Lumos and Client-First use is- prefix to signify a combo class. 

Class Stacking

While not specific to the naming syntax, there are different approaches each takes to class stacking. Class stacking is the practice of stacking multiple classes on top of a single element. Below you can see an example of several classes being stacked on a single div within Webflow.

For the most part, stacking too many classes in Webflow is not a good practice. This is primarily due to how Webflow handles class stacking. Remember, both these frameworks are specific to Webflow. Because of how the Webflow Designer is set up,  it’s generally more difficult to make adjustments to classes when they are stacked. When classes are stacked you’ll need to individually select, or even remove classes before you can adjust the styles for a specific class. This becomes even more amplified when you are dealing with multiple breakpoints. Long story short, you lose control over making adjustments to classes when they are stacked so for the most part you should avoid it.

While Client-First doesn’t give a specific number of classes that can be stacked it does give some general guidance to avoid “deep stacking”–the action of stacking many classes on top of an element. If you do find yourself deep stacking within Client-First the recommended action is to create a custom class that combines all the separate classes together rather than stacking them. This makes it easier to adjust that single element when needed.

Lumos–as you’ve probably gathered by now, approaches the class stacking problem differently. Because Lumos requires all elements to have a base class already, we should never need to stack more than two classes (component class and utility class). Because the utility class is always stacked on a component the utility class can be adjusted to that specific component without impacting the other places it is used.

Page Structure

Now that we’ve established the class structure let’s zoom out and look at the general page structure that each framework follows. Both frameworks follow a fairly traditional structure with minor naming differences.

Page Wrapper

Both frameworks employ a page wrapper div. This div wrap all other elements on the page. Client-First names this page-wrapper while Lumos names this page_wrap. For both Client-First and Lumos the main purpose of this wrapper is to house your custom style embeds and creates a class that can easily be copied to another page. Client-First recommends minimal styling on this while Lumos only applies an overflow: clip style to prevent horizontal overflow.

Main Wrapper

The main wrapper section is the next level below the page wrapper. Both frameworks utilize the main wrapper to house all sections that are unique to the page. Neither the navbar nor the footer should be contained within this wrapper. Lumos labels this section as page_main, while Client-First labels this as main-wrapper. It should also be noted that both frameworks utilize the <main> tag rather than a generic <div> tag here. This is helpful for search engines and accessibility.

Section

Ultimately sections in both Lumos and Client-First share the same purpose. They’re a structured way to divide up different sections of the page, not rocket science, right? But there are some different assumptions and class structures between each as we’ve already covered a little bit.

Looking at Client-First, a section is an unstyled <div> that is named using the section_[section-identifier] structure. Using this naming structure creates a user friendly and easily readable structure for clients in the Webflow Designer.

As a general rule Client-First discourages applying styling directly to sections. Instead it recommends using combo or utility classes to make adjustments. This keeps your sections a little more flexible throughout your design.

Lumos also uses a <div> class though by default each section has the default styling of position: relative. This allows for quickly applying absolute positioning to anything within the section. As you may have guessed, the naming pattern for a section is section_name_wrap, since each section is the start of a component. The big difference we start to see between Client-First and Lumos is this is the first mention of using data-attributes in the Lumos documentation. Unlike Client-First, Lumos utilizes data-attributes to change specific styling on sections and maintain flexibility with components. With data attributes such as data-theme-attribute="invert" you can adjust from a dark to a light theme across the entire section. This is where Lumos really starts to differentiate itself from Client-First and where its power starts to come in.

Container

Below each section sits a container. Again, this is all pretty standard for most frameworks however, this is a differentiator between Client-First and Lumos. Rather than applying horizontal padding directly to a container, Client-first utilizes a standalone <div> wrapped around each container to control the horizontal padding throughout the site  (class name padding-global). Separating the padding-global class from the container gives Client-First a little more flexibility when used with or without other page structures. In other words, this will give a design using Client-First a little more freedom to change the padding between sections without being locked in throughout the site.

Lumos instead relies on combo classes like u-container to adjust horizontal padding. This has the same effect in that because it’s a combo class changing it on a single instance will only impact the base class and not the entire project. Lumos however has a different way of managing vertical padding. Instead of using utility or combo classes Lumos recommends utilizing data attributes to adjust top or bottom padding. Why these vertical and horizontal padding are managed differently took me a minute to understand. The primary benefit of controlling the vertical padding with data attributes is that they can be applied as component properties. This allows for adjustments to be made on a component by component basis and since horizontal padding is less likely to change throughout a project it makes sense to have data attributes on the vertical padding to maintain flexibility.

‍

Where Each Framework Shines

If you stuck through reading that whole section then congratulations! While a lot of the structural differences are a bit nuanced, I found that getting a good grasp on these topics was helpful to understand the benefits and drawbacks of each framework. Let’s talk about where each framework shines.

Where Client-First Shines

As I’ve already alluded to a few times, Client-First is generally going to be easier for beginners. There’s a few reasons for this, project setup, the framework's documentation, and the Webflow community’s adoption of the framework.

Project Setup

I might be a bit biased here considering I am still learning Lumos but I found a lot of challenges with getting a project set up in Webflow quickly. Client-First has made this a pretty straightforward and linear process. For the most part, all that is needed is to clone the Webflow starter project and update the style guide before you begin building. 

Lumos is more convoluted in my opinion. While there is a Webflow starter project, getting your styles setup after cloning takes some discovery. Instead of just adjusting the classes contained within your style guide, the Lumos utilizes data attributes, variables and custom CSS to control the framework. I found myself hesitating making changes to individual classes for fear I should actually be making those adjustments somewhere else within Webflow.  Again, I’m sure a lot of this is just part of a learning curve and with time, practice and a better understanding of the framework I’ll be able to get up and running more quickly.

Documentation

In addition to project setup, I also didn’t feel that there was a comprehensive guide to getting started with Lumos. This gets into my point on documentation. Yes there’s the Lumos documentation and yes, Timothy Ricks has a number of videos going over the Lumos framework. Despite reading all of the documentation and watching all the Lumos playlist videos I still felt a little lost on where to begin after reading everything. As much as I hate to admit, I almost felt like I needed a dumbed down resource for getting started before moving on to some of the more advanced topics within the framework. I think this speaks to Lumos’ intended users of advanced developers rather than beginners.

Adoption

Client-First clearly has more of an adoption throughout the Webflow community. This is evident by inputting a simple search for Lumos within YouTube or Google. For the most part the only articles or videos I was able to find on Lumos were from Timothy Ricks himself. Client-First on the other hand has plenty of third-party resources to help get started. It also has whole organizations and Agencies backing it. Finsweet and Relume being some of the largest ones that utilize Client-First.

I don’t want to knock this point too much because a big factor here is that the Lumos framework is much newer than Client-First, so naturally there’s going to be fewer resources around it. Overall I think Timothy Ricks has identified points where a lot of other frameworks and Webflow in general are lacking and created a great solution. Given Timothy Ricks’ popularity within the Webflow community I’m sure Lumos will continue to grow and naturally gain more adoption.

Where Lumos Shines

Alright, so where does Lumos shine over Client-First? Lumos, while objectively for more advanced users, does come with a lot of benefits over Client-First. The three points I really see Lumos shining are customizability, responsiveness, and scalability.

Customizability

Lumos easily stands above Client-First when it comes to customizability. This is one of the main reasons I was drawn towards trying Lumos. While utilizing custom CSS and variables make the framework a little harder to master they do allow for some pretty neat layouts that are also responsive. Here’s an example from the OMMO Studio website that utilizes Lumos as it's framework.

While this could technically be built using Client-First, the way in which Lumos defines custom variables within its CSS embeds gives easy access to creating these types of layouts while still remaining responsive. This video by Timothy Ricks really made me realize the power and ease in which unique layouts can be applied once you understand how to leverage the framework. This becomes even more powerful when you realize how easy it is to make different elements responsive.

Responsiveness and Accessibility

Lumos also has a leg up on Client-First when it comes to responsive design. Not that Client-First isn’t responsive, it just isn’t as responsive. Let me explain. Out of the box, Lumos adopts fluid sizing as opposed to adaptive sizing. Essentially fluid sizing allows font sizes to scale with the browser windows size. This is different from adaptive sizing which only changes the font size at a defined breakpoint. Utilizing a fluid sizing maintains the original design on different screen sizes because everything is scaling relative to the screen size, rather than at set steps or breakpoints. 

This also helps create more accessible designs for users who increase their browsers font size. Should a user increase the size of their fong enough, the browser will actually switch to a separate breakpoint. This in some cases will actually make it smaller. This is generally a bad user experience and one Lumos solves through its implementation of fluid sizing.

I should note that Client-First does have options for adding fluid sizing to its projects but this is not a feature out of the box.

Scalability and Load Time

The last point to make for Lumos is on scalability and load time. When it comes to scalability one of the things that Lumos aims to do is correct an inherent problem with Webflow–which is adding unnecessary lines of code. While Webflow is great for quickly adjusting styles in the designer this can create an unnecessary number of styles that repeat and make our code longer than necessary. Longer code in general means slower loading times so it’s beneficial to keep our code from repeating. Lumos solves this problem by utilizing classes that already exist within its CSS embeds. By predefining all the variations of grid and flex box as classes that can be applied anywhere throughout the project. This keeps Webflow from creating unnecessary styles and keeps our code cleaner and shorter. 

While Client-First isn’t necessarily non-scalable, it does come with the problem described above. This means in the long-term as a website grows the code base is likely to continue growing as well.  Because Lumos focuses on reusable code and reusable components the code base is less likely to grow as quickly. This makes Lumos much more ideal for larger projects and gives it an edge on Client-First when it comes to performance.

‍

Conclusion

Client-First is a great option for beginners that are new to Webflow or that have limited experience with CSS and custom code. The documentation as well as the community backing make it easy to learn and quickly get up to speed.

Lumos on the other hand, is a great option for someone who has a more advanced understanding of Webflow and custom CSS. While the learning curve may be a little steeper, there’s a lot of gains to be made for those that take the time. This includes more customization and websites that look less templated. Lumos also brings built in fluid sizing allowing for better responsiveness and websites that stay true to their original design. Lastly, Lumos’s focus on reusable code and reusable components make it more ideal for performance and scalability.

While I’m not planning on switching all of my projects over to using Lumos yet, I do see myself trying it on the right project in the future. As I outlined above, there’s a lot of benefits that come with using it if you can get over the learning curve and create an efficient workflow within the framework. After giving Lumos a try and building out a few sections I can see how it becomes faster and easier to build and manage projects. While the overall community adoption remains low I think Client-First is still the best option.

Need some help building a website? Let's chat. Our team can built a website that's easy to manage using the Client-First framework. If you're looking to have a website built that's user friendly and easy to get up and running let us know.

Get in Touch