What is Reddit's opinion of Quasar Framework?

From 3.5 billion Reddit comments

Well, the app uses a UI framework called Quasar that can be found here: https://quasar.dev/

However, most of the choices of what parts to where, how to show them, colors, etc. are all done by me.

I'd recommend Quasar. I used it now for multiple projects. It's a framework that expands vue. You can do anything you would do with vue and more. It supports Ionic capaciator so you have one codebase for web, android and ios. Also you don't need a ui framework like vuetify or anything like that. The documentation is great as well.Quasar got a large updated recently with vuejs 3 support. I'd recommend you check it out.

It was only a small change to the docs, but one I'd been wanting for ages: they've finally put the API at the top of the page!

The docs still aren't the greatest to read if you kinda know what you're after already. A toggle to expand all the code snippets would really help this. That way I can just open up a docs page, toggle all the code to be visible, and then ctrl+f for what I'm trying to use to take myself straight to an example.

The docs, as they are atm, are still very much like window shopping. If I know I want a q-card then I can go to the docs page for it and scroll through to see what sort of stuff I can do with a q-card. But if I'm already using a q-card and I'm trying to align some q-card-actions it'd be nice to ctrl+f for align=.

Obviously that is a pretty contrived example as you'd just go to the With actions section, or even just searching for alig gets me to the Aligning actions section. But there are certainly times where you just want to search their example code instead of scrolling through the docs trying to find the example for what you're already doing.

But don't get me wrong, their docs are far and away better than most docs I've ever used. They've got a search bar that works, so they're already ahead of the vast majority of libraries out there...

Hi und Danke für Dein Feedback!

Zum Thema "läuft mobil" <- da bin ich echt froh und hab mir RICHTIG einen abgebrochen, damit es das tut. Ohne das Quasar Framework (https://quasar.dev) wäre ich schlichtweg verzweifelt.

Protip (nur, falls noch nicht geschehen): *lamonee als App installieren.

Das mit der Formatierungs-Zerschießung ist mir leider auch schon aufgefallen. Github verwendet bspw. auch Markup - das ist eher weniger kompatibel mit dem Namen :D

Bezüglich unregelmäßige Einkommen, Abbuchungen alle 14 Tage, etc. Ja, das ist durchaus ein Thema - aber wahrscheinlich keines, das *lamonee abdecken kann. Die ganze Logik von *lamonee geht vom Monatsrhythmus aus. Das zu ändern wäre dann der, äh, 4. Neustart der App :D . Ich habe mich für den Monatsrhythmus entschieden, weil, selbst wenn man häufiger oder seltener Einkommen erhält, die Fixkosten meistens(!) schon eher monatsgebunden sind - siehe Miete, Fitnessstudio, Leasingverträge, Netflix, Spotify, etc., etc.

Und noch ein winziges Detail am Rande, weil es immer wieder zu Missverständnissen kommt: ein Fixkosten*charm (jetzt muss ich aber mal mit den Sternchen aufhören) kümmert sich nur darum, dass das Geld am Stichmonat da ist. Der Umsatz, der diesen Betrag dann auch aufbraucht, muss von DIR angelegt oder importiert werden (ich empfehle ja letzteres). "Recurring Transactions", wie's YNAB macht, gibt's nicht.

> Database: not sure; considering SQL as it's the most basic?

Django's ORM assumes SQL, so you should definitely use that. Also, Django manages your DB using migrations, so you don't really need to use raw SQL. You just define normal python classes, and apply migrations.

> How does one decide which stacks to use, particularly Front End Framework and Database?

Matter of personal preference, mostly. I love python, and while JS is pretty nice since ES6, I wouldn't want to use it on the back-end. For front-end, really, what you are comfortable with. You can stick to React if you are comfortable with that, or you can give Vue a try if you don't want to write garbage soup (aka JSX).

> Structuring a project: this is likely the first problem I'm encountering right now. As a student who has never done a full-stack project, what is the typical way to properly structure a repo with different stacks? I'm searching for a GitHub repo template right now, but I'm open to any suggestions!

Docker, and docker-compose. I usually use Traefik for routing, with an nginx container for built assets, static, and media files, a python container for django, a postgresql container for the DB, and a node container to work on the front-end in the dev phase only. If you use nginx for routing, you can also treat the whole website as one, so you can use basic HTTP cookies for auth, don't have to deal with CORS bs, etc.

If you want SSR, you can also use a Node container in production, but that's not really necessary for deep web apps.

• My favourite thing for Django APIs: https://ariadnegraphql.org/
• My favourite SPA/PWA/SSR js framework/component library: https://quasar.dev/

Quasar was linked incorrectly. It is a framework for launching Vue to every platform. Unfortunately it uses Cordova or Capacitor for mobile deployment, which is not what you want.

EDIT: Quasar Documentation

I highly recommend Vue together with django-webpack-loader (although you can prototype and use Vue without webpack, e.g. straight in your browser after including the Vue import)

&#x200B;

If not, there's really nothing wrong with writing vanilla JS components, jQuery components, or whatever you are comfortable with... but if you are interested in productivity, then the fastest way is to re-use the open-source libraries that are already out there. Just as with Django and its ecosystem of libraries, you can build frontend apps very quickly if you adopt the patterns and component libraries from a popular frontend framework like Vue, React, Angular, etc.

&#x200B;

In your case, let's say you want to implement search/sort/selection over a table of data for your invoice feature. That can be a few lines of code/configuration using a pre-implemented "Table" component from a component library like Quasar, or maybe a few hundred lines of Vanilla JS that you write yourself. Or it might be 50 lines using a framework like Vue, without any other library support.

I think it's more of a signal that there's still a lack of maturity in the space and there is a lot more improvement to be done in the coming years to create more "plug-&-play" pipelines and workflows; possibly some standards/interfaces.

The Quasar Framework for Vue (https://quasar.dev/) I feel does a great job of "scaffolding" around the development workflow through their CLI. It does not address even 50% of OP's rant, but I have found the Quasar framework and CLI super productive to work with because the scaffolding is really good.

In my opintion documentation (such as this one as an example: https://quasar.dev/vue-components/ajax-bar) should definitely not live in the code.

I am close to a panic attack if I imagine that somebody would try to shove that into the actualy code of the app... The beauty of vue components is that they are largely 'self-contained' and should know very little about their parents.

When I look at the documentation of that library that you link I can see so many useless comments. I am aware that they are just trying to show off the capability of the library, and it might be very useful in some cases, but I would extremely worried that people start abusing it and think that they have to annotate every single variable, prop, etc. etc. bloating a component that would be a slim 100 lines to 500.

>Consider the Quasar Framework to get you off the ground and going quickly. They even have a templating page to get a boilerplate landing page and navigation panel setup very quickly.

Definitely an honorable mention, the frameworks I mentioned were more what I liked than anything (not much a fan of Material Design, personally).

>I would advocate against embedding Vue in Django templates, but not for any extreme reasons. I just find that it is better to keep these separate as it helps down the road.

Like inlined in a script tag? 100% agree, though for a project needing a gradual transition from vanilla HTML/CSS/JS, it isn't a bad idea at the very beginning. That's how I started out, but as the page I was working on grew more complex with multiple components/templates, that's when I pressed the button for SFCs. Even with Vite the build process is mildly convoluted since there still needs to be a gradual migration, but it's hardly terrible.

I completely agree with all of this. Vue.js is wonderful, and I say that as someone who tolerates Javascript. Using Vue made frontend work enjoyable.

Consider the Quasar Framework to get you off the ground and going quickly. They even have a templating page to get a boilerplate landing page and navigation panel setup very quickly.

I would advocate against embedding Vue in Django templates, but not for any extreme reasons. I just find that it is better to keep these separate as it helps down the road.

I would say check out Quasar. It's kind of a framework on top of a framework (Vue) and honestly takes a lot of the hard work out of setting up a frontend project. I've definitely got my issues with it (especially around their documentation), but I think it's probably the best thing a frontend newbie can start with as it removes a lot of the boring guff that gets in the way of just seeing something on the screen.

Honestly you don't need to worry about it too much if you let a framework handle it for you, especially for a starter project. Check out something like Quasar. The quickstart project sets everything up for you and you don't even need to touch webpack if you don't want to. Once you get a bit more familiar with frontend technologies you'll be a lot more comfortable diving into webpack related stuff.

Hi! thanks.

The problem with the lifespan of the links is that once a user generates an auto-generated link or a custom one, he might use it at at-least few places online and the link would be on that page forever in his context.

If he does not renew his membership, the system should not recycle and allow someone else to choose the same link(auto or custom) again, since he would start to get messages irrelevant to him. Its something like email Ids, gmail doesn't delete inactive email ids and enables it for someone else to take it.

For cases when a link is generated but was never actually used anywhere(can figure that out if link was visited through code), such links can be recycled.

Your price is right on.

For the tech stack, for the form itself, I will need something which can catch dynamic routes. Node with ExpressJs, PhP with Slim framework and the subscriber back-end would be based on quasar.dev with some API running on Slim or Expressjs.

if you wanted to explore, what you ought to do is create a sheets few in postgres

https://github.com/lincolnturner/gspreadsheet_fdw

this will bring the dataset directly into postgres, and may even allow you to update it. eitherway, you could experiment with what's required to the users.

from there you might try postgraphile to create an api

https://www.graphile.org/postgraphile/

and perhaps a UI could be quickly constructed from quasar framework

https://quasar.dev/

as others pointed out, it's likely in a Google spreadsheet because that's the easiest way to do CRUD and there's no derivative products necessary.

I love using Django + Django REST Framework + Vue for projects. Vue gives that more interactive and fancy UI, especially when using something with builtin components on top of Vue like Quasar. You can build super capable interactive and beautiful web apps using this combo.

No code? Can't think of anything. The closest to that might be a component library for a js framework, like Quasar for Vue. Still need to build functionality yourself, but it takes care of a lot of it.

Could roll your own, modals honestly aren't that hard to implement, the official docs even has an example. https://v3.vuejs.org/examples/modal.html

You could reference popular component libraries like Quasar/Vuetify to see their implementations (they call modals dialogs). https://quasar.dev/vue-components/dialog

It's not a bad idea, embed Flask in your application, use Swagger to generate the API interface and host a simple SPA web app. Good enough for single use applications and provides an upgrade path for distribution. Our front end guys at work suggested I look at Quasar for generating Vue based front ends which might be easier than coding the whole layout up manually.

https://quasar.dev - There is no amount of words that can describe all the advantages and features that come with quasar. A quick scroll through the documentation should be enough to convince you to give it a try. There is no turning back after that. You can literally prototype a full project in a couple of hours and get it production ready in a matter of days on multiple platforms (web, desktop, mobile, etc)

> I can proudly say they should all be flushed down the toilet.

Hard disagree about Vue. Throw 10k+ rows in this table: https://quasar.dev/vue-components/table and it works like a charm, you can paginate, do filtering client side, sorting client side, and you save money on the back-end in terms of CPU and bandwidth.

> and more readable understandable code.

ES6 and Vue.js SFCs are really nice to work with, IMO.

There is definitely a time and a place for server-side rendering, there is also a time and a place for true SPAs.

Assuming <q-radio> is a quasar component, let's check the docs...

https://quasar.dev/vue-components/radio

> @update:model-value -> function(value, evt)

>Description

>Emitted when the component needs to change the model; Is also used by v-model

You need to bind your method to @update not @change

You develop in your machine/PC... not on an android phone. All what you have to install will be on your machine. To develop Android apps with Vue you have two options:

1- Develop a native Android Vue app... you would need to install Vue Native CLIwhich serves as s command line to run the scripts such as $ npm run android. When ready for production you create your .apk file and upload it to Google Play Store.

2- Develop a non native Android Vue app. You install VUE-CLI in your machine/PC globally so that you can use it for different Vue projects in your local machine. Vue CLI serves as s command line to run the scripts of your Vue projects. You have also 2 options here :

2-1- You can wrap your app within a WebView (Java) and create your .apk afterwards.

2-2- Use a Javascript framework such as Quasar that can help you with the process so you won't have to spend your time and energy with Capacitor and Cordova settings and configuration. Refer to the documentation here.

You can always make a Django backend with a GraphQL (ariadne) or REST (drf) API, and then you can use just about anything as a client, including electron apps, SPA pages, or even a native desktop client using e.g. C#, which would look more like a desktop app than a web app.

If all the user wants is the ability to double-click something and be taken to the app directly, you might get away with not doing any extra coding at all and just adding a shortcut to your site on their desktop.

Honestly, there is seldom much benefit in creating a desktop app as an interface to a web app. You are just adding extra complexity to your codebase, which means extra development time, which means greater cost for the customer, but if that's what they want and compensate you accordingly, good for you I guess lol.

If they really want a native app and electron is acceptable, check out quasar. It's based on vue.js, but you could at least reuse components across different apps - electron (Windows, Linux, and Mac), SPA, and mobile (Capacitor or Cordova).

There are some FE frameworks which I have found to boost productivity if you are building applications that follow mainstream UI design language these days (the more exotic your UI, the more you'll have to roll your own; rule of 80/20).

The Quasar framework for Vue is particularly good if you are open to Vue: https://quasar.dev/

I'm not sure if there is an equivalent for React/Angular, but what I like about Quasar is that the team has put together the underlying plumbing for:

• SPA/PWA web app development
• Desktop development via Electron
• Mobile development via Ionic/Capacitor or Cordova

This includes the underlying build process plumbing which takes a lot of overhead away from even setting up a modern JS project.

The component library is one of the best I've used and is extremely flexible and intuitive; very easy to recombine pieces to get what you want and sensible extension model when you need to build custom components that plug into the framework.

The documentation is also fantastic, rich, and detailed so I have rarely gotten stuck for lack of information on how something is supposed to work at the edge.

Sample app I built: https://www.covidcureid.com/ with source code.

(Forgive the cold start time of the actual lookup on the first hit; Azure Functions do be like that).

Try it out on desktop and mobile. Tap through it on the chart and filter the results.

If the goal is adding ChromeOS support, you may be able to utilize PWAs (Progressive Web Apps) as an alternative to Electron which should be able to utilize most of the same codebase with. A quick search shows that Quasar at least has some support for it here, though I haven’t looked too deep into the code (and am only tangentially familiar with js, especially various frameworks)

For backend I recommend going with something like Laravel.

For frontend I recommend looking at Quasar Framework (https://quasar.dev/). It has some really useful features for building out mobile apps using Cordova/Capacitor.

Method one:

Use Quasar's classes. You want some div to have Padding All around? add a .q-pa-md (which stands for quasar-Padding*All-Med*iumsize).

Method two:

Mess with SCSS variables. You can put any of these in your quasar.variables.scss file and hard code various margins to your own liking.

<q-page-container class="q-pa-md">

or

q-page-container.q-pa-md

if you're using pug.

https://quasar.dev has a builder for creating Vue apps with Electron. Create an starter app using their CLI app and see the Electron wrapper it generates. You might even consider porting your app into Quasar so it’s supported long term

WxWidgets if you know anyone of C, C++, Python.

As someone recommended Electron. JavaScript is not good with floating points. You might have to use a library for that. Probably currency.js

You should look into web app development. I would strongly recommend against desktop app due to friction in distribution of software. Internet is the easiest way to distribute your project. No app store on mobile or desktop or voice assistants will get you in front of prospects as quick as internet.

An exception of this is a case where you are developing something that assists STEM+Med activities, you want to maintain strict compliance with a law like HIPAA, etc.

If you so choose to develop using a web app then look into Quasar framework(https://quasar.dev). You can use it to generate a web app, mobile app, desktop app, and a browser extension. It uses VueJS that is very easy to get started with when compared to Angular or React. As a backend dev, I got started with frontend using Quasar in around two days.

From a single codebase and a single CLI app, you can publish a Single Page App (SPA)/Server Side Render (SSR) for the web, iOS app, Android app, and a desktop app that runs on Linux, Mac, and Win10.

Plus if so inclined, create browser plugins for Chrome, FireFox, Brave all from a single codebase.

I believe it is one of the most complete modern web frameworks in existence and I found it incredibly easy to go from zero to productive in a short period of time. They bundle together webpack, vuejs, vuex, axios, icon genie, and scaffolding such a way that a lot of the complexity and tedious tasks required to weave together the various building blocks are automatically handled. And, I also enjoy the single CLI which manages most all the development environment and build tools with what feels like an easy and straightforward manner.

Also has a boat load of UI/UX components, scroll through the list and run the demos here: https://quasar.dev/vue-components/ajax-bar

Very nice!

You may also want to checkout JustPy

It allows you to develop a modern GUI just in Python, no JavaScript required at all and also supports Quasar (again without any need to learn vue.js) for a Material Design interface.

I use https://quasar.dev - for the kind apps we build at work it’s amazing!

It’s geared towards Vue but ships lots of Material Design styled components.

PWA support is baked in too.

Worth a look if you are into Vue and Material Design.

For me, the docs are the only thing stopping me from enthusiastically recommending Quasar. My team's refusing to upgrade from v0.17 because the new docs are a pain to use. As an example compare v0.17 QBtn with latest QBtn:

• The nice separation of examples and code snippets makes it easy to look through.

• Code snippets are not expanded by default, so if you know roughly what you're after you still need to read through the docs to find the right snippet instead of ctrl+f

• Props are a lot easier to read because they're not split across different tabs

• Slots / events / methods can be searched for with ctrl+f - in v1.0 they're not the default selected tab under API, so you have to search using their widget (less of a problem with QBtn because it has fewer slots/etc)

Those 4 alone are a massive hindrance to dev time.

The docs are still far and away better than a lot of other libraries out there, but given how invested you are in the Quasar ecosystem you'll find yourself spending a lot of time there - more so than other libraries you might be using.

All that said, Quasar is still a really nice library and we don't yet regret using it. I'd definitely advise fixing your version though, don't just follow latest. I still read through the change logs for the 1.x versions and it seems like they like to break things - this was definitely true pre-1.0 (as expected) but it seems like a habit that's followed them through to full release.

I don't like their push to use quasar cli. Quasar depends on Vue and then Electron/Cordova, not the other way around. However it is not required to get vendor locked into quasar cli - the library can be imported into Vue like any other component framework like so:

https://quasar.dev/start/vue-cli-plugin

Being able to import Quasar into existing Vue project is just not being very promoted in the docs. One of the fist things I did and can happily ignore fighting the quasar.conf.js intricacies.

If you then need Electron or Cordova on top of Vue, I'd use their native workflows rather than Electron's.

Nuxt or Checkout Quasar for a full UI framework with integrations:
https://quasar.dev/quasar-cli/developing-pwa/handling-service-worker

Vue.js, and the Quasar framework.

I don't like JSX, so I am not a fan of react. Angular looks more complicated, and Google doesn't seem to keep any stability in anything they do (https://killedbygoogle.com/).

Vue uses JavaScript, I like the way the single file components are organized. Less of a learning curve, and knowledge that translates well to other projects (finally comfortable with ES6).

Quasar gives you material components, and an app that makes certain things even easier.

If you want to just add some very simple AJAX into existing templates, rather than going full SPA, there's also Intercooler.js. You can simply use it to embed some reactive elements inside existing webpages.

Give Quasar Framework a try : many component, including calendars, many integrated plugins, and easy export your code to android, iOs and electron app...

I come from Vuetify, and think Quasar far more convenient.

>If your app is a run of the mill crud app, like most, than I would take a look at https://quasar.dev/

Why do you say this? For basic CRUD, Nativescript's framework seems like less overhead.

Quasar looks awesome though- I just watched the 30 min application. Is that same stuff that essentially runs your app on in an instance of chromium when it's a desktop, and runs it in an embedded browser on mobile? If I go this route, I can still use web-cookies, etc regardless of platform, right?

Thank you so much for sharing.

It really depends on the nature of your application. If your app needs to be closer to a true native app (heavy use of the device hardware) than nativescript could be a good solution.

If your app is a run of the mill crud app, like most, than I would take a look at https://quasar.dev/

Quasar lets you leverage cordova to push out a normal vue app as a mobile application.

Hi, I saw you updated the date-picker example. Thanks. It works for me.

For the next version, can you update that example on how to close the date-picker when a date is selected or you press <Esc>?

The linked code at https://quasar.dev/vue-components/date#With-QInput behaves this way: Click on a date and the datepicker closes. Press Esc without clicking and it closes too.

The example code displays the picker. Clicking on a date changes the date in the form. Here the picker stays visible and is difficult to close.

> For example, JustPy supports Quasar (https://quasar.dev) components.

Nothing pisses me off like having to watch a video with a stupid snapshot image to understand how something works. Has the whole development world gone retard?

It's built with the Quasar Framework and still under development.

I decided to post about it here already before it's finished because Microsoft just ended Windows 7 support so this is more relevant than ever.

It also features a social media module which I'll enable later.

I hope the site will be useful for some looking to switch and that it helps GNU/Linux-adoption gain traction.

you should look at https://quasar.dev/ the reason people use these frameworks because it is easy to get started and also they enforce you to use design standards which intern will reflect how your app looks.

So I think I figured out the difference here. I saw you mention "component framework". Pardon the semantics, but I I think you're looking at Quasar as a component library doing extra stuff. But since they've defined themselves as a framework, you should look at it more like the devs providing a toolset of pre-written code to accomplish common programming tasks. The components being a subset of the those tools.

It sounds like you could get the best of both worlds by using the UMD version of Quasar, which is meant to be added to existing projects outside of the typical Quasar framework structure.

Just in the experimenting phase, but I'm toying with making an admin GUI for Starlette. Starlette's great and I enjoy using it with FastAPI, but I miss having a proper-ish admin GUI.

So I rigged up some classes and made a truly modern client for them in Quasar, which will export to web, Android, iOS, Electron, etc. The client downloads a "description" of the schema and relevant pages, and builds everything locally.

The main challenge is making it extensible. Since the client, sort of by nature, is its own project and delivered as a bundle, it's hard to find a way of letting programmers add custom pages.

Depending on the interface and animations complexity I would recommend to look into Quasar or Ionic. The advantage of these options is that they have a lot of prebuild components and options that would help you to bootstrap the application and also learn how to create components on your own.

Not to discourage you, but one thing to keep in mind is that sooner or later you would need to store data somewhere which is mostly done via database, backend and APIs. That's where knowing HTML, CSS and JavaScript (regardless of Node.js) are not going to be enough and you may need to find someone to help you.

Honestly the main reason I quite like using Quasar v0.17 is that their documentation is really well written, and super easy to read. Having had a look at the v1.0 docs, I can't say I'll be pushing to upgrade my company's version in the near future. For example, compare the v0.17 docs for QTable to the v1.0 docs, and try to figure out how you'd implement server-side pagination in both versions.

The one huge problem I see with the new docs is how they've laid out the API reference. Using the same example as above, I know that I need to listen for the @request event. Ok cool, if I ctrl+f for "request" in the v0.17 docs then I find:

It's right there for me to read, then immediately below it is the code to implement it.

With the v1.0 docs, there are only 2 results for "request". Immediately below them is the end result of implementing server-side pagination, but you've got to click through to another site to see the actual code. If I just wanted to see the API reference for it, I've now got to scroll down to the QTable API... thing... Click the "events" tab, and then HOLY FUCK WHAT IS THIS MONSTROSITY‽‽‽ I'm honestly struggling to understand this reference for the v1.0 API, despite it being exactly the same as the v0.17 version that I'm used to.

Is https://quasar.dev/ built using the framework?

network tab is saying;

281 requests 2.6 MB transferred 2.6 MB resources Finish: 6.07 s DOMContentLoaded: 2.14 s Load: 5.67 s

That's enough to put me off using it.

If you're familiar with Vue, then Quasar is something you might want to look into. It's essentially a component framework doubling as a project-wrapper of sorts. It'll enable you to build your project for a handful of targets , one of which is mobile. It also has an Electron mode in there.
Bear in mind it'll take some time getting used to the way a project is structured , and how configuration files are handled.

Random question to anyone. I've tried for 2 days to deploy quasar to Heroku and the instructions on the quasar website don't work:

https://quasar.dev/quasar-cli/developing-spa/deploying#Deploying-with-Heroku

Specifically, this line gives an error because it's not a valid Heroku-CLI function

> heroku deploy

I'm using Quasar framework because it does more than UI, it simplifies a lot of the config cruft of Vue (tree shaking, linting, etc.) And it rolls out to IOS/Android and a desktop app with minimal effort. But I agree, you should use the right tool for the job.

On the other hand, if I was working on a 10 page website I might not bother with the complexity of an SPA like Vue at all!