Thanks @Alfhir I wasn’t aware of these findings. To my perspective, it’s not that bad, the worst is Ms Edge and that soon will be replaced by Chromium based, the other ones having problems seem quite old browsers which I don’t really care about. Also it seems that after doing google search on the Angular side, the order of all scripts matters and might fix some of these browsers not working in the findings.
I’ll be honest: I was never all that excited for Aurelia UX. I think it was overly ambitious and didn’t stand to offer much value over the wealth of existing component libraries that all work great with Aurelia. I think that truly great component libraries are also UI/UX systems with a significant amount of study behind them (stuff like Fluent, Ant, or Material Design) AND/OR a huge boon to developer cleanliness and productivity (Semantic UI).
I think the Aurelia team specializes in making developers productive. This might seem like a perfect fit for option #2 but let me propose an alternative after a brief story:
A while after writing off Aurelia UX I came across Microsoft’s Office UI Framework component library for React. Since my portfolio pays homage to Windows 8 (http://joshdovishaw.com), having access to Microsoft approved styles was a dream. For the first batch I mostly just used the components as a reference to style my own so I could get my portfolio out the door but after that I began tinkering with an Aurelia port of the React components. This would be my first open source component library so I looked to other projects for guidance. After a deep dive into the many Aurelia ports of Material and Bootstrap I decided to take a peek into Aurelia UX. I liked what I saw, not the components themselves, but the elegant way in which many of the problems with component library flexibility were approached. I ended up using a subtle variation of UX’s theme system: https://github.com/CuddleBunny/aurelia-office-ui-fabric/tree/master/src/core.
I believe that the Aurelia team’s superpowers could be best applied in the UI/UX space by building a series of smaller libraries (like this theme system) and documenting a handful of patterns (like using Lerna) which directly support other component library authors. By creating an ecosystem instead of “Just Another Component Library ™” I believe we can cultivate a wide variety of high quality Aurelia libraries rather than a collection of React/jQuery ports.
If you’re even considering using this feature, aren’t you doing so because you’re worried about these edge cases though?
Yes and No, most of the Apps I do are for Enterprise and the only edge case that would concern me, would be the Ms Edge but apparently they found a way to make it work. Why I mentioned this Differential Loading is mostly because of the much smaller bundle size that you get at the end of it since we can target ES2015
which I find is a big deal.
Hi CuddleBunny,
I understand why you have to port libraries that rely on jQuery for React or any other framework that uses a vDom, but why are ports needed for Aurelia, say for example “Aurelia-Semantic-UI” - what would such a port improve?
Most of them are wrappers basically.
jQuery and everything based on it rely heavily on document.onready event, in which they run all the code to turn static html into dynamic components. That pattern, of course, assumes that by the time document.onready is fired, all static html has been loaded.
That pattern doesn’t work well with client rendering, where html is manipulated all the time. These wrappers, which apply to not only Aurelia but also Angular, Vue, etc., conveniently hook into the attached and detached events of components and run the equivalent document.onready code. The wrappers also provide other convenience like adding the correct classname and abstract semantic html from framework specific html, but that’s just icing on the cake.
I see, thank you very much!