UnGUI MainFrame

24 Feb 2022

UnGUI MainFrame

UnGUI MainFrame

UI Frameworks are not simple. In fact, they can be almost as complicated to learn as a new programming language. Given that, why bother to use something like Semantic UI? What does one get in return for the investment of time and frustration?

Semantic UI seemed to be a challenge to learn to say the least. Although quite difficult, I had learned that the framework was indeed more highly capable when used correctly, with a few temporary cons and many pros to implementation of the type of UI within the creation of html/css web design. We had several iterations of practice work of the day sessions with the professor, individually and in pairs, as well as further deep dive sessions with the teacher’s assistant on using Semantic UI. Referring to the Semantic UI guide or examples from the vendor portal, we were able to creatively find ways of constructing the html with the help of the newly learned UI to our advantage whilst still fairly new to html by itself.

As Semantic UI, understandably is such a beast to get right, off the bat, there is indeed a sense of fulfillment that comes when successfully getting the framework to work in conjunction with our html in tandem with css.

Why not just use raw HTML and CSS?

Using raw HTML and CSS is difficult and very outdated, leading towards the accompaniment of solutions such as additional extensions of sorts like semantic UI to make the time it takes to write the code for html and css less in cumbersome, and time straining. Some capability or functionality inherent with semantic UI is quite powerful in nature and could lead to some interesting results, or ramifications if used improperly, in the wrong context of the code, precedence/hierarchy of the initially raw html and css.

Are the software engineering benefits of UI frameworks?

You could essentially tether specifically focused aspects of html along with particular software depending on the feasibility or furthermore the compatibility of the various combinations of the framework, code, and therefore software in line with inevitably even the potential to accommodate the lack of hardware could be deficient. There are many cases where hardware could never replace software, as well as vice-versa to some respect. Even instances where, software would be actually cheaper or less intensive of an approach to lever as opposed to hardware. This is where fully understanding the framework, code, and hardware all together can come in handy when dealing with software engineering and the overall reason of ensuring the software works properly in conjunction with its counterparts altogether.