question: if I really wanted to start frontend this year, where would I start? recommendations?
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.
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.
If you really like how Angular 1 worked (writing templates instead of JS to represent DOM) then Vue is a great choice.
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.
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.
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?
It's crazy how unnecessarily complex everything has become.
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.
I have no idea what my next move is but right now I don’t really care.
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!).
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.
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>;
}Choose good tools, but most importantly, good projects. They're out there.
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.
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.
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.
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.
Long live JS, V8, TS and JQuery! Peace.
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.