Css and reinventing framework ?
I’m going to give a high-level overview of why it’s best for Quasar to have its own CSS framework.
- Control of quality & timely fixes. Quasar’s CSS framework is done with performance in mind. Most of the external CSS frameworks have their own JS library that must be loaded. You can’t expect everything to fit in the most efficient way. Also see #2.
- Quasar has multiple themes (currently Material and iOS with more to come). Quasar components must work with multiple themes. Each CSS framework requires its own markup. MDL for example does not have all the components built in Quasar. Some other framework might have feature X but not feature Y. Quasar is the most complete framework out there. It would be a mess trying to integrate different frameworks. Performance & efficiency would be out of the question.
- Writing a framework with which you can simultaneously write a desktop responsive website & mobile apps is something that currently doesn’t exist at the moment (this was one of the reasons I started working on Quasar). Electron wrapper coming soon. These capabilities raise a lot of issues and require special CSS classes, like make a <div> visible only on Mobile but not on desktop etc etc etc. All external CSS frameworks are nowhere tweaked as Quasar’s to handle these many environments.
- Since every external CSS framework has its own markup, how would you be able to write same code to generate UIs that look native for Android and iOS simultaneously?
I won’t get started to talk about the low level implementation cause the list would go on forever really The reasons above just scratch the surface on why it’s better for Quasar to have its own CSS framework.
druppy last edited by
Ok, thanks for taking you time to explain.
I think I understand, and your arguments are worth considering, I just worry when things look like reinventing the wheel
The special focus on for Quasar (platform themes), is a good argument, along with the logic normally found i other CSS (JQuery) libs make it hard to maintain a vue version of that logic part alone of the framework (like vue-strap and vue-mdl, that all take that approach) .
Does all this not, on the other side, require a bit more documentation of the CSS parts too, or have you been using names and css concepts that resembles the classic frameworks, to keep the learning barrier low ?
I think some of these arguments would be nice to have in some of the intro doc. Many developers are looking for new frameworks especially for vue2, and these arguments allong with the basic idea represent some of the philosophy behind Quasar.
With a good community … this could be really solid
Yes, documentation will be greatly improved after the API stabilizes and we’ll enter the first beta for v1.0 (happening soon). I’ve seen features that are under-used or not used at all and people trying to import external dependencies to have X feature (that is already in Quasar and working really well). It’s all documented, but people tend to not read documentation or skip steps. Also, the prerequisites I posted in the Getting Started are also overlooked so when reading documentation it’s really hard to understand how a Boolean Vue property can be used, or an event, and so on. Anyway, started rambling here. Main point is that yes, documentation will be greatly improved to focus on the most important use-cases.
Thanks for sharing your thoughts!
Yes, thanks for that update, I wondered the same thing about documentation.
Not having learned much practical Vue usage yet, but enjoying your implementation so far, I wondered if it would be possible to construct a single page containing available components to showcase, programmatically, the design principles being applied.
If doing this by using exist infrastructure, might it reduce the documentation overhead as the framework matures?
Just a thought, it was the first step I considered putting together myself so that I could understand themeing with Quasar in a visual way.
I like that you’ve steered away from existing style frameworks to ensure optimisation is maintained and markup structure isn’t tethered to same-same ways of thinking. The technical debt incurred by this approach will be a burden until the merits of the decision are well laid out.
EDIT: I have just now found and read through http://quasar-framework.org/components/list.html
Awesome, absolutely awesome way of presenting all of the component information.
I wrote the Quasar Play App which showcases the usage of all components. Included it in the documentation website (the demo examples on the right are from this Quasar Play). You have the “View source” button or you can jump in and see the whole app code here: https://github.com/quasarframework/quasar-play
I just wanted to follow up, with a question, on the responsive part.
The Components Guide shows all compontents in the context of a mobile screen. What would be the best way to see their style in a desktop context? I consider the responsive aspect really a significant differentiation to other frameworks in the eco-system. It might be beneficial to expose this in the Component Guide to show clearly it’s responsive capabilities.
Thank’s for Quasar. Great and impressive work.
On each page in the doc website where there is a demo showing up there’s also a “view on desktop” button. This is so because of screen real estate reasons.
And yes, this is a major differentiating factor.
I can’t spot this “view on desktop” button on the docs page. Could you describe where to find it, please?
I attached a screenshot, how the docs page appears to me.
@hwiehen Zoom out until https://github.com/quasarframework/quasar-framework.org/issues/3 gets fixed.
Found it. Thank you @rstoenescu .