Scott

Scott

tl;dr; If you already know what Quasar is all about and you understand what the App CLI is, please drop down to the “What’s New?!” section below.

Right now, some of you might be going, “Hey…wait a second! Quasar was just released as 1.1.0!”. If you are thinking this, then you are absolutely right!

Let’s explain. Quasar has two main realms of functionality as a framework:

The Quasar CLI — a vast and powerful dev and a build environment for cross-device application development and distribution.

The Quasar UI — This is what we call the huge high-quality component library within Quasar.

The last 1.1.0 release was for the Quasar UI (release notes).

And, there’s more! The CLI itself also has two parts.

1. The “Global CLI” (@quasar/cli — which is optional), for doing things like creating projects and serving up app distributibles locally with an ad-hoc webserver.

2. The “App CLI” (@quasar/app), for doing most of the things you need to do within a Quasar app project, like offering the dev server environment (for HMR and a lot more!), adding boot or component file templates to your project or describing APIs for components and of course, the most important part, building out your project to the multiple environments Quasar supports (i.e. Web, PWA, Web+SSR, PWA+SSR, Cordova, Electron, etc.).

As you can see, Quasar is a very powerful framework for frontend development, especially for supporting cross-device code reuse.

With this release, we are updating the 2nd part of the CLI. The App CLI.

What’s New?!

In this release, we have two new great features we are excited to offer the Quasar community.

1. Quasar now fully supports [Sass CSS](https://sass-lang.com/) by processing both .scss and .sass file types!

2. No more having to remember to enter your used components or directives inside Quasar’s configuration file quasar.conf.js. Quasar now does it automatically for you, if you configure it to do so!

Let’s dig into more of the details of each new feature.

Sassy Quasar

That’s right! Quasar now also supports Sass and .sass and .scss file processing.

It doesn’t matter what survey you may run into, all of them show the propensity of developers to lean toward using Sass as their go-to CSS processing system. Quasar is following that trend.

The cool thing is though, if you know Quasar, you also know about Quasar’s style variables. And these variables are also available within your Sass CSS too!

Although Quasar supported Sass even before this change, now Quasar’s complete CSS system can be Sass only, if you so wish to use Quasar that way.

In other words, Quasar (through @quasar/app) now supports src/css/quasar.variables{.sass|.scss} file, which you can use to extend or change the default Quasar variables. When that file exists in a project folder, it will automatically make your changes available in your <style lang="scss"> or <style lang="sass"> too respectively. But, even if the file is missing, you’ll still be able to access the default variables.

There is only one common-sense caveat: adding your custom variables to quasar.variables.styl will make them available only in every .vue(lang=“stylus”) or .styl file, but it will not make them available in any .vue(lang=“scss”/lang=“sass”) or .scss/.sass files. You’ll need a quasar.variables.{scss|sass}file for this. The same rule goes in the other direction too.

After 1.1.0, it will be possible to have Quasar’s style source in the form of Sass and can also be used seamlessly with SCSS too. And Quasar’s App CLI will support Stylus and Sass/SCSS out of the box. That means, no additional packages will need to be installed for Sass/SCSS, as was the case in previous Quasar versions.

Also, when creating a new project in Quasar, the CLI will now ask you what CSS processing system you’d like to have for that project.

One last thing. Unbelievable as it may be, the addition of Sass was implemented without any breaking changes.

Automated Config

It’s a long-standing issue with devs about having to remember to add the components they use from Quasar within the quasar.conf.js file. It’s also often a simple fix to a common support issue.

There is the well-known all feature, which allows a dev to disregard adding used components for development purposes. The all feature basically included all components, directives, and plugins. However, and at the latest when the app is ready to be built, the dev would have to figure out what components and directives she had actually used and update the quasar.conf.js file accordingly. All of this was necessary to allow Quasar to tree-shake the code and build the smallest package possible.

Now, with App CLI 1.1.0, Quasar will automatically scan your code for components and directives used within your Quasar app and add the necessary entries into the quasar.conf.js file. Unfortunately, for technical reasons, plug-ins couldn’t be added, but there is a much, much smaller list of plug-ins, compared to components. This addition is a valuable and time and effort saving enhancement for you, as a developer.

We do believe this new feature will add to the already great developers experience Quasar offers and shows, one of the main intentions of Quasar…

A great developer experience.

The Full List of Updates in the App CLI 1.1.0 Release

New Features

• Sass/SCSS support #5049 (/src/css/quasar.variables.scss support, /src/css/quasar.variables.sass support, Quasar variables available even if app-space override file is missing, Supply node-sass and sass-loader out of the box)
• If no css/ variables file exists, hook directly into Quasar’s built .css file #5049
• Auto import Quasar components and directives; quasar.conf.js > framework > all: ‘auto’
• Boot files new params: urlPath and redirect(); enhance docs
• Small tweak to “setting port to nearest available” banner

Fixes

• “describe” command on quasar conf options
• Disable watchContentBase to avoid triggering unwanted errors #5026
• Allow Cordova to set target “electron” #4941 (will work when Cordova-electron v1.2 is released)

We hope you are as excited as we are about these new features to the App CLI.

Let us know what your impressions are about this release and the new features. We always welcome constructive feedback.

If you want to learn more about Quasar:

The Quasar website: https://quasar.dev
GitHub: https://github.com/quasarframework/quasar
Getting Started: https://quasar.dev/start
Discord Chat Server: https://chat.quasar.dev
Forum: https://forum.quasar.dev
Twitter: https://twitter.quasar.dev
Facebook: https://facebook.quasar.dev
Donate: https://donate.quasar.dev

Scott

Or, if you want a more advanced “ready-built” system, have a look at either Yoga GraphQL or Prisma Server.

Scott

Am I correct in saying, your containerization system code is closed-source?

Scott

I ended up as a team member to learn more and to help out, because I know in the future, I’ll be getting any effort I put in many-fold back.

If you are a company, a part of a company or are a dev and you are also taking advantage of the time and effort savings Quasar affords you, please think about compensating the Quasar project for that savings. It will help guarantee a sustained project for the longer run.

https://quasar.dev/

Scott

In my first article on Vue 3.0, my concern was more with the classical OOP developers, who were insisting the new function-based API isn’t the right direction. They were calling, even screaming, for their beloved classes, and unfortunately for them, classes, as an API alternative, are now a mute point.

Well, since that post, a new wave of pessimists came out of the woodwork and were much more emotional about the API change (a change at the time. More on that below). It seems the wording of the RFC, that the object-based API would be deprecated, most likely in Vue 4.0, was causing a lot of fear. That fear along with some other misinformation on Reddit and Hacker News sent the Vue community into a wildfire. The RFC comments thread exploded with some clear concerns, but also some abusive and unnecessary verbiage. And indeed, it was Vue’s Darkest Day.

I’ve also been quite active in the different threads on Github, trying to support the Vue team. I’m not sure if I’m helping or hurting. I believe my heart is in the right place. So, I guess it was ok.

You see, I’m not an advanced developer. I don’t even consider myself a good frontend developer. I have a lot of experience with software. Call me a power-user, who dabbles in code. And, I believe Vue’s “approachability” for such non-advanced users like me has been its strength…… and at the same time… its Achilles Heel.

So How Can That Be?

The issue as I see it is this. The object-based API and “how it looks”, its sleekness, its symmetry, its design elegance and its constraining logic encapsulation is as close to perfection that any API or abstraction can get. It is, in terms of “Programming Art”, a masterpiece, but mainly for the uninitiated, lesser experienced developer.

The constraining part of the API helps those that wouldn’t know better to place code in smartly named “spaces”, i.e. the different code blocks <script> , <template> and <style> along with the options of the component object, computed, data, methods, etc. This allows for an easy understanding on how to build components. It also means, anyone even remotely familiar with Vue can jump into already built components and quickly start to understand the gist of what the component is accomplishing. Maybe it’s needless to say, but this also helps to fix bugs or expand on that component.

There is, however, a few smudges of paint to be seen in this masterpiece, and in almost all cases, only other masters of programming can see them. Even the grand artist himself, Evan You, also knew his masterpiece wasn’t flawless. This is why we now have Vue 3.0.

I’ll be perfectly honest. I didn’t see those smudges either at first. I didn’t understand how something so beautiful could be wrong or rather “less beautiful” — less useful — for anyone else. But, after mixing it up in the different RFC threads, after asking the stupid question here or there and getting patient answers from the Vue team, after reading replies from other “masters” saying “Thank you” and also some explaining why they were thankful or where they see the usefulness, and after my coincidental work on a bug in a quite complex component (a WYSIWYG editor), those smudges on the great programming work of art called “Vue”, finally came to light for me.

It’s All About (better) Code Encapsulation

Yes, Vue is still a beautiful work of art. The constraints of the object API gives everyone a standard to go by. And, it works for the majority of components. However, it just doesn’t work for all components all of the time. And, although I too still think the new function-based API is missing some of the object APIs elegance, I also understand it is only the foundation, the basis, to what is an overall ability to allow Vue developers to make Vue SFCs, mainly more complex ones, more elegant.

As mentioned above, there was at first the notion in the RFC that the object API would be deprecated at some point. Through the rampage of upset Vue developers, pleading and deploring, it was finally decided by the Vue team to make the new function-based API not a change, but rather a set of extra tools to make plain old JavaScript “Vue-Reactive”. That’s right, the new function-based API is not going to be a replacement for the object API any more, but rather it is now an addition to it. The new API is for more advanced Vue coding. It will help those, the masters of Vue, get better code encapsulation into their own works of programming art. It will help more complex component code become more “feature oriented”, instead of “options oriented”, and that will ultimately help with the reasoning about that complex code.

I could go on with code examples, like my lame attempt to take the RFC example code and show the code encapsulation abilities the new API offers, but that hasn’t seemed to help. It’s like showing someone a piece of art, a masterpiece, and saying to them, “look at those intentional smears of paint and what that does to the whole emphasis of the painting”. If they aren’t true masters of painting or art, it bounces off of them. They see smears of paint, not the emphasis and improvements those smears make. At best, you might get a shrug of the shoulders, at worst, you get a lash out at the ingenuity and refinement, calling it “crap”. We’ve seen it so many times before, and we are seeing it again.

Though, great art always prevails.

Yes, this new art is also semi-stolen. It’s core idea, admittedly, comes from React’s new hook system. But, IT’S NOT REACT’S HOOK SYSTEM. It’s Vue’s new hook system. It’s better in many ways, well, because it’s Vue. 😄

It Will All be Alright

I made a prediction over a year before it happened (and yes, we can argue whether or not it did happen), that Vue would become the most popular JS reactive frontend framework. And, I will now also predict that with time, the new function-based API will become just another beloved part of Vue. Some will still see it as a mystery, just some wild strokes of a brush. And, as time goes on, other developers will see it makes Vue an even more revered work of programming Art, because it allows their own works of art, built on Vue, to be smarter, more elegant and easier to reason about.

If you are still skeptical about the new function-based API, I don’t blame you. I’ve not really attempted to change your mind. I just gave you my thoughts and opinions. I can only suggest the following. Be open to the masterful work of Evan You. He’s had it right for so long. He’s not a fool to throw that away for something “less-worthy”. Trust him as a master of his art and his mastery of the “Art of the Steal”.

I promise, you won’t regret it! 👍

Scott