Scenario:
Let’s assume you are building a typical (business/product/blog) webpage with Quasar. You want it to be flexible and responsive and VERY mobile friendly and VERY big screen friendly. After a while, you realize it is very hard to achieve with Quasar. Almost impossible out of the box. In normal scenario you would use one of the thousands Bootstrap site templates, BUT, in this case you are just stubborn to use Quasar.

One piece of the puzzle is fluid typography:
https://www.madebymike.com.au/writing/fluid-type-calc-examples/
https://css-tricks.com/books/volume-i/scale-typography-screen-size/

In Quasar you could use something like this in your app.styl file:

fluid-font-size($minimumSize = 12, $maximumSize = 36, $minimumViewportWidth = 300, $maximumViewportWidth = 1600)
  font-size: 'calc(%spx + (%s - %s) * ((100vw - %spx) / (%s - %s))) !important' % ($minimumSize $maximumSize $minimumSize $minimumViewportWidth $maximumViewportWidth $minimumViewportWidth)

for num in (8..28)
  .fontsize-{num}
    fluid-font-size num (num*2+2) 300 1800

The code above will generate CSS classes fontsize-8 through fontsize-28. After that it is quite simple to use it like this:

<p class="fontsize-10"> this is content text</p>
<p class="fontsize-12"> this is caption</p>
<p class="fontsize-14"> this is header</p>
<p class="fontsize-16"> this is bigger header</p>

In similar style other CSS typography properties could be scripted (line-height etc.). I know, it is not ideal, I would strongly prefer to have something like responsive/fluid typography CSS system in Quasar itself, but for now - it just works.

App Extensions - one of the most ingenious and powerful of all Quasar concepts. I want to ask what is your vision about their role in the future Quasar architecture? They’re great and they’re powerful, yet they’re quite cryptic and there are not too many of them. Do you want to let devs create them more? As for now, IMHO there is a confidence gap between their docs, usage and “marketing”, so average developer could have a problems to just trust AE subsystem and learn it and create something with it. There’s no confidence, that it is a recemmended “Quasar way” of thinking.
Do you see them as a playground for wizards and when their toys mature, they should be incorporated into the Quasar core (icongenie) or rather as a system for Quasar openness and integration and also - very important - as a market (in business terms) for thousands of custom AE? If it is latter, maybe it would be a sign of confidence to just convert all existing quasar components into app extensions?

@s-molinari said in Did you get support from the Quasar Dev Team or the Community?:

… And, we only can help during or own free time, so there isn’t any SLA to answer within 24h or the like. To be honest, the attitude you seem to have about OSS and how it should be “supported” is out-of-place.

just a thought - I always believed that it is we, who has a duty to support the open source authors, help them, be kind to them and praise them - not the other way around! It is they, who give something for free, something most valuable in their life - their time. It is they, who create something instead just consume as most others. Just $0.02 here.

@s-molinari sure, good idea!

I want to ask about drag’n’drop support in Quasar components. It would be nice to have q-tree with drag and drop, or q-table with repositioned columns and rows, or q-list which could exchange items with other components.

@rstoenescu @s-molinari

Hmm, as an unfortunate author of this charming “solution”, please take my advice and do not incorporate this trick/hack at the framework level into Quasar. Yes, it looks nice in developer eyes, but it is valid only in specific situations and taking it out of the context of the whole typography would be IMHO more hurting to the image of Quasar as a CSS web pages platform.

Why?

1. Typography is about visuals, rhythm, beauty, composition. This hack is an algorithmic take on font sizes and it is linear in nature. In reality, the scaling of visuals should be non-linear and adjusted to the page purpose, specific font etc. If we will encourage designers considering Quasar as their next tool, to use linear design (at the framework level), they will laugh us off. It should be a developer decision if he wants to use linears in his specific web page.

2. Yes, it is only part of “typography” as a whole and it is rather crippled part. The more advanced take to font scaling (only) at the LIBRARY level is here:
   https://github.com/twbs/rfs
   If at the APP level, one would want to use this LIBRARY, then one would only need to:

npm install rfs --install

and in their app.styl code:

@import "../../node_modules/rfs/stylus";

Why is it encouraged to use this library and not incorporating anything into the framework? It is not recommended because you lose the ability to easily and quickly manage and update RFS as a dependency. Why is it important? Because for example “my” solution doesn’t work fully on safari browser. There are specific quirks which this library handles and my hack does not. There is a documentation of how and where use or not to use scaled fonts (not on HTML tag).

2. Why typography is so important on web pages (and even on web apps)? What is this typography anyway? Well, there are so many tutorials, books and knowledge. Those are interesting at the beginning:
   https://css-tricks.com/typography-for-developers/
   This one touches of the tip of the iceberg - rhythm:
   https://www.webfx.com/blog/web-design/css-typography-02/
   There is a beautiful parable - I’ll cite “The concept of vertical rhythm is simple: Line heights, margins, and padding should all be equal or within even proportion.”. Even if a daveloper knows how to use CSS typography properties (so many…) does she understands what rules needs to be followed and which ones could be broken?
   This is nice one too:
   https://practicaltypography.com/
   … and many more.

3. What can I do anyway? Well I’m strongly encouraging to somehow incorporate Bootstrap design concepts into Quasar, but not necessarily at the framework level, but rather as friendly agreement to “not reinvent” Quasar own solutions, in a way, which would prevent using of knowledge and solutions accumulated in Boostrap as a concept. As I said in previous posts, the key is to convince thousands of developers from Bootstrap to convert to Quasar.

4. Can I use Boostrap already in Vue and link it with Quasar? There are solutions at the Vue level for example:
   https://bootstrap-vue.js.org/
   https://medium.com/@BjornKrols/integrating-and-customising-bootstrap-4-in-vue-js-cbc29ba7688e
   But they won’t be rather compatible with Quasar, because Quasar, at the framework level, intentionally or not, is using similar CSS classes to Boostrap, and it would just make a mess if one would want to use those two CSS system at the LIBRARY level.

5. Why am I differentiate “framework”, “library” and “app” level? At the framework level there is an “inversion of control”, at the “library” level it is the “app” who decides where “control” is, and the “app” is where the “interaction” is. Without “interaction” there is only “web page”.

6. OK, so what are the options to play along with Boostrap4 in Quasar? Quasar is based on “material design” and Boostrap is not, so why we even are talking about that? Because the most important are those designers/developers to convert and thousands of web page templates and snippets to use. We do not need to USE the B4 as a base for Quasar, we only need to have “possible way” to use hard learned B4 skills in Quasar environment. It is sufficient for Quasar not to prevent this (as it is doing now). Have it be done in Vue? Yes, there is a project MDBootstrap - “Material Design with Boostrap in Vue”:
   https://mdbootstrap.com/docs/vue/
   The name is perfect, becuase this project, as it is claiming, converted 800 000 developers to using Bostrap in Vue! This is the scale of traction we are talking about.

7. How is it possible for this project to be this successful? It allowed to use B4 skills and promised to multiply the productivity by using Vue. This project is focused on presentation, which is Quasar weakness. If Quasar would incorporate some of the design elements/concepts/ideas from MDB, than because it is a superior FRAMEWORK it would just offer a win/win.

8. In essence - we really do not need to follow the path of manually dealing with every css typography property or scaling or visual specifics. It is Vue and it is 2019. The MDB project has something like “Sections”. Please take a look:
   https://mdbootstrap.com/docs/vue/sections/demo/
   This is what we (as “we” developers") need at the end of the day: the highly configurable web page compound elements, with superior layout, excellent typography, visually atractive and highly configurable sections of blog, contact, e-commerce, features, intros, magazines, projects, social, teams, testimonial, and of course, jumbotron. With those “bricks” the Quasar would not only be an excellent app platform but also web page platform. In MDB those sections are highly compatible with B4 semantics and this is why this project is so succesful at developer acquisition. In MDB they are manually converting those web templates and snippets (but it is possible and it is simple), in Quasar we just could write something to automatically convert existing B4/MDB templates/snippets (ideally of course).

9. What am I proposing? There is a concept of App Extensions in Quasar. It is just ingenious. What we need in V1 is to not overwrite CSS classes from B4 (which would allow to use some of the B4 concepts) and make an App Extension with default sections for web page developers (maybe even the same as in MDB - they’re great). There is a twist - in specific demos, there should be examples of incorporating Quasar app components in those sections! It would be just a killer feature for thousands of developers. They couldn’t resist the temptation to finally use something app centric on those boring web pages, they are making every day, just to bring some food on the table.

@DDP said in Drag And Drop:

Upvote for built-in draggable features, especially for lists and tables

and q-tree and q-chips…

As a learning project I created a repo with BEX technology, as of now, it can interact with specific page, inserts some DOM and propagate events from host page to BEX, persists data between page changes, executes some privileged operations and some more stuff.

This is a learning/testing project. I would GLADLY donate this repository to Quasar devs as an example of BEX awesome technology. It is a starter of course, but it looks interesting. We as a developers alway like examples and code ready for copy/paste, so such projects will be useful.

This is the repo:

https://github.com/qyloxe/qbexlinks

In readme.md there are some questions, I think the main problem is why this doesn’t work in Firefox and how can w debug/test this on Mozilla platform. Unfortunately Chrome is better in this, there are more meaningful error messages for example. It worked in Firefox at the beginning but after changes to manifest.json and maybe in some other places it stopped working.

Firefox is important IMHO because it offers a sidebar technology for BEX. In Chrome there is no sidebar unfortunately.

All questions and comments are welcome. PR or anything on Github even more. Happy coding!

@rstoenescu said in fluid typography - SOLVED:

… Quasar is looking into the future and sets its own high and modern standards. And yes, in order to make progress in web development you need to break the current establishment. Otherwise we’d all be continuing to write websites in cgi-bin / perl today too, because maaany years ago that’s what developers were accustomed to. And what most developers are accustomed to at one point in time doesn’t actually mean it’s the best solution or the “definite” solution, and Quasar will never bend into choosing what we believe is not the optimal path to high quality work, not even over money.

We now have limited resources, but if you take a look at what has been achieved here then imagine what we can do with proper resources. What I want to achieve with Quasar is to raise the bar for web development as a whole. Make it go forward, evolve. Change minds. Point out when there’s a better alternative.

Please, please put above words somewhere on the main page. This is so strong, power and emotional narrative. Pure energy which leads and shows the new way to people. I’m in awe of those words, you used so many emotional and strong terms in such a short content. Almost like a poetry, but for developers Please, use those words not only on this forum but for rest of the world to hear. They deserve it.

There’s many libs for web workers. One which is quite simple and working in Quasar is described below.

Lets create a new test Quasa project, with javascript and simple options:

quasar create qworkers

We will be using this library and integrate it with our test project:
https://github.com/developit/workerize-loader

In file package.json we will add this:

  "devDependencies": {
    ...
    "workerize-loader": "^1.3.0"
  },

In file quasar.conf.js we will add this:

    build: {
      ...
      // https://quasar.dev/quasar-cli/handling-webpack
      chainWebpack (chain) {
        chain.output.set('globalObject', 'this')
      },
      extendWebpack (cfg) {
        ...
        cfg.module.rules.push({
          test: /\.worker\.js$/,
          exclude: /node_modules/,
          loader: 'workerize-loader',
          options: { inline: true }
        })
      }
    },

Our index.vue should look like this:

<template>
  <q-page class="flex flex-center">
    <img
      alt="Quasar logo"
      src="~assets/quasar-logo-full.svg"
    >
    <q-btn @click="start1">start worker</q-btn>
    <q-btn @click="start2">start DOM function</q-btn>
  </q-page>
</template>

<script>
import worker from './test.worker'

export default {
  name: 'PageIndex',
  methods: {
    async start1 () {
      const instance = worker()
      const count = await instance.expensive(5000)
      console.log(`Ran1 ${count} loops`)
    },
    expensive (time) {
      const start = Date.now()
      let count = 0
      while (Date.now() - start < time) {
        count++
      }
      return count
    },
    start2 () {
      const count = this.expensive(5000)
      console.log(`Ran2 ${count} loops`)
    }
  }
}
</script>

We will add a new file src/pages/test.worker.js with content:

export function expensive (time) {
  const start = Date.now()
  let count = 0
  while (Date.now() - start < time) {
    count++
  }
  return count
}

export default expensive

Next we execute commands:

npm install
quasar dev

And the browser should popup:

Pressing “start worker” button will execute CPU expensive function in web worker. Observe, that the page is fully responsive. The result will be shown in the console.
Pressing “start dom function” will execute CPU expensive function in main DOM browser thread. The page will NOT be responsive! The result will be shown in the console.

Discussion:

1. Why this library? Well, it’s simple and it works. The integration by webpack in inline mode allows nice HMR and quasar bundling.
2. Why there are strange CSP comments in firefox? Yes, the web workers has some security quirks and there are differences in handling them in Chrome and Firefox. There is a section about Content Security Policy in MDN about that:
   https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers
3. Why do you need web workers in Quasar? In Quasar there are many potential optimizations which could benefit from using web workers. They are not only typical sorting, filtering, querying but even less obvious parts of Quasar component where the CPU work could be transferred to web worker. Yes, it could make Quasar the fastest framework in the market.
4. Oh, but I’m just a user and I want web workers in Quasar, too! Well, I would like also! I think it is time to include web workers support in base library - similar as it was done with support for other browser API as local storage, full screen, resize. The one, working Quasar interface to web workers would be a game changer.
5. What if somebody will create an App Extension with web workers support instead? This IMHO would be less optimal, because the Quasar API for web workers should be the same for internal Quasar components and for user apps. The example above is rather simple in terms of communication, but in real life, probably one would want a more advanced communnication between components. It comes to mind the excellent BEX mode and the concept of bridge. I think, if Quasar would implement support for web workers, the existing bridge concept as a means of communication would be just right.

@perik for example like this:

Assuming, you host your own fonts in /fonts subdirectory. You can download them from google fonts for example or any other font source/converter. You will need them in woff and woff2 format.

in app.styl insert this:

@import 'myfonts.styl'
@import 'myrules.styl'

Then in myfonts.styl you can insert this font variation declarations. Code is generated from this tool:

https://google-webfonts-helper.herokuapp.com/fonts/ubuntu?subsets=latin-ext,latin

/* ubuntu-300 - latin_latin-ext */
@font-face {
  font-family: 'Ubuntu';
  font-style: normal;
  font-weight: 300;
  src: local('Ubuntu Light'), local('Ubuntu-Light'),
       url('/fonts/ubuntu-v13-latin_latin-ext-300.woff2') format('woff2'), /* Chrome 26+, Opera 23+, Firefox 39+ */
       url('/fonts/ubuntu-v13-latin_latin-ext-300.woff') format('woff'); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
}

/* ubuntu-300italic - latin_latin-ext */
@font-face {
  font-family: 'Ubuntu';
  font-style: italic;
  font-weight: 300;
  src: local('Ubuntu Light Italic'), local('Ubuntu-LightItalic'),
       url('/fonts/ubuntu-v13-latin_latin-ext-300italic.woff2') format('woff2'), /* Chrome 26+, Opera 23+, Firefox 39+ */
       url('/fonts/ubuntu-v13-latin_latin-ext-300italic.woff') format('woff'); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
}

/* ubuntu-regular - latin_latin-ext */
@font-face {
  font-family: 'Ubuntu';
  font-style: normal;
  font-weight: 400;
  src: local('Ubuntu Regular'), local('Ubuntu-Regular'),
       url('/fonts/ubuntu-v13-latin_latin-ext-regular.woff2') format('woff2'), /* Chrome 26+, Opera 23+, Firefox 39+ */
       url('/fonts/ubuntu-v13-latin_latin-ext-regular.woff') format('woff'); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
}

/* ubuntu-italic - latin_latin-ext */
@font-face {
  font-family: 'Ubuntu';
  font-style: italic;
  font-weight: 400;
  src: local('Ubuntu Italic'), local('Ubuntu-Italic'),
       url('/fonts/ubuntu-v13-latin_latin-ext-italic.woff2') format('woff2'), /* Chrome 26+, Opera 23+, Firefox 39+ */
       url('/fonts/ubuntu-v13-latin_latin-ext-italic.woff') format('woff'); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
}

/* ubuntu-500 - latin_latin-ext */
@font-face {
  font-family: 'Ubuntu';
  font-style: normal;
  font-weight: 500;
  src: local('Ubuntu Medium'), local('Ubuntu-Medium'),
       url('/fonts/ubuntu-v13-latin_latin-ext-500.woff2') format('woff2'), /* Chrome 26+, Opera 23+, Firefox 39+ */
       url('/fonts/ubuntu-v13-latin_latin-ext-500.woff') format('woff'); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
}

/* ubuntu-500italic - latin_latin-ext */
@font-face {
  font-family: 'Ubuntu';
  font-style: italic;
  font-weight: 500;
  src: local('Ubuntu Medium Italic'), local('Ubuntu-MediumItalic'),
       url('/fonts/ubuntu-v13-latin_latin-ext-500italic.woff2') format('woff2'), /* Chrome 26+, Opera 23+, Firefox 39+ */
       url('/fonts/ubuntu-v13-latin_latin-ext-500italic.woff') format('woff'); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
}

/* ubuntu-700 - latin_latin-ext */
@font-face {
  font-family: 'Ubuntu';
  font-style: normal;
  font-weight: 700;
  src: local('Ubuntu Bold'), local('Ubuntu-Bold'),
       url('/fonts/ubuntu-v13-latin_latin-ext-700.woff2') format('woff2'), /* Chrome 26+, Opera 23+, Firefox 39+ */
       url('/fonts/ubuntu-v13-latin_latin-ext-700.woff') format('woff'); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
}

/* ubuntu-700italic - latin_latin-ext */
@font-face {
  font-family: 'Ubuntu';
  font-style: italic;
  font-weight: 700;
  src: local('Ubuntu Bold Italic'), local('Ubuntu-BoldItalic'),
       url('/fonts/ubuntu-v13-latin_latin-ext-700italic.woff2') format('woff2'), /* Chrome 26+, Opera 23+, Firefox 39+ */
       url('/fonts/ubuntu-v13-latin_latin-ext-700italic.woff') format('woff'); /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
}

and then in myrules.styl you insert this:

// local font references
.font-Ubuntu
  font-family: 'Ubuntu', sans-serif

from now you can use those fonts as any fonts for example:

  <q-page class="font-Ubuntu">
       ...
  </q-page>

@dobbel https://en.wikipedia.org/wiki/Lotka–Volterra_equations

@aislan said in Web workers - how to use in Quasar:

Right now I’m just struggling with Quasar to place my worker files in another place not in statics folder.
I would like to put them next my actions folder, etc.

with the method described on top, you can put them anywhere - as long as they have an extension .worker.js. The webpack will do his job and properly inline/bundle your code.

And related to workerize-loader, how could we test them with Jest, for example ?

Don’t know carefully??? This should be asked to the author/users group, probably.

Haven’t tested this yet, but definitely looks promising:

https://github.com/mozilla/web-ext

@beets nice work in deployment

If you’re using nginx, then if it is not an enterprise one, I strongly recommend using openresty fork - you can process browser feedback like csp etc. directly in lua part of nginx (and many, many more).

The second hint for nginx and even lover latencies is using custom configured caches - caching dynamic pages even for 1-2 minutes gives a BIG win in some setups. Well, nginx/openresty is obviously awesome. Oh, and proper host configuration - files, handles, buffers etc. That is not an art - it is a black magic haha Careful host configuration can give you even lower latency and higher reliability.

Anyway, I like your style

@beets

Again, with dev proxy rewrite and other local configurations like a simple change in hosts file:

127.0.0.1    media.example.com

You can mimic any production configuration on development. It is highly usefule if you have accesss to local/development/qa vms/docker/kubernetes with production external services.

What I’m trying to say, is that dev environment should be a mimic of production instead of its other conditional incarnation. Different way of thinking.

@beets said in How to set up a CDN for SPA (got problems with vue-router):

Overall it makes me happy, the only thing that doesn’t work is Quasar’s automagic static asset handling, which as I mentioned above I just don’t use, and instead use explicit references to the media subdomain.

for that you can use a devserver feature - proxy:

https://quasar.dev/quasar-cli/quasar-conf-js#Property%3A-devServer

documented here:

https://webpack.js.org/configuration/dev-server/#devserverproxy

you can easily use just one configuration (production) and in dev environment statics, media will just be proxied whenever you need. It is very powerful because you can not simple proxy but also use: changeOrigin, context, cookieDomainRewrite, cookiePathRewrite and pathRewrite in such a way, where even the most hard to maintain api/backend will properly work in dev environment (which will be identical to the production).

@njsteele said in Some larger projects using Quasar Framework:

Hello.

…but I don’t see a lot of people showing some major stuff working in the community vs other platforms (i.e Vuetify has a lot more production apps on display than Quasar).

well, Quasar is such a superior beast, and gives so much competitive advantage, that based on game theory it is not economically viable to promote it to give hints to your potential competition. Basically, it is so good, that you just want to enjoy it on your own. It is in your interest, to let the competition use inferior tools such as vuetify and many others. The Nash equilibrium for Quasar is very strange and imho it will resonate to balance in a few years. The upcoming quasar+vue3 could move that sooner, but this will only put emotional hopes for developers, which is usually bad, because hopes are very hard to manage. I’m not exactly sure, that many people thinks in those terms, but it’s not a problem for me if they don’t (because I’m using Quasar and I have this advantage)

@Jonalxh yeah, the proper tour component could be a game changer for more complicated Quasar apps, helpdesk apps, remote apps etc. I would only hope that this Quasar technology:

https://quasar.dev/vue-directives/morph

will be a base for a proper quasar tour component.

@ghada said in change meta tags dynamically from index.html:

@qyloxe I am using firebase with node js

with node (express?) you have many templating engines:
https://expressjs.com/en/resources/template-engines.html

this one is quite nice as it is very similar to jinja2:

https://mozilla.github.io/nunjucks/

So in essence, your index.html from Quasar could be postprocessed by node/nunjucks based on request headers, context etc.

yeah, that could be a problem in typical spa/html pages but there is the way without ssr also.
If you are deploying bundled files on the www server with for example php, aspx or similar server side technology, then you can change your index.html into index.php and make any changes to headers dynamically as you wish.

But that is not all. If you are using reverse proxy - let’s say nginx/openresty then you have a couple of other technologies at disposal. For example server side includes (ssi):

http://nginx.org/en/docs/http/ngx_http_ssi_module.html

Or with openresty - you have a full Lua programming language at the reverse proxy layer - for example something like this:

https://openresty-reference.readthedocs.io/en/latest/Directives/

with this directive:

https://openresty-reference.readthedocs.io/en/latest/Directives/#body_filter_by_lua_block

With those tools, you can change any fragment of body or headers from your pages, files, etc. before it is transmitted to the client browser.