(moved to dev@ list, context is cleaned up) On Sun, 7 Mar 2021 at 02:36, [email protected] <[email protected]> wrote:
> We should use that opportunity to also update the Dev options on how to run > the JavaScript compile using NPM > IMO this should be obvious :) > And update: > > https://openmeetings.apache.org/BuildInstructions.html#update-javascript-and-css-at-runtime > > It's up to you, this is something I'm not using > There are btw also some really good plugins to compile CSS files. And > enable usage of Sass https://sass-lang.com/ > > I don't see benefits of moving to sass ATM such move will be invisible to end user it will introduce new bugs ** I expect it would be harder to find "what need to be changed" i.e. currently I copy/paste existing CSS selector and can jump to the place it is defined it will be much harder in case of SASS .... > *I'm afraid these 4 front-end artifacts might need to be packed as one > HUGE js file* > => Please don't do that. It is a really good approach to split a website > into multiple smaller JS files so you can work on those independently: > > https://martinfowler.com/articles/micro-frontends.html?utm_source=arador.com > > TL;DR; recently I moved browser detection to OmUtil it was small refactoring unfortunately the size of our JS files has grown a lot :( this is because right now we have same browser detection library and all its dependencies in 2 "js modules" this js module separation produces smaller JS files BUT - now we can't use compiler (due to we can't specify "dependencies" for our modules) - and the code "accidentally" grows due to duplicate dependencies The only way I see to address above: to create huge JS :((( > We do *NOT* want to built yet another monolithic front end: > > https://xebia.com/blog/the-monolithic-frontend-in-the-microservices-architecture/ > > I would rather like to see more code stripped into separated JS files out > of Apache Wicket. If we need to share code between js files, let's build a > node/npm module! > lots of small files will decrease performance and compiler will not be your friend .... > > This will be also a great way to externalise common functionality and share > it via: npmjs.com. > Somebody for instance already built a NodeJS library to integrate with the > Rest service: https://www.npmjs.com/search?q=keywords:openmeetings > But some more front end related libraries would be great! And a great way > to have front end developers being more excited about working with > OpenMeetings! > > Also this would enable much easier to customise openmeetings on the Front > End side by enabling a more modular design. > > Thanks > Seb > > Sebastian Wagner > Director Arrakeen Solutions, OM-Hosting.com > http://arrakeen-solutions.co.nz/ > https://om-hosting.com - Cloud & Server Hosting for HTML5 > Video-Conferencing OpenMeetings > < > https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url > > > < > https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url > > > > > On Sat, 6 Mar 2021 at 17:11, Maxim Solodovnik <[email protected]> > wrote: > > > Maybe you are right :) > > I'm not very good at blogging :) > > > > I'm afraid these 4 front-end artifacts might need to be packed as one > HUGE > > js file :( > > but this definitely should be other discussion :)) > > > -- Best regards, Maxim
