not that js/react are not useful, but rarely should be your starting point. much better to use them progressively when the trade off are worthwhile.
As a (bad) side-effect, people have stopped creating amateur websites, because it's hard. HTML was easy and fun, and everyone wanted to create their own geocities monstrosity. I'm looking at modern web constructs like WebXR with disbelief: How is it an hypertext standard if it doesnt even involve html tags (it's just a rehash of openGL , but in JS??). Why dont we make it easy for people to make quirky stuff anymore?
Newbies are immediately plunged into the world of npm, react/vue, and AWS.
Gone are the days where the tutorials are “write a page in HTML and FTP it on to a server”
If you don't want to deal with the tool chain, just go straight to the "Include JS build" section. That one line script tag is all you need.
Markdown and restructured text are both easier than HTML.
Very fast, easy to use, me gusta.
https://gohugo.io/getting-started/quick-start/
easier than HTML, that a lot of people learned in school and with which people interact daily? no
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).
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.
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.
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.
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 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.
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
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.
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'm not here to piss on JS frameworks, it's good that devs push the limits of what's possible, I guess. But there's something to say for simplicity and stuff that's so matured that you can really rely on it. Making sound decisions for your product, your stack and your architecture is a skill.
I agree! It sucks that most jobs don't care about paying for that skill though.
Back then it was CSS that was so rapidly evolving nobody could keep up. Remember the ACID tests? And that was even before flexboxes made things both simpler and more complicated.
Then there was the streaming wars, where RealPlayer and Flash and ActiveX and whoever else competed to be able to deliver <video>.
And what we solve now with CSS layouts and React components used to require frames and iframes and sprinkled JS drop downs that spoke to ColdFusion templates served from a single old Apache instance shared between a thousand users and constantly crashed, and https cost like a thousand dollars and couldn't be used internationally...
The web was never simple. We were just younger then and our neurons weren't so degraded yet. /sigh
The HTML and CSS from the nineties require about five times more work just to get the same results.
This is progress.
C#
Python
C++
Django
Git
Jenkins
Docker
Kubernetes
Also while React has the highest market share, it's not the only framework out there.
It's just a corporate hellhole now, with Facebook owning the frontend via React, Google and Apple owning the hardware, and Amazon owning the network.
I miss those one person passion project pages that you used to be able to find on Yahoo.
If you're talking about web sites as art projects, there are communities like that although they are fairly small. Neocities is one of the more prominent ones.
The small web still exists, but you have to stray quite a way off the beaten path to find it.
Like most content is now controlled by, what, 5 to 10 corporations?
2022 - 15 = 2007.... Which means you aren't even in the IE era. Hardly a dinosaur if you ask me :)