The dev team has been discussing some changes that we would like to see in future UserFrosting releases.
Some of these are funnelling down into fully backwards compatible updates, like the planned expansions to the bakery CLI tool. However there has also been discussion of features that cannot be introduced in a backwards compatible way, and in extreme cases, will completely change how a particular aspect of UserFrosting is works.
As such I am creating this topic to keep the community in the loop (and to prevent ideas from lost to the RC chat history).
As of posting we have;
Webpack for asset bundling.
This has been in discussion for awhile now. Its going to be hard to implement, drastically change how the frontend is developed, and if we are going to play to its strengths, require a complete redevelopment of just about every front end component. The stakes are high for this one, but a successful implementation will greatly improve the front end development experience.
A virtual DOM.
Made popular by Facebook’s React, using a virtual DOM greatly reduces the processing required for scripts to manipulate the webpage. This means code runs faster, and the user has less chances of browser hangs. However JS libraries that have a virtual DOM are in fact a full, deeply intertwined framework, as is the case of React. And in the case of React, even if we got the virtual DOM code out of it, we would be at the mercy of React’s license. As a Facebook product, it understandably does not permit its use in creating a social network. There are however alternatives such as Preact which (presumably) don’t have that same license clause, and lack the full scale framework part, making it very well suited to a PHP backed web app. (Preact also supports JSX language, a clean JS and HTML fusion that would eliminate the need for alternative, and more restrictive templating libraries). Like webpack, this will drastically change things, but isn’t ultimately dependent on it (it would just benefit immensely).
Our own Resource Locator library.
Currently UF uses RocketTheme’s ‘Toolbox’ library which has a special Universal Resource Locator class. This is the class that allows access to various files via schemes such as
assets://path/to/style.css. While an extremely useful tool, it does have some major flaws. A big one is the lack of documentation, another is that the stock interface lacks many of the methods that would benefit the tools various use cases, leaving us with code bloat to handle the shortfalls and ultimately trapped with the library despite the fact is has a reusable interface. There are plans to ditch the RocketTheme implementation as much as possible in the short term (in a BC way), but in the long run we want to remove the dependency entirely.