Hacker News Reader

Comment by enjikaka | Hacker News Reader

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.

View on HN

> 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.

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.

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.

> if they use an overblown framework for something as simple as a switch on a website and thereby destroy normal browser functionality

Likely not what you meant, but FYI there is no native "switch" control in HTML - you do need to use a CSS or JS framework if you want something like iOS switch control. QED

CheckBox is a native HTML switch control.

Change my mind.jpg

Your definition of "QED" is quite a funny one.

I don't need a JS framework for a thing, that has 2 states, which can be realized using 2 CSS classes and toggling between them. That's maybe a 3 liner, if at all.

I am not using iOS and have no interest in it, so I have no idea what is so special about an _iOS_ switch control. Since I don't know what is that is, I also cannot really want to have it.

Fairly sure that I could probably find some easy to follow tutorial on how to make something graphically resemble a switch, if a checkbox is not sufficient for whatever reason, if I look for it ... Oh I just found a website which lists 20 of them in pure CSS on the first search query I entered: "plain css js make switch"

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

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

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

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

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".

The difference is, that JS, CSD and HTML are evolving. They now offer way more than they used to. We can do so much with HTML 5 and CSS 3 already. The argument is to not use React or similar, when a simpler way using standard conform means is available.

It is hard to take a comment serious which compares not using React to not being able to do anything productively. It looks like a very junior React-only dev comment.

> The argument is to not use React or similar, when a simpler way using standard conform means is available.

Please show me which part of any current or future proposals show a declarative UI + state + input + template binding mechanism which React or even something like handlebars provide.

If you're going to mention three or four different API's and explaining combining them together, then you've just reinvented a worse X framework.

You can't just dismiss everything as "well you can do X with the native platform" which is literally what I'd already made an analogy for.

> It looks like a very junior React-only dev comment.

Personal attacks, nice. If you believe I'm a junior for my comments then you are free to believe what you want, it does not change reality.

You can buzzword all day long, but that doesn't make the typical React component any more declarative than the next script. Components reyling on internal state, querying that state and then munging some JS code into some HTML-like template and mutating the state again, when a user interaction happens -- That's hardly a declarative UI. It also does not become more declarative due to using an angle bracket notation for components.

One can look at some Prolog code to get an actual idea about what declarative means. In React you are not writing down constraints and logic rules, according to which React automatically figures things out. You are not working with relations, which need to be kept true. React is far from a configuration only kind of framework.

To claim something like one cannot be productive without using React or similar framework is really a silly thing to claim. Most websites do not even need to use any such framework, because in their nature, they are not interactive. They show information and that is it. Then there is a set of websites, which has here and there some small interactive widget, which one could argue to use a framework for, in parts, not for the whole friggin website. This still allows for people, who merely want to retrieve the information and leave without interacting. The third and smallest category is then the set of websites, which actually need interactivity and state in the frontend everywhere, where such a framework can be justified.

> We can do so much with HTML 5 and CSS 3 already. The argument is to not use React or similar, when a simpler way using standard conform means is available.

There are no simple ways to build UIs available in HTML5 and CSS3.

It has neither state handling, nor reactivity, nor any APIs that don't make you tear you hair out (or build another lib/framework).

It's a horrendously bad half-low-level half-high-level API with hundreds of one-off solutions and special cases that form no coherent whole.

You still can't reliably animate adding to and deleting items from a list without hacks because even if you so much as look at DOM, it will re-layout and re-draw the entire document.

It still has no collection of well-specified built-in controls beyond a few primitive ones. https://open-ui.org/ is about twenty years too late.

But sure, you can finally put items in grids now. I guess that's nice. But when you need a dialog element you need copious amounts of hacky Javascript to make it properly accessible. Go figure.

People have built "UIs" on websites for decades, without the current flavor of SPA web frameworks. It is actually very easy to put things like a navigation and forms and such things on a website. Most websites do not need more than that. They merely show some information. Maybe you can register through a form or login through a form to see some more information. Not every website needs to be a SPA. The use-case you are apparently relating to, the one of websites really needing a more complex desktop-like UI, is merely a small percentage of websites. If you find yourself building a SPA on every second project, then you are most likely just following hype.

If you find yourself wanting to put dialogs on a website, consider showing information in a different way, more appropriate to the web. Work on your assumptions of how things must be done and some problems will disappear without ever having to write gnarly code.

Aside from that, writing a dialog is really not that difficult. I've done that before and I didn't need any framework to do it. Just don't rely on its modality for security, obviously, because one does not rely on frontend code for security anyway. Element zapper will make short work out of any dialog, that tries to block the stuff underneath it.

Ultimately the browser is not the desktop. It has a different use-case. Too many people do not understand this and try to shoehorn things into being "like on the desktop". Write desktop programs, if you want the desktop (not Electron shit ...). Write websites, if you want the web and the browser. Both have their own quirks and complications. Trying to force one into the other will only lead to more complications. Good design pays attention to the medium.

> It is actually very easy to put things like a navigation and forms and such things on a website.

That's about 1% of 1% of what people want to build.

> Most websites do not need more than that.

That we can agree on

> If you find yourself wanting to put dialogs on a website, consider showing information in a different way, more appropriate to the web.

dialog is literally a web standard in the web platform you so ardently advocate for. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...

> Aside from that, writing a dialog is really not that difficult.

Tell me you've never built a proper accessible dialog without telling you've never built one.

> Too many people do not understand this and try to shoehorn things into being "like on the desktop".

I can empathise with this sentiment because I've expressed it myself many times. However, that ship has sailed and the platform has not adjusted in the least.

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)

> 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

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

And the super heavy js websites will work?

Not necessarily.

How old and how backward compatible are you thinking?

- Symbol is 2014-2015

- Map is 2014-2015

- Weak* data structures and their methods span 2014-2021

- WebGL 2.0 is 2017-2021

- Custom Elements are 2017-2021

- Chrome-only non-standards (hardware APIs and a bunch of others) are pumped out at a rate of up to 400 per year

- WebAssembly MVP is 2017-2018

And so on. That's off the top of my head. None of them are backwards compatible. Some of them cannot be polyfilled.

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

Reply on news.ycombinator.com