[v1] @quasar/app v1.0.0-beta.15 released!

[rstoenescu]

Fixes on processing CSS options & logic for both dev and build #3736

[Lou Rectoret]

@rstoenescu I’m planning to start a new project, but I need an stable version.

In order to take a decision I’d need to know when is +/- expected to have a solid v1 ??

Thanks for your effort!

[somascope]

I’m on the tail end of a Quasar 0.17.20 Electron desktop app, and I feel “the feels” around this, too.

I’m not answering for anybody here, but I have thoughts towards this when wanting to use an open-source project in production “now”. If it’s in Alpha, don’t even consider/worry about it. If it’s in Beta, it will be in Beta for at least “another 60 days”, but more likely 90+ days depending (I don’t say this with regards to Quasar, but just in general…you really don’t know). If you’ll be getting into the main, serious development of a project before 30 days, then don’t consider a Beta. Depending on the release cycle, Quasar (or at least other products) have a Release Candidate stage that takes yet more time before being an official release.

Or… if a product is in Beta, and you aren’t delivering for at least 90 days, you can measure the risk of not-ready-for-production software and bring it into your project. And hope that you have a production-ready version to integrate into your project before your completion date. It’s a gamble, and not worth the risk, IMO.

The beauty and the pain of amazing open-source stuff, like Quasar, is that we want to use what’s coming down the pike… but can’t until the upcoming awesome stuff is really ready. It’s so much better to play it safe and use a production-ready version even if it’s not the “bright and shiny.” In my opinion, the project and the client won’t be worse off, only we the developers will have that light “fear of missing out” feeling

The uncertain delivery dates of open-source software is a benefit. The alternative is corporate-based software & tooling that must meet dates, and tends to really suffer because of that. Oh, and they cost to use, usually, too.

[turigeza]

I have just upgraded to v1 I don’t think it’s a big deal coping with the small changes of the beta.

On the other hand upgrading form 0.17 to v1 is a big change and I really would not like to do it again.

I would prefer beta to run as long as needed so all issues can be addressed rather than rush it. After all gmail was in beta for over 5 years : ) never stopped me using it. Thank you for the solid work you guys put in.

[sybrix]

I love this project but the move from 0.17 to 1 has been a major set back for me due to number of components changed/deprecated between the versions. I was very pleased with 0.17(pleased enough to donate), seriously thinking about reverting just to get my project out. I would just caution to proceed carefully w/breaking changes; even between major version releases. Many good projects no longer exist (or do so in obscurity now) because they were not mindful of this.

[metalsadman]

@sybrix quite true tbh, but it was to be expected. i still think you should consider v1 tho, since it’ll be the version that will get more stable releases now. there’s an upgrade guide in their docs, now if you haven’t checked that out yet, would help you a ton migrating to v1.

[s.molinari]

@sybrix - It was a tough decision by Razvan to do such deep changing of the APIs for v1. But in effect, it was because of the learnings a few years of prior betas (noting the word Beta!). Razvan knew, he had to basically start from scratch. And if you can imagine that, it took about 6 months to do, which is amazing.

What you can be rest assured of now, is that V1 is much more optimized, much more stable, much more logical and easier to work with. It will be Quasar’s future and the RC stage is coming fairly soon, which means feature freeze (and API freeze). So, it’s the way to go from now on and I would suggest everyone move to it.

We are sorry for the pain the rewrite has caused, but as almost every developer has noted making the change to v1, it’s well worth it!

Scott

[rstoenescu]

Hi,

Let me emphasize on a few things:

1. Version number: “1.0.0” --> no more breaking changes, finally stability for the future.
2. v1 renders 2-3-4-5x times faster
3. v1 is way easier to CSS customize
4. v1 has a LOT of new components, features, capabilities – which were not possible with the 0.17 architecture

This is the last “tough” milestone. Once you reach using v1.0.0 final (which is very close) you can have peace of mind that upgrading to newer 1.x.y versions can only mean “more goodies”. Your apps won’t break.

Take some time to check out the v1 beta docs, look at all the demos. You will notice the tons of new capabilities that your app can have. And not just that. Once you port it to v1, you’ll notice that your website/app will run faster.

v1 is not meant to be “good”. It’s meant to be the best framework out there. Once you get past this final upgrade effort, it will be well worth it, I assure you. The general consensus on v1 from our community is “I didn’t know a framework can be THIS good until I upgraded to v1”.

[qyloxe]

@s-molinari @rstoenescu
Totally agree, Q1 is just awesome. It is a work of a genius and it will be the best framework and it will pave a road for many years ahead. Just as jquery did in the past.

Anyway, the original question is about migration of old projects into production. IMHO in non trivial 0.17 projects, migration to 1.0 could be still quite problematic, at this moment. Some people asked me about it and that is what I said to them, maybe it would be of help to anyone:

• it is easier to just start a new project and gradually copy and adapt elements of old projects. Starting with store, plugins/boot, routing, layout, css, typography, and then every single component by its kind. For example firstly buttons, then cards etc. There will be a lot of manual keystroking but there is nothing to fear or overcome.

• this is IMPORTANT - new Quasar as for now doesn’t work with keep-alive! It is a show stopper for many projects where one have forms or tabs or basically anything on toggled DOM group elements (panels, tabs, slides). Without this solution, migration of 0.17 non trivial projects to 1.0 is impossible - it breaks existing functionality and there is no way to overcome this in current V1.

• you should plan to deeply learn new flex css. New Quasar is based on flex but as far as it is an excellent app framework, it lacks many of the qualities of CSS frameworks. So anyone, who would want to migrate other projects based on Bootstrap or using Bootstrap, will hit a wall because in Quasar there are no full CSS reset and no full support for other layouts than app ones and in context of CSS migration there are new and replaced CSS classes from 0.17 (and those new classes appear to be extremely “responsive” so in example on 4K screen you will end with some strange proportions). In Quasar implementation of CSS/flex, even setting up a proper simple (responsive) block with left section of header, paragraph,bullet list and right section with responsive image (from svg), is quite non trivial even for experienced developers. Maybe there should be ready components for this (in 0.17 there was a jumbotron as a way to make some typical page blocks - maybe it is a idea for a new extension with visual page blocks)? What I’m thinking about is a way for easy migration of 1000s of “html templates”, from bootstrap to a new quasar. If your old project is based on your own CSS/typography, you will have to change that fundamentally. Right now with V1 it is not easy. It is hard. If one would want to create just a “webpage for my blog or product” with quasar, which should look just nice as a typical bootstrap free template, then one would need to create many of his own css classes and style conventions (for example a typical solution in Q1 is to use own flex-grow, which one will just must to employ in his own user CSS classes). There are tons of interactive css flex tutorials, the good ones even give some playgrounds:
  https://demos.scotch.io/visual-guide-to-css3-flexbox-flexbox-playground/demos/

• the new app QLayout in 1.0 is somewhat different from 0.17 so if you have an app, where lured by new possibilities you would want to “upgrade” to responsive/mobile/ultra wide/4K app layouts, you will need to reevaluate your old “app screen space” or “UX mechanics” (in example - scrolling/scrollbars) and use a new flex, even at component level (as in every visual component in your new app - row, col wrappers). And you will have some CSS problems in example with responsive typography. In overall It is good and it is wise to use flex. It is awesome that Quasar allows this and encourages it on every level, but - in context of migration it could end with a whole new app compared to what spaghetti one had in 0.17. Let me repeat, the migration could end with a costly rewrite of an app but this rewrite will result with awesome and clean app. For me it is an exciting possibility but for someone else it could be different.

• there are many totally new components or component options, so when one expects a simple “copy/paste” migration of an old project it is rather unrealistic. Q1 is a new framework and is just beautiful from a developer point of view. Just enjoy this beauty when you will pull your hairs trying to figure out why those buttons/tabs/methods/properties are different. At the end you will be happy. Trust me

• as for V1 production quality there are still two non-trivial, and possibly breaking concepts. The first one is keyboard navigation. Some components are using a notion of “selected” item. For example QTree. And this selected item is even visually different from other “not selected” items. But there is no support for moving selection to next item or previous items and in consequence, there is no possibility to implement keyboard navigation on single component or at the layout level between many components on currently visible QLayout. Because it is fundamental decision (about keyboard processing) it could result in some breaking changes when Quasar will decide to add support for keyboard in the future. The possible solution could be some global event handler (blah), some additional component properties/attributes/methods (preferred), maybe even Vuex integration (wow).

• the second one decision which could result in future compatibility changes is drag’n’drop. From the framework point of view, visual implementation should be left to developer libraries, which are many. But we are living in the context of Vue, observables and reactive environment, so any change in visuals should not be fired by events or user interaction, but by reactive change to underlying data models. From my (developer) point of view, drag and drop as a concept, should be available to EVERY (almost) Quasar component as a properties/methods/slots/functionality because every Quasar component is linked to a specific data model and this component just knows what data model it needs. The rest of visual implementation of dragging or another quirks should be left to developer (in example what to accept or when to copy and when to move) but as a simple slots in main Layout component or even other way. The visual act of drag and drop needs to change an order or content of the underlying items in component data structures. It is also an another architectural problem, where Quasar will need to decide in the future, how it envisions the communication and interaction between components. If this decision will not be made in V1 then it will inevitably be made in the future and it will break all the V1 code just as V1 broke the 0.17. I’m afraid that this break will be bigger, because migration from 0.17 to V1 doesn’t break any kind of back-end API/solutions, but changes in data model architecture will need some changes in backend API/solutions. Of course it will be good and superb, and I have no problem to just wait for V1 another couple of months and let those three problems (keep-alive, keyboard, drag-drop) will be solved at the architecture level. V1 is worth to wait for. Quasar is not just another javascript framework. It is a way of thinking, way of working and way of having fun with web development.

[s.molinari]

FYI @qyloxe - keep-alive is coming to beta-22.

Scott

[rstoenescu]

@qyloxe Thank you for the nice words. First, I’d like to thank you on your feedback! It is very important for me to know how developers perceive the product (Quasar) and what are the pain points. But want to avoid some misleadings if you’ll allow me, so please don’t take the following as an attack because it isn’t my intention. We are all here to make web development better!

• I’ve just pushed a new Boolean prop (keep-alive) for QCarousel/QTabPanels/QStepper (available in future beta.22). Simply saying “Quasar doesn’t works with keep-alive” is misleading. Someone reading that may say: “Oh, so I can’t use <keep-alive> anywhere in my app if I use Quasar?”. It was those three components’ content that didn’t work as you might have imagined with the <keep-alive> native Vue component. But the reason is pretty solid and Vue doesn’t makes life easier either. Regardless, you can now specify keep-alive Boolean prop on QCarousel/QTabPanels/QStepper and it will simply work. It would be nice to spread the word on this update with the folks that you talked with already, otherwise this is yet again one of those things that will “stick” no matter my efforts

• no CSS reset --> not actually true: https://github.com/quasarframework/quasar/blob/dev/ui/src/css/normalize.styl

• The idea that you are forced to use Quasar’s QLayout has been hanging for too long and on too many people’s radar. It must go away. It’s not true. It’s there as a helper, as all the other components. You use it along with QDrawer/QHeader/QFooter/QPage/QPageSticky/etc OR you write your own custom pages/layouts. Quasar is about freedom, not about forcing QLayout on developers.

• Regarding keyboard navigation: almost all components are configured with Accessibility in mind and use the “native” TAB / SHIFT+TAB combo for navigation. This includes QTree.

Again, apologies if this sounds in any way “too rough”. My intention is only to clarify some ideas. I’m a bit exhausted from today’s workload.
Looking forward to more feedback!

Cheers,
Razvan Stoenescu

[qyloxe]

@rstoenescu
Hello, thanks for your time, I’m feeling that I’m taking too many of it lately. Firstly there’s no attack/defense or any other military/combat situation. Everything here is in the faith that it will make Quasar better. IMHO of course ha ha. Oh, and you said “more feedback” - so MORE it is

• I’m in awe of how fast and decisively you solved this keep-alive situation. Thank you! Yes, those compound components needs special case with boolean flag, and it’s true, that even on Vue side, keep-alive is very weird component (from developers of Vue point of view in their words). Anyway without it, many, many real-life use cases would be impossible. Another argument is that keep-alive allows designers (those who deal with html/css) to make decisions, which in traditional situations had to be resolved by developers (those who deal with html/css and all the rest - js, webpack, server side etc.). Making keep-alive possible at html level, reduces time costly channel of communication between designers and developers.

• Well, my response was of course in context of previous posters, who as I understood wanted to put their V1 migrations into production right now. I totally agree with @somascope, that (essentially) if you know what you are doing than it might be ok, but for some (me…) the migration had some conclusions, and I wanted to share them. In the hope, that maybe it could help somebody, who has a similar 0.17 app (not website).

• Considering the above, you are totally right that if anyone could read that wrongly as “don’t use V1” then in reality somebody will - and it is bad. Yeah, I’m sorry if it was unclear - I’ll clarify here: impossibility of migration of non-trivial 0.17 projects to V1 because of keep-alive, referred only to V1 version as for the time of writing my previous answer. Now, the solution is available and in regarding to “keep-alive” everything is possible. And I was totally sure, that it will be, when the V1 will get out from beta.

• CSS/Bootstrap and Quasar. Well, now we are talking about strategy (using those military terms - it is actually good, because it is different level than talking tactics in the context of framework). Yes, there is a concept of app framework and css framework. As for now, Quasar is an excellent app framework with css elements and bootstrap is an excellent css framework with app elements. You are very wisely steering Quasar into the direction of css framework, because people need their own web designs and those need designers and designers need simplicity, excellent tooling, society of other designers and … tons of examples. Without that no designer would want to move his hard earned bootstrap skills to yet another css framework. Some history. At the time of bootstrap incarnation it was one of many css frameworks. But somehow it prevailed and made its way to the whole internet. One of the crucial point of that domination was a simple tool, simple website called bootsnipp:
  https://bootsnipp.com/
  What is it? cite: “Bootsnipp is an element gallery for web designers and web developers, anybody using Bootstrap will find this website essential in their craft.”. And it really was - anybody could took some blocks from bootsnipp and made his own, almost beautiful website. And when you have snippets (of building blocks), only then, you can have full houses from those blocks - full website templates. Now, there are thousands of free or commercial bootstrap templates because of this. Possibility to use a website template as a commodity created a market. And market created the need for developers and so we have a full cycle. Without market there is no global reach.
  As for now, you want (and me too) to put Quasar in the css frameworks market. Strategically it is not feasible to create something totally different from existing market. You only need something better, not too much different. As for now, migration of single bootstrap snippet or whole bootstrap template to Quasar css is extremely hard. I know, because I tried that and at the beginning, lured by those col-x classes I wanted to create an online converter from bootstrap code to quasar code. But it was impossible, because devils laid in the details (many of them).
  There is a solution to this situation - if you could only steer your css framework in a way, where it would be possible to easy automatically convert existing templates/snippets, than you could acquire (in V1 phase) many, many designers from the bootstrap realm (lured by your app superiority and developer feelings about Quasar - it is important). And then, if you really want, and when you will have big traction, then you could drastically change your css framework in V2/V3. Without people it is hard to generate your own energy to grow something. And Quasar is excellent but it growed so big that it could starve of that energy. What I’m saying is that css framework is big and nasty and dirty, that there is no strategically valid point in reinventing it (in the context of websites - not in the context of apps, qlayouts, qpages etc.).

• Keyboard - this is VERY (in the sense EXTREMELY) important subject. Many frameworks ignore this aspect of development and those framework won’t reach the level of bigger, universal environments. Why?

• Firstly lets define of what we are talking about. I’m saying about interactive apps, where user is not only presented with detailed or aggregated information but she has to input complex, interlinked forms from source data or change existing data periodically. It means - almost every business app.

• Accessibility is of course important but paradoxically not from the point of view of end user (in the context of app framework). There are laws in Europe, where if you want to offer an app solution in the government contract, that app needs support for accessibility. So without accessibility you will not have Quasar apps in public sector because those apps would not meet the specifications of public offerings. In public sector at the phase of choosing the solution, they could be tested for conformance to WCAG 2.0 AA in tools like this:
  http://wave.webaim.org/
  https://achecker.ca/checker/index.php
  As for, now this V1 Quasar page:
  https://v1.quasar-framework.org/introduction-to-quasar
  Results in many errors and warnings.

• Internationalization and localization are another terms linked to keyboard. Why? Because keystrokes has cultural or historical meaning. If you have complex form there is a different expectation of moving to another field in Germany and in Russia or USA. In one environment user would expect to press enter and move to another field (not submit the whole form) in another, the user wants to use arrow down or tab. In one environment one expects to move to next page in QTable with page down in another with right arrow. What that means for Quasar? That you need a support for keymapping and every interactive component should have a concept of “selection”, “move next” ,“next page”, “next sibling”, “move to parent”, “select all”, “copy”, “paste”, “cut”, “undo” etc. And those behaviours should be mapped to specific keystrokes. And those mappings should be allowed to change at runtime. BTW - in QTree you have something ingenious - strategies (as in tick strategy). There should be similar keyboard strategies in interactive Quasar components (and global keymapping).

• UX as in user experience. There is no possibility of efficient data input, when you have to type on keyboard and then use a mouse to navigate between complex form elements. It just won’t work in business environment and without it, you will not have a business market.

• App development - keyboard navigation, selection, action firing, switching between app parts is crucial for development of bigger apps. Why? Because we, developer have many tools for automated testing of code, but we have only limited tools to actually testing the UI impact of code changes. It is not possible in bigger app, to manually check every form or view before deploying to production. If you need to manually check your UI than you can not even think about automation, continouus delivery etc. You need to have a possibility of automated tests of your UI. There are solutions for that, in example this is nice one:
  https://devexpress.github.io/testcafe/
  With those tools, possibility of keyboard automation simplifies construction of UI tests and in result you can have bigger test coverage. Without automated UI tests you rather will not reach with Quasar to developers of corporate apps.

• App automation - there is a concept of headless browser:
  https://en.wikipedia.org/wiki/Headless_browser
  In some apps it is used to script them, or allows automated data entry in closed apps or even makes screen dumps or scrapes data. Proper keyobard navigation and data entry opens a whole second market for external tools for another apps. It is important, because you are allowing Quasar developers to make their own app niches.

• Drag’n’drop - why it should be somewhat resolved at component level? Because component have slots, and there could be slots designed specifically to DND. How? In QTable, the default row drag behaviour is to visually drag the whole DOM TR element. It is ugly. One would want to have a slot, where during dragging, the dragged element would be presented as a DIV with data from first column only. And why and why DND is so importand? Because in some markets 80-90% of app users are mobile users. They have no mouse so how should they interact with compound elements (QTree, QList, QTable etc.) on their touch screens? It is crucial, if you want to put Quasar on mobile market.

• Why putting keyboard and DND could be beneficial in V1 in spite of prolonged wait for release? Well, V1 is a big update. The older developers with 0.17 solutions would have to change their apps regardless. But the key is an access to new developers! If you want a traction and big impact, than it would be better to make a BIG V1 release and let the developers update what already is in Quasar by their pull requests, than lure them to V1 and then repeat the process in V2, where they would be expected to greatly change their apps because of keyboard strategies and DND support. It’is easier for developers (as an engineers) to tweak with your code and improve gradually than jump a big step every year or two. There is an evaluation, where the recompilation of 18 months old codebase is almost impossible for a standard developer.

• Why DND support and keyboard should be implemented in unison? Because this will change the communication methods between components in Quasar. They are, as for now, only beautiful visually but not fully interactive. For them to be interactive they need to talk to each other (for example by verbs “copy”, “cut”, “drop”, or events, or bus, or VueX etc.). And you will have to make decision (exciting) how? It will make a Quasar an “opinionated” framework, which is good because you have a very good “opinions”. Your work is beautiful and on the another level, so I’m sure, that whatever you choose, will be good.

• “Opinionated framework” - lets strategize even further. This post is such awfully long, that I lost any scruples and will make it even longer

• You have already “opinionated framework” because you have chosen webpack, electron, cordova and now you’re pushing for yarn. It is great. So when you have such a great opinion about tooling, you are entitled to have an opinion about development process of this framework. This include of course not only component interaction but also - in the future I assume - data persistence and communication.

• In case of data persistence, the crucial is data querying and synchronization. In regard to data querying you have something similar already - in QTable there is a column sort, local paging and filtering. I have no doubts, that this functionality will be in the future put into web workers, which could benefit 100-300 times faster in query/speed speed in comparison to main browser thread. There are some libraries which do it (web worker queries) already but the real question is how this will be integrated with VueX? In regard to VueX it is a very interesting concept of normalization of nested data. There is this library:
  https://github.com/vuex-orm/vuex-orm
  Which IMHO does this right but there’s no web worker support (yet). It is interesting library, because it allows to properly set (properly as in set an observable) nested objects in VueX and it has a very interesting concept of data synchronization, where you could just respond to changes in data and easily persist them locally or send them to the server (or peer) by request or even websocket or WebRTC.

• In case of communication, you have choosen to write your own communication layer in your QUploader but you have non obligatory suggestions in examples/docs to choose Axios. This is good IMHO. In the future, I think there will be your “opinion” to put this Axios as a communication layer, but not in a simple mode of “lets just everybody uses Axios”, but in one interesting option - let developers use Axios communication but in web workers. And probably, what you will implement into Quasar, will be a web workers support for any developer code and Axios will be just your “opinion” again. The possibility of support for web workers (as an component or a newly concept of app extensions) would be a “killer” argument for many developers of business apps. Web workers are the best option to offload cpu intensive tasks from javascript main browser thread.

• Let’s strategize more. What could happen if you will have such a marvelous framework? Well, it will be the BEST web platform in the world Historically there will be two scenarios:

• In scenario one, you will be approached by somebody who would want to “consume” your solution as you have “consumed” cordova and electron. There is a possibility that .NET 5 in 2020 would want to use Quasar as their frontend, or Oracle or IBM or something else. I do not know, who, but Quasar as an app platform would be interesting to have as a little part of a bigger programming platform. Would it be wise to link quasar to one platform? Probably not to one, but if it could be possible to externalize Quasar platform from programming/backend/execution platform and use Quasar in at least two of them, then you will win globally. How would you externalize the backend? By not linking Quasar with specific app platforms but with API gateways. You have already similar concept in quasar.conf by using WebPack devServer.proxy. This proxy in development mode is the same as actual reverse proxy in production mode. BUT in the future, all this will be handled by API Gateways, where security, authorization, authentication, CORS, webservices, load balancing, cache will be managed in one place. If you integrate Quasar with such a beast as an API Gateway, you will be safe from “consumption” by specific App Platforms. They are afraid, that they will be consumed by those API Gateways in the future BTW.

• In scenario two - on the other side of programming life, you will be approached by something like existing (or new) IDE platform which would want to use Quasar as its target development environment. There are rumors, that Eclipse is destroyed by Oracle, there are plans to put Visual Studio Code online, there are many collaboration platforms for single developers or communities like JSFidlle, CodePen, there are traditional IDE’s like NetBeans which could go online anytime. In this scenario you will have an opportunity to create a global developer experience but at the cost of your “opinions”. Of course, there is one interesting part - if this global IDE solution would want to base its mechanics on Quasar - that would be ideal. Imagine, that something like JSFiddle or CodePen or even full blown Web IDE is using Quasar. There are some interesting WebIDE’s already, but none of them IMHO has that something (Quasar ha ha). Online development is unfortunately the future of development for many developers and the market will be huge.

OK, I’m little tired so I stop now. Cheers Razvan, I’m so happy that you’re on this world.