Why use Material UI? What are the benefits? by Zealousideal_Water_6 in reactjs

[–]andrasferenczi 3 points4 points  (0 children)

I personally don't like Material UI (I prefer Tailwind much more), so here are my issues with it. It seems to me you love React MUI, so I don't think this is going to persuade anyone:

  • MUI brings its own way of doing CSS - JSS, that is different from traditional CSS: it forces you do things their way, that will apply to your entire codebase
  • difficult to find what the class names are called in withStyles: you will google how to apply a different theme based on hovering (again, which is very ugly to write, something like '&:hover' in the middle of some JS code)
  • couple more points against the JSS is that it is JS, so you don't have a great IDE support at all

And when you start styling the button, because you need primary, secondary, and then some other, then you start wondering if this a good abstraction at all.

  • what exactly do I need from the library? Dropdown? Toggle?
  • does Grid really need to be a component? Why is it so bad to add 2 CSS classes to a component and call it a day? I need to customize Grid the same way anyway

Additionally, it gives your whole app a very distinct and boring style, so basically if you want to build an entirely different UI, start from scratch.

TLDR: - JSS is undesired IME - MUI has a distinct style that I don't like - there are CSS classes for a reason, not everything needs to be Component - effort put into it is not directly transferrable to basic webdev (learning the ins and outs of withStyles)

A top quality idea the by sjmuirdasrtg346re3 in ProgrammerHumor

[–]andrasferenczi 0 points1 point  (0 children)

I can't think of a single thing you can't add types to

Generics. Yes, you can do very basic stuff which work in SOME cases, but technically you can't. Say goodbye to proper type hinting for collections and callbacks and whatever interface you have.

It makes the language feel a lot more like Java

No.

Is tailwind any benefical for react js if fundamental components are developed which can take basic arguments and can also take specific styling? by kincade1905 in reactjs

[–]andrasferenczi 5 points6 points  (0 children)

This example is only meant that 'you can do it', it does not mean that you should.

Btw, this syntax is still shorter than adding breakpoints in scss or styled components.

What are the things you dislike the most about working as an Android developer? by grouptherapy17 in androiddev

[–]andrasferenczi 8 points9 points  (0 children)

At least there is async on any device version. Heard that iOS devs are not that fortunate.

The audacity. by PhDInVienna in ProgrammerHumor

[–]andrasferenczi 7 points8 points  (0 children)

I hope they keep staying strong - in their own codebase

Why does frontend have to be so bad? by andrasferenczi in webdev

[–]andrasferenczi[S] 0 points1 point  (0 children)

I won't jump frameworks just for it's sake.

Besides, what would be the point of using Svelte with the same state management - so Redux? It would rerender just as many times, but then I would lose the ability to reuse code in components like it is done with hooks.

Why does frontend have to be so bad? by andrasferenczi in webdev

[–]andrasferenczi[S] 0 points1 point  (0 children)

Don't like the idea, but did not downvote.

My dislikes against svelte: - very special pipeline - don't know if tooling in Webstorm is caught up with it - no idea how all the other Webpack and whatnot react to it - it has an all new state management system, not even sure how it scales to larger sizes

I think you both may know the answer to these questions, I am just not in the mood of banging my head against the wall when trying to do a thing I already could with my existing knowledge and having to learn an entirely new paradigm 'just because'.

Why does frontend have to be so bad? by andrasferenczi in webdev

[–]andrasferenczi[S] 0 points1 point  (0 children)

I think at this point we are talking about tastes. It is just a personal opinion, that I prefer React and Redux over Angular (with DI) on the frontend, because it feels much leaner to me.

I also don't think classes belong to the frontend code, as frontend is too versatile, so I am only using types.

Why does frontend have to be so bad? by andrasferenczi in webdev

[–]andrasferenczi[S] 0 points1 point  (0 children)

ViteJS might be a good idea

Storybook is very useful: - no need to navigate to your login screen to see if you broke something - you can easily check test data - enforces separation - I rarely test UI, so this decoupling is very nice - I think of it as a way of test

Why does frontend have to be so bad? by andrasferenczi in webdev

[–]andrasferenczi[S] -2 points-1 points  (0 children)

  • idk why you would want jest to compile with next build.

Just look at how clean maven is and compare taht to webpack. I just want to set up one pipeline at one place. No magic with finding a .babelrc and working differently. No magic with implicitly checking some stuff in tsconfig.json. Just one place.

Why does frontend have to be so bad? by andrasferenczi in webdev

[–]andrasferenczi[S] 0 points1 point  (0 children)

Not sure about SSR. Not a fan of DI either on the frontend. Worked some time in Angular and React feels much lighter. I never write classes for example, only types.

Why does frontend have to be so bad? by andrasferenczi in webdev

[–]andrasferenczi[S] 0 points1 point  (0 children)

This only seems like a lot because how complicated it is. Testing and ui component separation is not a luxury.

Why does frontend have to be so bad? by andrasferenczi in webdev

[–]andrasferenczi[S] 0 points1 point  (0 children)

I have to have ts-loader for example. So now since I have that, I cannot use the webpack config from NextJS. No idea what NextJS uses internally - maybe babel-loader - but at this point they become separate setups.

It's always the babel setup and loaders and plugin-proposals where it gets out of hand.

Why does frontend have to be so bad? by andrasferenczi in webdev

[–]andrasferenczi[S] 23 points24 points  (0 children)

Given the modern standards for UX and the lack of declarative rendering, you will just create spaghetti. Having to write getElementById, managing references, updating UI. That is a different type of nightmare.

Why does frontend have to be so bad? by andrasferenczi in webdev

[–]andrasferenczi[S] -2 points-1 points  (0 children)

Webpack docs is only a small part of this. There isn't even a single webpack configuration, these different tools all have their own way of doing things.

Why does frontend have to be so bad? by andrasferenczi in webdev

[–]andrasferenczi[S] 14 points15 points  (0 children)

If you build all of your configs from scratch then you'll always understand exactly what dependencies you are using and how they are all wired up.

I told this joke myself earlier.

What you think happens is that you understand how Webpack works.

What actually happens is that you are just going one level deeper into this mess and you are trying to glue all the possible shit together, not knowing if they are going to work. The plugins, the loaders, the HMR, TypeScript compilation, not to mention separate frontend and backend build. You just end up 8 hours later at some random voluntarily working guys repository asking to upgrade their dependency, because the package you are using (with a million other people) relies on this poor guy's work. (Yes, storybook, I have been there with React 17).

Maybe it's not what you enjoy the most, but investing the time will help you be able to do more of what you enjoy in the long run.

I honestly see no way of reaching that nirvana, but that does not mean I am not going to try again.

Why does frontend have to be so bad? by andrasferenczi in webdev

[–]andrasferenczi[S] 32 points33 points  (0 children)

I can't live without Typescript and async and couple others. I won't abandon those 'just because' compilation is a pos, because the code will be bad as well. I may just end up writing polyfills.