@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.
