This code is easy to read and understand and refactoring it with a callback seems as premature optimization which does bring own flavor to it. In other words, this is a good example when perfect is the enemy of the good.
For simple things we still have Excel and Ms Access where people continue to build simple UIs for personal use. At my previous job, our CFO build own framework (Excel) to manage and automate financial reports (which makes him a full-stack developer based on industry standards)
I guess the frustration comes from the fact that historically Web started as a set of static HTML files to create/publish documents and we inertially compare todays Web with it but we if stop comparing apples with oranges than it becomes apparent that:
1. It's never been simpler to create and publish web content
2. It's never been simpler to build/ship/and distribute software
Complexity arises when people (given many options) pick wrong tool for a job.
I do not think that you would be able to do ActiveX, COM, OLE, MFC, C++ after 2 weeks of bootcamp. Yes, Delphi and Visual Basic simplified many of it but there were still many challenges to develop and ship your software. Just shipping alone and dealing with installers was a challenge by itself. Now compare it with a browser tab and a single click that deploys your code across the globe so it event can run in space on ISS.
Browser capabilities exploded dramatically as well as hardware, this is why we have Figma and virtual machines running in the browser. So the answer to this question seems obvious to me. It would be odd if UI complexity stayed the same.
It looks like Material UI has its own implementation of styled-system which is great! They should have started with something like that from the start :-)
> What I am talking about is overriding styles by the user of the component.
Please take a look at theme spec where variants become part of your theme object. You use theme.js to provide custom variants to components. This is how you would let users to customize your components via well defined expressed API (typed with TS if you want) :-)
> One way to do it is through the ThemeProvider. But that does so globally.
You can have as many nested ThemeProviders as you want. This is not a hacky way but is the way if for some reason it's not enough for you to have 1 global theme object.
Material UI is great for what it does (implements said kind of design) but if material design is not what you want then using this library with its own layers of abstraction is a no go to me.
Please take a look at styled-system and proposed theme specification with variants. This is how you would expose your inner components for custom styling.
> Material UI uses a very similar theming system. The interface of the theme itself is different, but that seems to be about it there.
Material UI implements Material UI by default and this is the main reason why it's hard to customize. Too much to change. I guess this is one of the reasons why there are not that many custom themes available for this library.
Once webassembly becomes a thing, we can leave the web to the documents and migrate all the apps to the bytecode. That should bring peace to many HTML designers.
> nah. what about theming? you cannot do that with inline styles.
Nobody is utilizing inline styles in that example. It _looks_ like inline styles but it not. It generates css class name behind the hood which you can override in multiple ways. Starting from the ThemeProvider or just like this:
css was designed to style HTML documents. It was never designed to build rich and scallable apps thus we have all these libraries which fixes a lot of underlining problems.
I am a big fan of styled-system and glad that more frameworks are utilizing it. This is something that helps a lot when building desktop-alike apps for the web.
you mean the days when most software had to be manually installed on your Windows? :-)
Yeah, web is not only about documents these days (how it was originally intended) but it is also about running and hosting real-time applications.
But I hear you, people indeed use wrong technology to solve their problems. I agree that there is no need to use any React and Angular to display a document.
> As an experienced front-end developer I must say that I don't really understand why the complexity of building websites is growing instead of going down.
Complexity of building dynamic documents is actually going down. If you are to build a typical web site from 200x using modern browsers, you wont need jquery or anything like that. Networking, security - everything became 100 times easier and faster.
But if you want to build a desktop application using DOM as a rendering layer, then it is a different story.
There are plenty of apps out there where you cannot apply HTML document semantics or that would be a waste of time (money) doing so.
If using canvas or web-assembly would be easier/possible than using HTML tags for a rendering layer, nobody would ever disturb the HTML document designers with this div "soup" :)
Semantic HTML serves 2 purposes: lets search engines correctly index your content and makes it easier for a human to edit this HTML directly. Other than that, there is no other reason which requires semantic HTML.
True accessibility is achieved through other means.
> I’m a ‘frontend of the frontend’ kind of guy. My expertise is in HTML and CSS,
There are 2 different things: documents and applications. These days you can find IDEs running in the browsers, excel spreadsheets, terminals and all other things which are not HTML documents. Yes, you cannot use <ul/> </li> to style an output of terminal `$ tree ` command. This is why you see <div/> soup when you examine HTML of the web terminal output.
As web-assembly becomes more mature, I expect developers to abandoned the HTML/CSS scene and leave it to HTML document template designers so there again can be a clear understanding when you have to use HTML.
It feels like google web-devs/disigners should start looking at the native apps to get an idea of what the user expectations for the web-app are going to be. If we look at microsoft web outlook, it is gradually becoming like its native counterpart (which is the best desktop email client on my opinion). They didn't have a good web expertise like google so it was too sluggish at the begning but it's getting better. If webassemply becomes a thing, MS will have a good chance to bring its dominance to the field of web apps.
What's interesting is that I remember how devs and designers were frustrated when they were asked to build a web version of their desktop apps finding it too hard to fit into new constrains. Now, I wont be surprised if web-devs/designers feel frustrated too trying to build a desktop app with a mental model of HTML documents and page reloads which is what the new gmail UX looks like to me (the old one was not better, I just got used to it).
If it was up to me, I would focus only on performance and accessibility. I would cut all animations and use much simpler (bare text if needed) ways to present information. Today when you can be fast on web, no need to compensate lack of it with too much content and animations.
To me this attributes more towards general evolution of the browsers which naturally leads to more complex requirements for the modern web-app. I remember that in 2010, when we started re-writing our desktop apps during our transition to web, the initial requirements were such that it was still possible (although very hacky) to use the latest version of ASP.NET.
Then 6 months later we received a new set of requirements which rendered this _latest_ stack useless. We literally had people sleeping under the desks pulling all-nighters trying to transfer a session state between browser and server without dropping an egg. That's was around time when backbone.js came out.
If we compare the things that browsers can do _now_ with what was possible 5y or 10y ago, no wonder why we have so many new frameworks.
Browsers are trying to catch up with (or even replace) an OS as a main container for running an application and because it's hard to release all features _at once_ without agreeing on standards, we have a situation when people have to choose a new library each time a new major API/feature is available. And this what I see is the main reason why `front-end development is so unstable`
WebAsm is coming which will again lead to yet another huge re-write.