Hacker News new | past | comments | ask | show | jobs | submit login

> hating on React

It would be great if developers stopped treating tools they like with this much sentiment. For starters, it would mean fewer flamewars.

They're just tools, criticizing them is not "hating" and your liking them is no endorsement (for anyone other than you, anyway).

> With low-code backend tooling and React, I can promise you I can make a better website than with just Python no matter how much Django template wizardry one can muster.

How can you "promise" this? How can anyone "promise" this? I'm not even sure I understood what you meant by this. Even more so in this case as the tools you mentioned are geared to different types of applications.

The only way I can parse this sentence is that you're claiming that react is indisputably better at [not sure what you meant to do since you said "website" and a website doesn't need a backend$, but you mentioned backend regardless] than any tool in [whatever other language/framework, clearly, even if you're using Python as example] and I'm gonna need a source on that one. It's a pretty strong claim, assuming I didn't misinterpret it.

$ Technically, a website doesn't need a frontend either; it's debatable whether a website even needs javascript, but certainly not react, which is a library for creating web applications.




> hating on React

What do you call it when someone claims changes to the definition of "idiomatic" usage is the same as being not backwards compatible, incorrectly? I calmly corrected the incorrect statement. There is no flamewar here, but criticizing something incorrectly because of personal bias and lack of knowledge is more or less "hating" in a nutshell

> How can you "promise" this?

Because I am a pro web dev who has made a ton of apps and understands the difference in power between HTML templates and JS components? There are objective standards of user experience and for anything non-trivial a web application is clearly going to be more interactive and deliver the data and workflows in a more user-friendly way. Reporting, workflows, interactivity, visualizations, all are much better when they're done interactively with JavaScript than delivered as some static asset to the browser.


>Because I am a pro web dev who has made a ton of apps and understands the difference in power between HTML templates and JS components

so what you're actually promising is you can make a better website with React than with Django for any website that needs advanced JavaScript interactivity - but then obviously the comparison would not be between Django and React but between React and some other JavaScript based frontend technology.


> What do you call it when someone claims changes to the definition of "idiomatic" usage is the same as being not backwards compatible, incorrectly? I calmly corrected the incorrect statement.

A) I have a very different interpretation of the other person's comments• and I don't see anything factually incorrect in them, b) I would call what the other person said criticizing even if I vehemently disagreed, if just to keep the discussion productive, and c) there was no specific "correction" of anything in the comment I replied to; you only expressed that you think react is stable.

> understands the difference in power between HTML templates and JS components

Those HTML templates don't exist in a vacuum and are invoked by whatever language is being used in the backend. The only "advantage" javascript gives is that it saves you the blink of reload; beyond that, the logic of a web application doesn't change in the slightest regardless of where the html is being rendered.

> There are objective standards of user experience and for anything non-trivial a web application is clearly going to be more interactive and deliver the data and workflows in a more user-friendly way

The GCP console is a gigantic mostly angular based single page application. The AWS console is mostly a jsp based server side application. You know what they have in common beyond being dashboards for managing cloud platforms? They're both unwieldy giant hodgepodges of work by a multitude of different teams.

There's no silver bullet.

You have a preference for single page applications. That doesn't mean a user is going to like an unusable SPA more than a well architected server application more just because the SPA saves page reloads.

> Reporting, workflows, interactivity, visualizations, all are much better when they're done interactively with JavaScript than delivered as some static asset to the browser.

I originally asked for a source of your claims, and I would really like to see your data for this.

Let me turn your original claim on its head: With proper backend tooling (be it Rails, or Django, or whatever else) and a low-javascript, progressive enhancement library like htmx, I can "promise" you I can make a better web application than with just javascript, no matter how much JSX hacking one can muster.

But I don't actually believe that, because it's better to use the right tool for the job. Sometimes an SPA framework is the right tool, and in that case I'll go for vue or svelte. After all, they're vastly superior to react ( ;) ).

• For starters, most of them were about the javascript ecosystem in general; for that matter, you've been focusing on react more than anyone else in this exchange.


FWIW, I am not against SPAs, either. I actually prefer using them in most cases if I can help it, because it pushes me toward building out an API that is not coupled tightly to my web front-end, and can be reused if I ever need to serve a mobile app, etc.

Also, you are correct that I was not initially dissing React specifically. The amount of churn in the Node ecosystem is a real issue, and I am always getting those vulnerability emails from GitHub for old, forgotten repos where a dependency I never even knew I had is problematic.

Deno recognizes this is a serious problem, with one of the bullet points at the top of the home page touting "a set of reviewed (audited) standard modules that are guaranteed to work with Deno: deno.land/std". Deno was started by Ryan Dahl, who also invented Node. I don't know if he's said this explicitly, but I would imagine he had his own Dr. Frankenstein moments with Node.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: