Hacker News Reader

Comment by atoav | Hacker News Reader

I am one of those people who started reading a book on HTML when I was 10. I didn't understand a lot, but kept reading again and again and with 13 I understood enough context to create HTML websites.

For most projects I have been doing since it was either pure HTML, CSS wirh a few sprinkles of handwritten Vanilla JS, or Jinja2 templates with occasional PHP. When it got really complicated I used Flask or Django.

But to this day I never understood people who use js/react for pages that could have been handwritten with zero js in half a day (including a handwritten fluid CSS layout).

View on HN

> But to this day I never understood people who use js/react for pages that could have been handwritten with zero js in half a day (including a handwritten fluid CSS layout).

I think people tend to improve their knowledge of some specific tool/language (JS in this case) and wanting it to apply to everything, not just what they initially learned it for and even if it might not be a great fit.

If all you know (because its what the schools/bootcamps teach) is generating HTML via DOM operations in JS, you might not even know better/simpler ways of doing it.

A bit like if someone just knew C and haven't really explored other languages/environments, then they might think that building a server serving HTML is a great thing to build in C, rather than using pre-built tools that serve static files or even using a safer language.

HTML is hard to compose (as in composing a page out of modular components), reuse (your toolbar everywhere has to recreate a bunch of components, like the nav section, logged in state, etc.).

Sure you can do that with server-side templates, but it's more readable (especially in a team) to use React components.

For me the main benefits of React didn't really shine until I had to maintain complex state and component trees among multiple devs. What is overkill for a simple blog is an absolute godsend for more complex apps.

Although frankly I still think Angular had a much better architecture, and I'm kinda sad React took over. But hey the frontend landscape gets a revolution every year or two (sigh) so who knows what the dominant paradigm will be by 2024.

I still don't get the love affair with CSS in JS. It defeats much of the purpose of CSS.

Also, my idea of a FE component is that of a class. A black box if you will. It the markup structure with the details as properties. Reusable because all properties are set from outide.

If you're hardcoding CSS within the "component" then it's not a component. And then having to effectively rebuild the entire app because a hardcoded bit of (Tailwind) CSS needed to he changed?? That's a step forward?

From a professional / career stand point I'm interested in React. But its model of thinking feels like 1999 in some ways.

I'm missing something? What am I missing?

As a react dev, I don't like CSS in JS either. It brings back the old font tag approach of individually styling components.

As an alternative, you can just assign class names to components and use global CSS like the old days, if you prefer. Sass is pretty great, basically CSS with better selectors and variables.

Exactly. Something like Tailwind should be done in the Sass, not by assigning a gazillion helpers.
Have a component-type class in the component then use Sass to configure that with helper properties (read: functions and mixins, etc.)
But hardcoding? Inline? I did that in 1997.

Keyword in. I know TW is done with Sass

The CSS in js components can be fully reusable between compatible frameworks, without any wiring of separate CSS files, and can also utilize theme configuration. Also just like how jsx is a form of html in js, having your style definitions in the same place makes it a lot easier to immediately grok what the component does and how it will look

Not if that CSS is styling (unique to the project). Once it's "hardwired" you have to rewire it to use it again, or worse...if the styling changes you have to rebuild. In the context of CSS's intention, that's an anti-pattern. Yes, people do it. But that doesn't change the anti-ness.

If you're editing the actual components then that's a step backwards in time. They should be like (OOP) classes. Completely agnostic. Completely "decoupled". They should be the structure (i.e. markup). But the styling should be abstracted out into "real" CSS, not inlined hardcoded CSS.

Put another way, for all intents and purposes CSS in JS is like using important!. Nuff said.

I'm building a simple page. Ok let's do simple html. Now I need popup for email capture, ok add a bit of hacky js. Now add a menu, could potentially be done with css only.

Now add responsive images. Good luck. You need to process then on server side, then handle them on client side etc...

Now add some customer area...

Add a few more features and it becomes complex.

Why would you want to now throw away all this and rewrite in react when you could just start with react.

In addition I can even migrate my old app to the new one and sometimes I can just copy paste certain components and css styles (thanks to css in Js) and it just works.

Honestly I don’t want to write responsive images manually. I just wrote a system once, now any app reuses the same thing. Same for other stuff. Plus I only need to know react and I can build anything.

You telling me now to learn htmlx syntax and use it sometimes, then use react other times just because… it’s simpler. The benefit is minimal, but now I need to know 2 worlds: react and htmlx.

Not meant as a criticism, but if this is the way you build websites, you are doing it wrong. If you are building a website in a way where you can not anticipate beforehand what will be needed a few steps later because you skip the one most essential step — the planning phase — you are gonna have a bad time.

Of course customers change their mind constantly, which is why you anticipate this in you choice of architecture to leave some wiggle room. The scenario you described tho: I never even remotely had a situation where it bit me in the arse that I wrote HTML with JS sprinkled in. For more complex stuff I have flask, django, websockets, htmx, custom REST-APIs I can built in any other language interacting with custom JS on that webpage (most of the software I write is server side). Or I could just take something like Grav CMS and write a custom Theme and some plugins for it. What is a good starting point depends on the kind of website.

There is so many ways to skin the cat it is not even funny. And if you don't know what cat it is beforehand it is your fault for not asking.

You are not going to be promoted if you quickly build something using simple tools. Complex and overengineered systems is where the golden opportunity is.

Reply on news.ycombinator.com