Build your own React (2019)(pomb.us)
pomb.us
Build your own React (2019)
https://pomb.us/build-your-own-react/
3 comments
Author here. I'm working on a new version of Code Hike, more flexible. Docs: https://v1.codehike.org/docs
Are your older build-a-react tutorial available anywhere? The links on your site are broken and I wanted to implement a class/object based system using your older tutorial.
yes, try to find them on medium.com directly. I'm afk travelling right now, I'll update the links next week
Thanks for the pointer.
For others who are interested: https://medium.com/hexacta-engineering/didact-learning-how-r... and https://medium.com/@pomber are the articles.
For others who are interested: https://medium.com/hexacta-engineering/didact-learning-how-r... and https://medium.com/@pomber are the articles.
It's funny, I've been a web developer for many, many years and I've yet to see any compelling argument for why React (or similar libraries) should even exist.
Every single time I look into them I just can't find a reason why I'd ever want to use them over regular HTML and JavaScript. This is especially true in recent years when so many convenience functions have been added to the languages which you'd only previously find in the likes of jQuery etc.
I've looked at framework comparison sites like ToDoMVC.com and the React code just looks so disgustingly over-engineered.
I just don't get it at all.
Every single time I look into them I just can't find a reason why I'd ever want to use them over regular HTML and JavaScript. This is especially true in recent years when so many convenience functions have been added to the languages which you'd only previously find in the likes of jQuery etc.
I've looked at framework comparison sites like ToDoMVC.com and the React code just looks so disgustingly over-engineered.
I just don't get it at all.
Interesting - the one thing that makes me leery of React is that design is not separated from code. I'm used to HTML and CSS being in the province of the designer and I absolutely hate that there is no separation of concerns. The one thing I would remove from React is the ability to specify styling other than class and/or id for all but a few elements.
Now, it looks like I can do just that, maybe?
Now, it looks like I can do just that, maybe?
A useful trade-off for the separation of concerns between JS and HTML is type checking. It can be a game changer for some types of applications to have type checking of templates, especially if that type checking happens in a fast compile cycle or automatically in the background of an IDE.
I personally wasn't sold on JSX until I engaged with it through the lens of TSX. Having Typescript check that my templates make sense and variables are passed in correctly and unlikely to be `undefined` fixes a lot of the problems I've had in most other ways to template HTML.
As for styling, yes I'm also a big fan of letting CSS cascade, be the province of the designer, if possible, and that templates and scripting should focus on CSS classes and good selectors over inline styles as much as possible.
In JSX/TSX you can get some of the same linters that warn "no inline styles" even if using off-the-shelf React. Some projects turn those off for "CSS-in-JS" alternatives or Tailwind, but those are still options that I find uncomfortable. In my opinion: good templates produce good markup that a designer can use the "Cascade" in CSS to do wonders with, and components shouldn't need to micro-manage their own styles.
When I built my own React-like library with TSX I was also sorely tempted to remove inline styles and/or binding changes to them, but eventually was convinced that there are still some things that are more convenient that way (including if you are copy/pasting someone else's components or vanilla JS code). My library tries to stay "close to the vanilla wire" so to speak, so I needed inline styles and style bindings just because otherwise it would be done directly to the DOM object anyway, vanilla style. So in the end I was convinced to include them, but it was definitely something I thought long and hard about as someone who believes classes and the Cascade should be the first tool to hand, not inline styles.
I personally wasn't sold on JSX until I engaged with it through the lens of TSX. Having Typescript check that my templates make sense and variables are passed in correctly and unlikely to be `undefined` fixes a lot of the problems I've had in most other ways to template HTML.
As for styling, yes I'm also a big fan of letting CSS cascade, be the province of the designer, if possible, and that templates and scripting should focus on CSS classes and good selectors over inline styles as much as possible.
In JSX/TSX you can get some of the same linters that warn "no inline styles" even if using off-the-shelf React. Some projects turn those off for "CSS-in-JS" alternatives or Tailwind, but those are still options that I find uncomfortable. In my opinion: good templates produce good markup that a designer can use the "Cascade" in CSS to do wonders with, and components shouldn't need to micro-manage their own styles.
When I built my own React-like library with TSX I was also sorely tempted to remove inline styles and/or binding changes to them, but eventually was convinced that there are still some things that are more convenient that way (including if you are copy/pasting someone else's components or vanilla JS code). My library tries to stay "close to the vanilla wire" so to speak, so I needed inline styles and style bindings just because otherwise it would be done directly to the DOM object anyway, vanilla style. So in the end I was convinced to include them, but it was definitely something I thought long and hard about as someone who believes classes and the Cascade should be the first tool to hand, not inline styles.
I don't think I follow your concerns.
For styling, there has never been a requirement (or even, really, an incentive) to style your elements directly in JSX. It's possible to do so but you're just passing through inline styles to HTML.
For "the province of the designer," do you mean the designers of your sites are writing all the HTML and CSS themselves? I do not think that's the province of the designer personally, but it may be an older school of thought (I only started my career in the age of React). When writing in JSX, they truly can become thoroughly intertwined, as the structure influences the styling and vice-versa, and code can control either of those other options. I find this complex, but quite reasonable. The majority of the time it's actually just straightforward.
For styling, there has never been a requirement (or even, really, an incentive) to style your elements directly in JSX. It's possible to do so but you're just passing through inline styles to HTML.
For "the province of the designer," do you mean the designers of your sites are writing all the HTML and CSS themselves? I do not think that's the province of the designer personally, but it may be an older school of thought (I only started my career in the age of React). When writing in JSX, they truly can become thoroughly intertwined, as the structure influences the styling and vice-versa, and code can control either of those other options. I find this complex, but quite reasonable. The majority of the time it's actually just straightforward.
I’d be interested in a practical definition of logic truly separated from design in the context of web tech.
The two are so ridiculously intertwined. It’s already a problem within CSS, where layout systems and styling are mixed. Flexbox and grid have nothing to do with colors and gradients, which are again themselves orthogonal to positional properties. Fonts, paddings and margins (in 15 different units, look it up) add to the insanity. Now sprinkle in animations, box models and borders.
The two are so ridiculously intertwined. It’s already a problem within CSS, where layout systems and styling are mixed. Flexbox and grid have nothing to do with colors and gradients, which are again themselves orthogonal to positional properties. Fonts, paddings and margins (in 15 different units, look it up) add to the insanity. Now sprinkle in animations, box models and borders.
The world is largely moving away from this direction, including on mobile. It's not a React thing. React also allows you to organize your code however you wish.
> and I absolutely hate that there is no separation of concerns
There is a separation of concerns when using react but it’s not split by technology but by responsibility. A react components is an isolated piece of the puzzle which’s concerns are separated from the other puzzle pieces.
There is a separation of concerns when using react but it’s not split by technology but by responsibility. A react components is an isolated piece of the puzzle which’s concerns are separated from the other puzzle pieces.
That's the only thing that makes you question React?
I just hate the fact that it requires JavaScript to render even the simplest of pages. I would be bold enough to state that most websites built using React have absolutely no need to be built with React, i.e. they should be using plain HTML/CSS and maybe a tiny bit of JS instead.
Instead we now have an entire ecosystem where JavaScript powers everything, even the rendering of the most basic static page. And have you seen the markup generated by React and its ilk? It's horrific and makes debugging/modifying pages using client-side tools (user scripts, accessibility tools etc.) much harder.
It's anathema to me. I hate it all.
I just hate the fact that it requires JavaScript to render even the simplest of pages. I would be bold enough to state that most websites built using React have absolutely no need to be built with React, i.e. they should be using plain HTML/CSS and maybe a tiny bit of JS instead.
Instead we now have an entire ecosystem where JavaScript powers everything, even the rendering of the most basic static page. And have you seen the markup generated by React and its ilk? It's horrific and makes debugging/modifying pages using client-side tools (user scripts, accessibility tools etc.) much harder.
It's anathema to me. I hate it all.
> And have you seen the markup generated by React and its ilk?
I completely agree with your point that most sites could easily just be static HTML and we would all be better for it, but React does not generate any markup beyond what the developer instructs it to.
A lot of the hate modern JS frameworks get is actually the result of so many web developers having poor HTML skills (and, if I’m being honest, poor development skills all round). Nothing inherent to any JS framework is responsible for div soup.
You can construct clean semantic HTML from React just as easily as you can hand-write crappy HTML directly into a file on a server.
I completely agree with your point that most sites could easily just be static HTML and we would all be better for it, but React does not generate any markup beyond what the developer instructs it to.
A lot of the hate modern JS frameworks get is actually the result of so many web developers having poor HTML skills (and, if I’m being honest, poor development skills all round). Nothing inherent to any JS framework is responsible for div soup.
You can construct clean semantic HTML from React just as easily as you can hand-write crappy HTML directly into a file on a server.
HTML itself allows inline styles. I’m not sure how or why you would want to remove it from React, since it’s part of DOM.
If you don’t want to use inline styles, then don’t use them. Though even if you use a stylesheet, they are still essential for setting CSS variables.
If you don’t want to use inline styles, then don’t use them. Though even if you use a stylesheet, they are still essential for setting CSS variables.
I could see the argument to be made for imposing restrictions in React that don't exist in the next level down -- eg. something along the same lines as the argument for removing arbitrary effects in functional programming. However, I agree that this particular idea doesn't make much sense.
This seems to be the pattern that Angular uses. I've written quite a few Angular applications, but I have never been in a situation where a designer creates usable HTML and CSS, and the developers provide the code. It just seems like a pipe dream, but perhaps we should change the way we are working?
People could just do it in JavaScript without react.
His Scrollycoding framework uses a DSL similar to markdown+xml for the script and generates the webpage from it.