Smalltalk expert having questions related to Vue components

[JosefRosenberger]

Hello all,

I am not (yet) a user of Vue but I'm having a couple of questions, which came up when studying the Vue documentation.

A few words on my background and methodology:

Extremely experienced OOD software architect and lead developer since 1987 (yes, true), first nightmarish in Objective-C, for the last 30 years only in Smalltalk.

I am looking for a UI library, which I can use as low-level tool below my Smalltalk framework having over 10.000 application classes and around 200.000 methods to create complex, appealing and dynamic UIs in the browser.

What I'm missing in the Vue documentation is a detailed listing of all the claimed 140 UI components and their attributes (instance vars). There are just a few examples but no complete list of all and no listing of the UI attributes or examples how they can be initialized.

All UI systems, which I had used or played with in the past (2 x in Smalltalk, Gtk, Sencha EXT JS, which I used for a running prototype) had standardized UI components, widgets, buttons, selection lists, containers and so forth, which were used to assemble a comprehensive UI.

Where are ALL Vue components listed and explained in detail?

I look at the UI totally the OOD way. All possible settings of my UI (currently in Smalltalk) come from various types of descriptors, which exist for all important entities, especially for classes (this includes all DB table settings), attributes (instVars), which includes all lower-level values, also for forms, panes, views and more. I call this "data-driven programming" and I have practiced and enhanced this step-by-step since 1987.

Is it possible to initialize and standardize Vue components this way? In my former Sencha prototype this was quite well possible, but I do not trust this company as they have screwed their customers several times in the past.

I ALSO DO NOT WANT to construct UI components individually one-by-one in this extremely primitive JS "IDE", which I find appalling - and nobody should judge this statement who has no clue of what Smalltalk has been offering since it's first version in 1980!

There exists meanwhile a clever tools to translate Smalltalk code into JavaScript, so that I intend to have my extremely comprehensive and highly productive Smalltalk framework generate (almost?) all of my UI definitions for the browser from Smalltalk definitions in higher abstraction levels similar to what I have achieved for the current Smalltalk UI for the desk-top.

Thank you in advance for your constructive comments

[skirtles-code]

Vue is a lower-level framework, used to write and combine components. It only provides a very small number of components itself (e.g Transition, KeepAlive).

I'm not sure where you read the number of 140 UI components. Vue itself doesn't provide that.

There are several component libraries available, written on top of Vue, that should give you what you're looking for. You can find more information about them at:

• https://vue-land.github.io/faq/component-library

[JosefRosenberger]

Dear readers,

@skirtles-code
Thank you very much for your comment, which had an disillusion impact on me - and that was what I had needed.

@ToAllReaders
Over the last days I read into various so-called "component libraries" but I found none where the following mandatory information was documented:

• A complete list of all available components at least with a short description of their purposes
• A class tree with all components showing the inheritance structure
• A detailed description of all the attributes per class (or call it: instance variables or settings) and their inheritance

Code without this vital information is basically useless, in any case amateurish and therefore worthless. Such docs were quite well done in my earlier encounter with EXT JS several years ago.

I cannot understand how people waste their time by trying to use undocumented code. This gravely violates the first commandment of software development: "Thou shall document thy code clearly BEFORE writing it!"

The unavoidable punishment for ignoring this rule is "life in hell of code chaos"!

Just as a side remark to those geniuses who believe to know better (the old and wise German language has the saying "glauben heißt nicht wissen" - to believe is not to know):

Over my more than four decades in software development I had around 150 programmers working under my leadership. All my projects came to life.

Most of them were ignoring this first commandment when they started to work with me but after educating them for some while the great majority understood that this is indisputable and they changed their behaviour.

I got rid of the small rest very quickly.

Nevertheless, this was my first encounter with open source libraries, it was an interesting experience but I shall not waste my time trying to use such projects.

Shortsighted savings in quality or documentation almost always pay back far more dearly in mid-range terms.

(I wrote the above for those few who are clever enough to learn from more experienced colleagues! The others need it "the hard way". Good luck!)

[skirtles-code]

I am also a former ExtJS user, so I know the docs you mentioned well.

But I'm confused about your claim that Vue-based component libraries don't have the information you need.

• A class tree with all components showing the inheritance structure

Vue components don't use classes and aren't built using inheritance, so this doesn't apply. They use composition for reuse instead. The docs won't show you this kind of information because it doesn't exist.

• A complete list of all available components at least with a short description of their purposes
• A detailed description of all the attributes per class (or call it: instance variables or settings) and their inheritance

Picking a popular library at random, Nuxt UI:

• https://ui.nuxt.com/components - A list of the available components, with a short description of their purpose. Exactly what you asked for.
• https://ui.nuxt.com/components/alert - The docs for a specific component, including examples and the API (at the bottom of the page, with sections for props, slots and emits). In the context of Vue components, these are the 'settings' you need.

Here's another library, Quasar:

• https://quasar.dev/components - Component overview.
• https://quasar.dev/vue-components/avatar - Examples and API details for a specific component.

You'll find something similar for all the popular Vue-based component libraries. Vuetify, PrimeVue, Element Plus, etc. Detailed docs with examples and API listings for every component.

[JosefRosenberger]

Thank you very much indeed for your reply. I will give it another try, although this statement:

"Vue components don't use classes and aren't built using inheritance, so this doesn't apply."

confuses my insofar as I cannot imagine why and how this is the case and I currently would only see great and many disadvantages. But one never stops learning and perhaps this will be such a case for me.

Still I ask myself what are the reasons for such a strange decision? And: Shouldn't that rather turn me off even more?

I will later come back later with what I found out.

Some more important side-remarks on what influences me strongly and that will also show that my decision will be influenced by several more factors:

1. There are a few preconditions for my decision how to proceed:
   a) My small but very professional team and I do not want to mess with stone-age JS tools to write low-level code.
   b) We want to deal with JavaScript as little as possible - and ideally not at all (if possible and see below).
   c) The same applies to html.
   d) We want to preserve and re-use as much of our tools and descriptors and pure OOD concepts as possible and ideally use all of them for future projects in the browser as the one and ONLY source for code and data.

2. I must first get into the details of the Smalltalk to JS translation tool and, if and where needed, improve and/or modify it and gain some experiences and interface this to my classes, which generate the current Smalltalk UI interface. I want to build a small prototype. In case that this works well, it should be a feasible solution to proceed.

From my current state of knowledge, I would prefer to translate / convert my currently used GUI classes from Smalltalk to JavaScript in order to construct my own UI framework, which would then be as tightly coupled with all existing descriptors, models etc as today's Smalltalk UI. I tend to doubt that this will be much more work than getting into a totally different third-party and "class less" framework.

3. The UI library of Smalltalk consists of around 800 to 1.200 GUI classes, depending on what one classifies as "GUI" but only (estimated) about half of them are in use by my application framework. There are also redundancies created by third parties, i.e. far less are really needed. These classes have been matured over time and consist of their own and quite large class tree and, of course, with plenty of inheritance.

4. And further I would like to re-use the very intensive coupling of my various types of "descriptors" and tools also for the browser based GUI to avoid isolating the browser GUI from the current source of information (i.e. all in Smalltalk), which also includes all the model handling, otherwise I risk to get, at least in major parts, two rather separate "generations" or versions of software and that must be avoided under all circumstances.

5. Further more, we have our own OODBMS under development to finally get rid of these (in my view primitive and) stone-age RDBMS (currently MariaDB) so that we will be no longer forced to "squeeze nice round objects into an ugly square database" - and that is an old "classical" phrase from the 1980-ies, when OOD, Smalltalk & Co were introduced and discussed. This OODBMS will be available at least in major parts in a foreseeable future (only for our own use) and it will free us from all of the many idiotic and stone-age limitations that all RDBMS have and enforce.

This includes already today various tools all under MIT license to serialize and to materialize complex data structures (i.e. real objects build from different classes), which are anyway already described completely by my oldest type of descriptors (since 1987). One of these structures can be sent into the browser "as is" to be materialized by the browser so that all the otherwise needed detours can be completely avoided.

6. I am not a DOM and even less a JavaScript expert but I have been living and breeding for years with this fancy idea to access the DOM directly without any detours such as html and JS although I have lot's of experiences in writing various types of parsers to process stored DOM structures (also highly descriptor driven). This is already currently and more so in the future an essential part of my product and business concepts.

7. Since "the good old days" (not so long ago, till 2016) when we were heavily using IE8 and its COM-interface to construct and more so to also read-out browser contents I have had the idea to completely and entirely skip all this html and JS BS and to access, define, build (fill) and read out the DOM directly.

AFAIK know this would require our own browser, which would have a lot of other advantages and which should be feasible as there are a couple of small teams making their own browser variants. At least for the DotNet world there exists such a solution which tells me that it is feasible.

But, I must admit, that a lot of details will have to be found out and clarified first.

I would very much appreciate comments on these additional concerns, too. Thank you and best regards.