Open Stack

Thomas, I think that's something that downstream maintainers will
eventually need to seriously consider and figure out, because any modern
front end service these days will end up being built with npm pieces,
and various js libraries. Horizon is sadly a terrible example of a
'modern' front end service, and it will either need to eventually pivot
to being a JS based front end, or replaced by one.

The mindset of excluding or avoiding npm dependencies will cripple any
attempt at any serious javascript development, and given the modern web
is all JS interfaces, that doesn't particularly bode well for OpenStack
from a visual interface perspective if the mindset is very anti-js. :(

On 21/06/20 9:46 am, Thomas Goirand wrote:
> On 6/19/20 10:03 PM, Mohammed Naser wrote:
>> Hi everyone,
>>
>> I was wondering if anyone in the community has explored the idea of
>> implementing PatternFly inside Horizon.  It seems like it shares a lot
>> of the similar ideas that we use and we could really benefit from using
>> a common library that already exists with a lot of good UX thought
>> behind it.
>>
>> I know it's based on React which is a bit of a leap from where Horizon
>> is today.  However, I'd be curious if the Horizon team is interested in
>> figuring out a plan to make a migration to something like this happen.
>>
>> Personally, I think I would be able to provide resources to have
>> someone do this work.  However, if this seems like a huge stretch and
>> architecture change where it actually makes more sense to stand this up
>> from scratch (and implement an architecture where the dashboard talks
>> directly to the APIs?), perhaps we should explore that.
>>
>> I also would like to hear more from our extended community too, as I
>> think we really need to improve our user interface experience.
>>
>> Thanks,
>> Mohammed
>>
>> -- 
>> Mohammed Naser
>> VEXXHOST, Inc.
> Stuff based on npm are *very* difficult to maintain on downstream
> distributions, because of the way apps are getting dependencies (ie: by
> the 100s of dependencies, each of them having to be packaged separately
> as separate libraries).
>
> So, before considering any solution for the web, please consider the
> amount of work necessary to do the packaging. For example, I would *not*
> have the bandwidth to package 100s of nmp components.
>
> These are just general remarks, I don't know any specifics about this
> particular library (just saw its package.json which is as horrifying
> (from a package maintainer perspective) as any other npm app...).
>
> Cheers,
>
> Thomas Goirand (zigo)
>