player2121

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.

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 :-)

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.

https://styled-system.com/variants

you can use it in Chakra or in anything else that supports this spec.

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.

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:

const Footer = styled.div` ${PrimaryButton} { color: red; } `

I strongly suggest to look at https://styled-system.com/ to better understand the mechanics.

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.

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.

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.

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.

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.

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.

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.

With blockchains it's mostly about operational expenses. Now, bitcoin transaction fee might be currently high but it is a problem of this blockchain implementation and not with blockchain per se.

I am not sure if _lack_ of trusted intermediaries is the issue here. The problem is with their current form and shape, not with the lack of trust.

Blockchain is trying to reshape how the trust _works_ not its lack or abundance.

I am originally from central Russia and I've learned about anti-Semitism in Soviet Union only after moving to US. Yap, never heard or witnessed anything like that while living there.

Another interesting thing is that several of my Jewish friends told me that their parents asked them to lie about anti-Semitism when they were interviewed at the US embassy in Moscow in the late 90s.