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.
10 years of Front end Development. I quit
21–30 of 50 posts
Re: 10 years of Front end Development. I quit
#22You’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.
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.
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.
Re: 10 years of Front end Development. I quit
#23backend dev here. mainly python/flask. question: if I really wanted to start frontend this year, where would I start? recommendations?
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.
Re: 10 years of Front end Development. I quit
#24Couldn'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.
Kudos!
Re: 10 years of Front end Development. I quit
#25The 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.
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. , 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.
Re: 10 years of Front end Development. I quit
#26backend dev here. mainly python/flask. question: if I really wanted to start frontend this year, where would I start? recommendations?
I love React and would recommend it as the primary frontend library. However, I would suggest avoiding the Material UI component library entirely (as I believe it’s both difficult to customise and over-engineered) and just write SASS to start off.
If you really like how Angular 1 worked (writing templates instead of JS to represent DOM) then Vue is a great choice.
Re: 10 years of Front end Development. I quit
#27People 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 everyt…
jQuery is not part of standard web development, it’s a library.
You can also view vanilla Javascript as a library, just one that ships with the browser. Where is the distinction between too much abstraction and not enough? You’re not developing in machine code right?
Re: 10 years of Front end Development. I quit
#28Oftentimes, 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.
Re: 10 years of Front end Development. I quit
#29If 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...
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.
Re: 10 years of Front end Development. I quit
#30What 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.