[enjikaka]

Tools like Babel emerged to bridge a compatibility gap between the evolving ECMAScript specification and the browser lacking behind implementing the new features. Then some "smart" people decided Babel would be a good thing to transform anything and thus React, JSX and the like were born. The problem emerged and took foot when we stopped polyfilling and transpiling the compability gap and instead built further on the powers of these tools and coupled us too tightly with them.

People need to learn to build on and use the platform. Do NOT learn React, Node.js or Tailwind. Learn HTML, JS and CSS. Use these in your projects and they will work forever.

The standards are backwards compatible and evergreen. Your walled garden withers.

[lloydatkinson]

> Then some "smart" people decided Babel would be a good thing to transform anything and thus React ... and the like were born

Is this a serious comment? You're playing into the typical HN bandwagon of hate on anything web related. React is a library for declarative UI and state management. It doesn't need Babel or even JSX to be used. It can be used in the browser with no build tools at all. Except no one does that, because productivity of tooling is a massive win.

Your complaint about polyfills, transpiling, etc, is just a thinly veiled attack on React because you apparently have some gripe with it.

[parasubvert]

This is terrible advice, on the order of “learn assembly, not C”, or “real geeks compile their kernels with customizations”.

It’s a tale as old as time: the “smart” people are actually dumb, I am the smart one, and so I will build my own framework from the ground up of JS, HTML, CSS as part of my work. And maybe eventually I’ll release it to the world.

This is why the JS community is the way it is - lots of folks thinking they can do better than the last group. This plays out a few times in mature language ecosystems. Sometimes, occasionally, it’s actually true. In the JS community there have been a LOT of new attempts with “just enough” better ideas to form a sustainable community around them. But most of the time this is a wasteful idea: reskilling, reinvention, endless advocacy flame wars, etc.

But such is the tech world, we used to see this with Operating systems in the 80s and 90s before we settled down mostly on *nix.

Doing it all by yourself from base technology is fine if it’s just you and you’re the boss, but is a recipe for an unmaintainable mess that will be hell to deal with and likely thrown out once you leave whatever organization you inflicted your brilliance on.

The JS community is an example of what Happens when there is no strong central body in control of core library and framework maintainability. There are subsets that are well maintained. Use those.

[zelphirkalt]

To compare plain JS and React/stuff with C and assembly, that is a bit much. The comparison of things from so fundamentally different ecosystems is not going to yield a convincing argument.

"Smart" people are actually dump, if they use an overblown framework for something as simple as a switch on a website and thereby destroy normal browser functionality, because most of them do not actually know how to use their hammer.

So once one has carefully considered not using a full blown megabytes sized framework and simply writing a few lines of JS instead, coupled with standard conform CSS and has actually thought about what parts of a website really need to be interactive, then one can still decide point-wise / component-wise, where to use a framework.

The problem in the JS community is a huge load of people, who present their specific solution as a general solution and others who trust them and add dependencies to their project. Putting something like left pad as a package shows what I am talking about. There is no need to have such a simple thing be a package and no harm in writing a single simple function, when one needs it. But in JS ecosystem there are also loads of devs who just started out developing and they are happy to choose dependency after dependency, because it means they can have it now, without having to code it up themselves, even if it should be a simple exercise. That does not lead to being very smart. Smart is, when I can avoid dependencies, due to intelligently coding simple things myself in generally reusable ways, so that it does not impact future development. But with most of the JS ecosystem mentality, people never get there.

[schwartzworld]

> Do NOT learn React, Node.js or Tailwind. Learn HTML, JS and CSS.

How exactly should I use html and css to replace nodejs?

[zelphirkalt]

You don't do server side code in JS and then you don't have a need for Node.js. Easy.

[mirthflat83]

Learning React, Node.js, and Tailwind doesn’t mean that you’re not learning HTML, JS, or CSS…

[lloydatkinson]

I was going to say the same but I think you said it much more clearly than I would have. I see this meme a lot. "I hate X, don't learn X, Y is better because Y is fundamental to Z".

I have not once seen these same people suggesting "Don't learn the toolkit/framework/control library for your OS, instead use raw WinAPI or X System calls and push raw pixels to build applications".

Yet, they push for the same with HTML. How you arrive at the HTML is up to you. By saying, for example, don't learn React, you might as well be saying "don't do anything productively, do everything in the least maintainable and the most convoluted and unnecessary way possible, your customers and team will like that surely".

[zelphirkalt]

Oh in theory you are correct, but in practice once people are given a hammer, everything starts to look like a nail, especially since they do not yet have the basics down well enough and it does lead to them not really learing the basics, because "it also works with React" (no matter how shitty and with how much overhead)

[dmitriid]

> The standards are backwards compatible and evergreen.

They are definitely not backwards compatible. Most of the modern web will be broken on older devices. A few of the newer standards couldn't even be properly polyfilled on some older browsers.

And some of them are definitely not evergreen. Marquee is the one that will definitely spring to mind. But then there was Custom Elements V0 that Youtube was rebuilt in and removed when Youtube was rebuilt in V1. And then there's the push by browsers to remove alert/prompt/confirm.

> Your walled garden withers.

These "walled gardens" use the platform as much as your half-baked lib/framework you inevitably end up with. Because there's nothing else to use in the browser but the platform.

And the platform sucks. It offers almost zero functionality for anything beyond a static text page with a few images on it

[LtWorf]

> Most of the modern web will be broken on older devices.

And the super heavy js websites will work?

[gedy]

This attitude usually results in a company inventing some bespoke abstraction/framework whilst saying they are following standards.