Hacker News new | past | comments | ask | show | jobs | submit login
[flagged] 10 years of Front end Development. I quit
64 points by mvgmvg on May 21, 2020 | hide | past | favorite | 46 comments
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 & its' ecosystem. Is this: https://material-ui.com/styles/basics/#hook-api 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'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.

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.


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.

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.

> 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.

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?

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


It's crazy how unnecessarily complex everything has become.

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?

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.

Love the name switch, the logic of htm + x makes it easy to remember and you got a good domain name for it too.

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.

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.

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...

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.

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.

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!!

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.

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.

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

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.

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.

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!


Embedded work has its good points, but it has its downsides. I wouldn’t advise anyone to change because they expected the tooling or libraries to be better designed, or if they imagined that working with electronics means dealing with less bugs or that they might be working with more skilled people!

I have relevant background to say this, although my embedded work is very rusty. I have an EE degree and a small amount of experience with electronics. I’ve been doing web front end for over a decade which was mostly 100% JavaScript SPA dev work (recently quit because browsers are hell: I did like the money and some of the challenges!).

Yeah, I certainly didn't mean to imply that embedded code is high quality. It is just as much of a mixed bag as anything else. If anything it can be a bit worse because it often isn't user facing. Also, as an embedded developer, a big part of your job is to wallpaper over bugs in hardware.

Embedded is a pretty stable ecosystem though. Most of the "new" stuff is introduced on the order of years.

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/.

> 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

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.

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.

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.

Funnily enough I started working with hooks a couple months ago and I can no longer go back to classes. And Functional programming has just made things so smooth.

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>;

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?

backend 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.

Svelte is easiest to pick up and gets you far.

Eventually it makes sense to learn JavaScript on its face. It is a weird and beautiful language. Abandon hope of understanding it unless you read a coherent book about it. As for me, I read JavaScript: The Definitive Guide from cover to cover. I have also read good things about JavaScript: The Good Parts, and I know that Douglas Crockford is smart.

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.

I'd say don't. You'll end up like the OP in about 3 weeks flat.

I'd recommend freecodecamp. Starts from the basics and ends every section with a project

React with typescript

> 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.

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.

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.

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.

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 ️

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.

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...

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact