3 ms·

> In my view the only thing we should retain from the React era is JSX (for many reasons, true type-safety, autocomplete etc) Warning: opinion incoming. JSX i

> In my view the only thing we should retain from the React era is JSX (for many reasons, true type-safety, autocomplete etc) Warning: opinion incoming. JSX is one of two reasons that I never liked React at all and wish it would go away. I've been developing "web applications" since the latter half of the 90s. I've worked with everything from an in-house built dynamic template language (very similar to what PHP did in the early days) developed in C++ and served using CGI in Apache, to developing with PHP to Java Spring MVC to Django to modern frontend frameworks including both React and Angular. JSX reminds me of what PHP was like in the 90s and early 00s. People adopted it widely because the barrier to entry was extremely low. We had all of these static HTML websites and "developers" could just go in and start adding control flow to those documents in order to add dynamic functionality. It was easy ... and it quickly turned into a complete mess so big that PHP ended up with a reputation as being a toy language that "serious programmers" wouldn't be caught dead touching. That reputation was a bit unfair but also kind of earned. With the rise of PHP's popularity, the PHP "community" itself came to realize that they had a decent turing-complete programming language that they were working with, but that this idea of mixing business logic within HTML documents was a massive anti-pattern. It's ironic that what began its journey as a template language eventually realized that the best thing for the language was to stop using it as a template language, and to adopt different template languages such as Smarty in order to promote a separation of concerns between view / presentation concerns and business logic. React was never created as a "framework." There are actual frameworks that are starting to come out that use React for its view layer, such as NextJS, but React itself is just a library that allows you to create custom components and then choose your adventure when it comes to what other libraries you want to mix and match. But because people reach for React to start throwing together dynamic frontends quickly, everything is compononent-first. So it actively encourages you to put business and integration concerns in what really ought to be your view / presentation "layer." And JSX magnifies that problem by just being JavaScript. So, again, it's PHP all over again. You've got a very powerful turing-complete programming language that you intersperse with your markup and you get messes. Even in the most well-written, concern-separated React projects I still see a lot of "ugliness" that comes through with JSX. I did mention that it was one of two reasons I'm not a fan of React, the other is that - again because it was only conceived of as a component / view library - there is no inbuilt view encapsulation / scoped styles. This problem is somewhat mitigated by CSS modules these days. But view encapsulation is something that I've always seen as Angular's killer feature - the ability to just style your tags directly and create component markup that is completely devoid of class="" attributes. Angular and VueJS actually trained me to hate 99% of class="" attributes and to think of them as a type of code smell... just because it is possible to create higher-level components that don't have any at all but still styling when needed.

imtringued 2y ago
Some of us need to get work done and not worry about the XSS potential that inline styles represent so we set our CSP to block all inline JavaScript and CSS. Btw I'm sorry if I misunderstood what you're trying to say, because you're mostly dissing the class attribute which I very much depend on purely to keep my websites secure.
- gspencley 2y ago
  Yup you misunderstood. I would be just as much opposed to inline styles as using class="" attributes. With frameworks like Angular, you can create a component and bind CSS styling to that component in a way that you can select just your HTML tags directly ... like style div {} instead of styling .my-card {} etc. And those styles are not "global", they are scoped to only those elements that are referenced in your component's markup. There are two ways that this can be implemented and frameworks often let you choose which one you want to employ: Shadow DOM or emulation. With emulation, the classes and selectors get generated for you at compile time so if you inspect the DOM you'll see tons of class="" attributes that were auto-generated ... but the developer never had to write them or think about them. The result is code that is so much nicer to read and work with.
stickfigure 2y ago
Separating components is more important than separating presentation and business logic, and React/JSX excels at that. Old style MVC and templating frameworks that promised clean presentation/business separation ended up with two giant muddled piles of disorganized code. Components gave us a better organizational structure for complicated UIs, and that's why that form of separation won out. If you have nice clean modular components, it doesn't matter too much where the code vs template boundaries are inside. They shouldn't be so complex that it matters. This is why I like JSX - for any given component, everything is in one place.
- gspencley 2y ago
  > and that's why that form of separation won out. React won out because it has a low barrier to entry and is very unopinionated. That's not a bad thing. But don't pretend for a second that it won out as any kind of industry standard because it was technologically superior or was a better designed "framework" (again, it's not and never was a framework, it's a view library for creating components). There are 3 broad concerns when it comes to programming for the virtual machine that we call the web browser: - Semantic demarcation, which is what markup does: this is a paragraph, this is a header, this is card etc. - Visual decoration and styling, what CSS does. This is how a paragraph looks, this is how a card looks etc. - Interactivity and control flow: what JavaScript does. When the user clicks the button this is what happens. Those are all distinct responsibilities which the browser handles separately natively. We don't need to even start talking about MVC or OOP design patterns when talking about spearating your concerns. That's a basic engineering concept of isolating your moving parts to keep things simpler and allow you to change things in isolation without acccidentally breaking something else, which is the bane of software maintenance. The notion that diluting separation of concerns is a design innovation that makes software development and maintenance somehow easier is truly baffling.

imtringued 2y ago

Some of us need to get work done and not worry about the XSS potential that inline styles represent so we set our CSP to block all inline JavaScript and CSS. Btw I'm sorry if I misunderstood what you're trying to say, because you're mostly dissing the class attribute which I very much depend on purely to keep my websites secure.

gspencley 2y ago
Yup you misunderstood. I would be just as much opposed to inline styles as using class="" attributes. With frameworks like Angular, you can create a component and bind CSS styling to that component in a way that you can select just your HTML tags directly ... like style div {} instead of styling .my-card {} etc. And those styles are not "global", they are scoped to only those elements that are referenced in your component's markup. There are two ways that this can be implemented and frameworks often let you choose which one you want to employ: Shadow DOM or emulation. With emulation, the classes and selectors get generated for you at compile time so if you inspect the DOM you'll see tons of class="" attributes that were auto-generated ... but the developer never had to write them or think about them. The result is code that is so much nicer to read and work with.

stickfigure 2y ago

Separating components is more important than separating presentation and business logic, and React/JSX excels at that. Old style MVC and templating frameworks that promised clean presentation/business separation ended up with two giant muddled piles of disorganized code. Components gave us a better organizational structure for complicated UIs, and that's why that form of separation won out. If you have nice clean modular components, it doesn't matter too much where the code vs template boundaries are inside. They shouldn't be so complex that it matters. This is why I like JSX - for any given component, everything is in one place.

gspencley 2y ago
> and that's why that form of separation won out. React won out because it has a low barrier to entry and is very unopinionated. That's not a bad thing. But don't pretend for a second that it won out as any kind of industry standard because it was technologically superior or was a better designed "framework" (again, it's not and never was a framework, it's a view library for creating components). There are 3 broad concerns when it comes to programming for the virtual machine that we call the web browser: - Semantic demarcation, which is what markup does: this is a paragraph, this is a header, this is card etc. - Visual decoration and styling, what CSS does. This is how a paragraph looks, this is how a card looks etc. - Interactivity and control flow: what JavaScript does. When the user clicks the button this is what happens. Those are all distinct responsibilities which the browser handles separately natively. We don't need to even start talking about MVC or OOP design patterns when talking about spearating your concerns. That's a basic engineering concept of isolating your moving parts to keep things simpler and allow you to change things in isolation without acccidentally breaking something else, which is the bane of software maintenance. The notion that diluting separation of concerns is a design innovation that makes software development and maintenance somehow easier is truly baffling.