
10 years of Front end Development. I quit - mvgmvg
After 10 years of Frontend Development, I think I quit. What the HELL happened? I did some Vue.JS dev for a couple of years, (thank god Vue exists) but recently decided to dive into React &amp; its&#x27; ecosystem. Is this: <a href="https:&#x2F;&#x2F;material-ui.com&#x2F;styles&#x2F;basics&#x2F;#hook-api" rel="nofollow">https:&#x2F;&#x2F;material-ui.com&#x2F;styles&#x2F;basics&#x2F;#hook-api</a> considered progress? I think I know what happened. Many ex-backend devs entered the field and being unable or impatient enough to understand and do CSS properly, decided to inline and JavaScripIze everything. Then came the Educators, the Wes&#x27;s, the eggheads, the Public Speakers, Facebook and the like, and managed to convince the world all this is a good thing. I spent half an hour looking into the Material UI documentation trying to figure out how to add proper styles. This is sad. Fuck all of it.
======
phillipseamore
Couldn't agree more! Just took over a project done in React. Rewrote it in
plain html, css and JS. Went from megabytes down to kilobytes. At least 10x as
performant. Ended up with about 360 LoC JS to implement everything that was
previously done with a ton of imports.

~~~
cpach
Kudos!

------
mydongle
I'm a casual so don't take this post as authoritative or anything, but I feel
like people are forced to use frameworks to do anything more complex than a
static website meant for desktop only. For example, to make a fully responsive
website that adapts from desktop to mobile and vice versa and can dynamically
create forms and stuff, there's no one place to go and see a SUPER OFFICIAL
STANDARD OF HTMl/CSS way to do it. There are some official resources like
w3school and mozilla, but they're only good for really simple things. You find
a bunch of scattered guides around the web, none of them really explaining the
choices in their settings very well or at all. So as a beginner, I feel like I
am just throwing shit at a wall and hoping something sticks and works, until I
find some other setting from a different guide to do some other thing that
breaks the first feature. With modern frameworks, you can achieve some
structure and order, because someone else did all the boilerplate and
groundwork so that you can just make a damned website like you wanted to do
instead of floundering around from tutorial to tutorial.

------
pascalxus
People look at "modern frameworks" and they're so easily impressed by what it
can do. But, it's very short sighted. If you're project expects you to
implement a feature that doesn't work in that framework, all the sudden you're
going to have a huge productivity disadvantage.

It's better to learn actual web development: HTML/CSS, javascript, jQuery.
Learn how to manipulate the DOM and not expect a library to do everything for
you. In the long term, it's much more productive.

~~~
commandlinefan
> they're so easily impressed by what it can do

Are they, though? I haven't worked with React, but I have had the misfortune
of working with Angular and I was immediately struck by how useless the whole
thing was - it was pure overhead, and didn't seem to actually "do" anything at
all. At least with jQuery there were some cute accordion and slideshow plugins
- Angular just made things slower and bigger. I asked the front-end guy who
was pushing Angular so hard why we didn't just scrap the thing entirely and,
after a bit of incredulous back and forth, got sort of a condescending "you'll
understand how helpful it is once you've spent some more time working with
it". Nope, just give me HTML/CSS/Javascript. I'm a programmer. I can program
the rest.

------
recursivedoubts
I sympathize. The state of front end dev is in no small part why I wrote
intercooler and, now, work on htmx:

[http://htmx.org](http://htmx.org)

It's crazy how unnecessarily complex everything has become.

~~~
raihansaputra
Glad to hear it's still going! Does this represent a lot of change from
Intercooler? Why a new project instead of integrating it to Intercooler?

~~~
recursivedoubts
For simple stuff it's not too different from intercooler, but I wanted to have
the freedom to remove mistakes and ideas that didn't work out, so I chose to
go with a new name.

Originally I chose kutty, which means, roughly, "sweet" in american slang, but
that had too many other meanings, including a very unfortunate meaning in
dutch slang.

------
poisonborz
Man, chill out. Don't let the burnout or a few bad days cloud your judgement.
A lot of new tooling is shit. It was always like this. It's like someone
judging FE dev by all the jQuery monstrosities in 2010 or by Angular 1.x in
2013.

Choose good tools, but most importantly, good projects. They're out there.

------
schwartzworld
What happened was that web apps and SPAs got powerful enough and ubiquitous
enough to deserve their own tooling and abstractions. React is about creating
a program that generates a UI. Lots of people use it to build static websites
because they want access to the tooling that the ecosystem has created, much
of which is very good.

The kind of front end development I do at work would be much harder without
React, not only because the app is large, but there is a large team working on
it. Using a framework and adhering to it's best practices makes onboarding
easier, and coding (and reviewing code) faster.

------
wayneftw
If you end up giving React, Material UI and JSS a chance, there are some
things you can do to make it more palatable.

1\. Put all of your calls to makeStyles in a separate file called
MyComponent.styles.js right next to your component and export the resulting
useStyles function(s).

2\. Learn the power of the themes system. Make a themes/defaultTheme.js file
where you export the result of createMuiTheme(and modify all MUI components
here as well as add your own variables and functions that can be used in any
of your .styles.js files).

3\. Wrap your app component with a ThemeProvider passing your
theme={defaultTheme}. These can also be nested so you can have different
themes for different area of your component tree.

4\. In your style.js files, use theme variables or functions as part of your
styles. Also try creating functional CSS selectors, which are functions that
can use whatever props that you've passed into your classes =
useStyles(props); call and return a dynamic style based on those props.

It's actually quite powerful. The closest you can get to this level of
encapsulation, flexibility and dynamic theming with non-JS CSS is CSS Modules
and CSS Variables, which you can read about here - [https://itnext.io/css-
variables-dynamic-app-themes-86c0db61c...](https://itnext.io/css-variables-
dynamic-app-themes-86c0db61cbbb)

However, Material UI is not going to help you very much with that type of
styling. That kit works best with JSS. They do provide some integration points
with normal CSS, CSS Modules or any other type of styling but the easy path
with MUI is to just embrace JSS. After working with it for a while, I prefer
it.

I don't understand the complaint that you had to spend a half hour looking
into how to do something with a framework that is new to you. That's the job.
If they just gave you the basic React styling capability, Material UI wouldn't
be as popular as it is. Providing multiple integration points for multiple
dynamic styling/theming systems for an entire framework of related UI elements
is not easy and their documentation on what they've done here is quite
straightforward. Give it a chance, experiment, learn some basic principles and
you'll see how powerful it is compared to doing straight CSS or SCSS.

------
nojvek
I will say this. React popularized good ideas at the start. `View is a
function of state`, that's a great paradigm to build UI on. It makes a lot of
things simpler. Other frameworks like Vue, svelte, snabbdom all do very
similar things.

The current iteration of React with hooks, fibers, synthetic events is a
tirefire. There's a lot of `It's Facebook so it must be good` hype without
questioning whether all that complexity even makes sense.

Gzipped React + ReactDom = ~50KB. Unzipped is ~200KB. That's nuts and plain
inefficient. A low powered device will take half a second to load and parse
that crap before it even does a first paint.

If you care about performance, React is no longer the tool. Svelte and Preact
(4k gzipped) are way better alternatives.

Stay away from it. If it's a simple app/web page, just use vanilla js. The
core DOM API has good cross browser compatibility nowadays. You don't even
need jQuery.

React is a jack of all trades but master of none. Don't equate Frontend
Development === React.

------
tvphan
The Material UI library for React is such a piece of garbage and I actually
believe it’s one of the main reasons why so many devs hate React. You can use
React without and your happy will be so much happier!!

------
jamespetercook
The whole CSS in JS thing is so backwards. I use React a lot and I love it,
but styles stay in a css file structured using BEM. It works.

~~~
tvphan
I thought the same thing until you start to think in terms of “constraint-
based components”, which are more easily done in CSS-in-JS. Styling is done by
passing properties to a component, e.g. <Heading color=“primary” />, and only
the developer building the primitive component needs to worry about styling.
You end up being able to rapidly develop interfaces that match the designs.

~~~
jamespetercook
If I understand correctly you can still do that, just the underlying component
will be adding/removing a CSS class instead of injecting the actual styles. I
usually use the classnames library to help with this but obviously not a
requirement ([https://www.npmjs.com/package/circular-dependency-
plugin](https://www.npmjs.com/package/circular-dependency-plugin)) I find it's
also easier to test for the presence of css classnames based on the provided
props than it is to test for the presence of mutiple style rules.

------
henriquez
You’re not wrong. I just quit the industry as well; the multiple levels of
webpacked transpiled bullshit, react modules for spacer divs and “type safe
CSS” really got me down. Between ass backwards code, renting mainframes from
Amazon, and surveillance capitalism I realized that everything I loved about
commercial web engineering has gone to shit.

I have no idea what my next move is but right now I don’t really care.

~~~
Skunkleton
Go work on embedded stuff. There are lots of jobs where you work primarily
with electrical engineers. It is pretty much the opposite of front end work.

~~~
henriquez
Embedded sounds cool but I like working with vanilla JS and high performance
in-browser rendering with canvases and other tricks. Basically the opposite of
modern JS frameworks. I might brush up on my linear algebra and get into
Vulkan programming. I’m basically unemployable right now due to severe
lockdown-induced burnout so I have time to figure stuff out.

~~~
testbot123
Oh man, try WebGL if you haven't already. If you're into math and writing
highly-performant code, shaders/GLSL is going to be right up your alley. And
you can make really cool and fun stuff with it in the frontend, too!

[https://developer.mozilla.org/en-
US/docs/Web/API/WebGL_API](https://developer.mozilla.org/en-
US/docs/Web/API/WebGL_API)

------
iliaznk
In general I agree that all that JSS mess is something invented by someone too
lazy (to put it mildly) to learn how CSS works (just like hooks – too lazy to
figure out "this" and classes in JS), but if you read the docs a bit closer,
you'd find that plain CSS works just as well [https://material-
ui.com/guides/interoperability/](https://material-
ui.com/guides/interoperability/).

~~~
thatswrong0
> just like hooks – too lazy to figure out "this" and classes in JS

That's just a part of why hooks exist: [https://reactjs.org/docs/hooks-
intro.html#motivation](https://reactjs.org/docs/hooks-intro.html#motivation)

The more important parts have to do with code reusability and complexity.

And the way classes work in React is not typical and there _are_ non-standard
behaviors to them, so to brush that additional complexity aside is myopic.

~~~
iliaznk
Oh, did I? But as far as I remember, not having to figure out classes was one
of the official reasons why hooks came to be, which was clearly stated in the
corresponding blog post, I think.

~~~
iliaznk
Oops, the original comment I was replying to is gone... I didn't notice before
that people here seem to like to comment and then delete it a minute later.

------
agent3bood
Let's rewrite the same example and change the variable names, I think it make
more sense now.

    
    
      import React from 'react';
      import { makeStyles } from '@material-ui/core/styles';
      import Button from '@material-ui/core/Button';
      
      const MyButtonClasses = makeStyles({
        root: {
          background: 'linear-gradient(45deg, #FE6B8B 30%, #FF8E53 90%)',
          border: 0,
          borderRadius: 3,
          boxShadow: '0 3px 5px 2px rgba(255, 105, 135, .3)',
          color: 'white',
          height: 48,
          padding: '0 30px',
        },
      });
      
      export default function MyButton() {
        const classes = MyButtonClasses();
        return <Button className={classes.root}>MyButton</Button>;
      }

~~~
ahofmann
This looks like much too complicated CSS mixed with Javascript. Or in other
words: why must a button be created in such a complex way, when CSS and HTML
can do the same?

------
webartifex
backend dev here. mainly python/flask.

question: if I really wanted to start frontend this year, where would I start?
recommendations?

~~~
henriquez
I would recommend starting with HTML and CSS and avoid JavaScript until you
have a good sense of how the static stuff works. Then play a bit with JS and
find a framework that you like working in.

If you already know Python it should be relatively easy to learn JS, just try
to understand _this_, scoping and variable hoisting, which is the source of
almost all of the weirdness of JavaScript and something a lot of (even
experienced) developers get confused on.

------
Ioluc8yi
> I think I know what happened. Many ex-backend devs entered the field and
> being unable or impatient enough to understand and do CSS properly, decided
> to inline and JavaScripIze everything.

Lol, dude. A few years before publishing React, Facebook hired basically all
Mootools developers who would join, which were among the few people taking big
javascript applications seriously before "frontend development" was a thing.

------
assertnotnull
Sadly our reality is that the used tool is the one that gets most publicity. I
never liked React or Angular because how it mixed structure and styling. It
was sold on features then simplicity. Whereas I used Riot.js, then Vue.js now
using personally Svelte because it's even simpler. BTW I do frontend+backend
Node.js now learning Elixir.

------
zie1ony
Backend dev here. It's exactly as you said. Now I can easily write complex
fronted with React. But the real revolution is yet to come. WASM is behind the
corner. I believe it's just a matter of time and we'll see the Rust-based,
React-like frontend framework that will be viewed as the killer of JS.

Long live JS, V8, TS and JQuery! Peace.

------
robocat
Trust your own aesthetic ideals: can you use your anger to help push you in a
positive direction? I agree there is a lot wrong with the React ecosystem, and
its complexity. I wish I could suggest something unequivocally better than
doing front-end work to earn money, but other options just have different
compromises. Good luck.

------
earthlingdavey
You quit cos of this? Did you change your mind yet? CSS in JS is pretty good
for performance and organising of styled components. Give it at least a day or
two of learing before you throw 10 years work down the drain ️

------
mooted1
Oftentimes, these tools are developed for much more complex sites than the
people who author these rants have ever maintained. Of course it doesn't solve
meaningful problems for sites that can be maintained by a handful of
developers and whose feature set evolves slowly.

That's fine. Don't use them.

It'd be nice if rants like this also reflect on why these frameworks _do_
exist. Then people would actually learn something.

Here are some of the tradeoffs I considered when evaluating JAMStack vs
flask/jinja server side rendering.

1\. Low latency interactivity unlocks all kinds of user interaction
optimizations for us. The size of the initial download is amortized over
hundreds to thousands of lightening fast interactions.

2\. It's difficult to manage complexity around large html/css deployments,
since CSS is a global namespace. Devs use all kinds of conventions for
modularizing CSS. You can definitely succeed with these strategies, but when
you're juggling tens of thousands of lines of CSS, it's a lot easier to solve
these problems using a real programming language and its module system. We
anticipated thousands of lines of CSS over time.

3\. Immutability makes whole classes of race conditions unlikely to
impossible. Do things still race in React? Of course. Are they vastly less
likely to happen? Yes.

4\. Managing interactivity through server-client interaction shifts a ton of
complexity to the backend that the browser could otherwise handle. If you're
designing a multi-stage form, for example, you often have to save incomplete
user submissions in servers, depending on use case. Offloading this to
localstorage on the frontend is a lot easier to author and maintain.

5\. If you host your frontend statically on CDNs, that's several orders of
magnitude less traffic you have to scale your web servers for. The vast
majority of my company's traffic is handled by Cloudfront, making our
operational footprint tiny.

Are there also reasons the modern stack sucks? Yes.

1\. Configuring react and webpack is incredibly, incredibly hard. Webpack
exposes a vast array of knobs that most applications don't benefit from
tuning.

2\. Time to first load is absurdly slow and server side rendering is, again,
very complex to implement. React is not the right choice for a blog or
anything that is sensitive to bounce rates.

3\. MUI's documentation and APIs are painful, as OP notes.

For these reasons, and because most of our application was interactive, not
read-only, we went with JAMStack.

I definitely think there's a place for the traditional HTML/CSS/jQuery stack.
Read-only sites, for starters, with limited feature complexity. Everything
I've built in the last several years has grown in complexity and features at a
faster-than-linear rate, however, and these new technologies make managing
such codebases vastly simpler.

------
chad_strategic
One time I had to use Ember as the front end and drupal API as the backend.
Seriously, what a mess. But I was getting paid...

