Comment by eawgewag | Hacker News Reader

Comment by eawgewag | Hacker News Reader

Parent Full thread

I honestly think this conversation gets overly complex because we fail to define the kind of websites we are talking about. These are my definitions, so I'll just share them upfront:

- a web site -- which has low interactivity requirements. Blogs, documentation sites, etc, go here. A vast majority of websites are in this bucket

- a web application -- which has high interactivity requirements. Things like Gmail, Linear, Google Calendar, and an enormous amount of SaaS apps fit in this bucket of things.

React is better at anything else at making the second. React developers happily pay the weird tradeoffs that come with it in order to efficiently develop the second.

React is pretty reasonably good at making the first, but the negative costs are more obvious.

As someone who has worked on one of the most consumed React apps in the world (Discord), I think the concerns with React are overstated. People want a good product, they don't care about the framework and it's costs. React is one of the most efficient (in terms of developer productivity) ways to get there.

I'm not a React loyalist; I would love to see someone dethrone React. My ears are always to the ground for new developments in technology. In my opinion it hasn't happened yet, but I would be surprised if it never happens.

> a web site [...] a web application

But is that not the crux of the article? So much of the web is the former but is built and distributed as if it's the latter, with all the end-user downsides that entails.

Honestly, that wasn't clear to me from the article, and judging by the comments section to this post, I don't think I'm alone. That's part of why I advocate for defining these terms up front, because one person is talking about whether or not Linear should be in React, another person is talking about whether or not Linear's docs should be in React.

> React is better at anything else at making [a web application]

Mithril.js beats it in my opinion.

I’m sure many developers would argue in favor of other libraries over React.

React is simply the most popular.

Being the most popular comes with big benefits. There are far more articles about how to support issues that you run into, and many more libraries available for your use. While other libraries maybe "better"in some cases, giving up the support of the large community is a big cost.

No argument there. But “better at” implies something inherent to React’s design rather than to its community.

I'm glad you like it, but https://mithril.js.org/simple-application.html is some "uh-huh, thanks but no"

Care to be specific? Is it the documentation you don’t like? Is it the example application’s design you don’t like? Or is it something about Mithril itself?

Two things, in descending order of rage-close-tab for me: that m(.., [m(), m()]) is deeply unserious, and .then((result) => User.list = result) just seems oppressively singleton (although I'm open to that being a tutorialism but why even show users antipatterns if that's not how it's going to work for real?)

I tried to be neutral in my reply, so if you like it then I'm glad for you, and I hope your colleagues find gainful employment when they have to go to their next job that also uses Mithril. But I hope I never ever have to work in an organization which thinks a shitload of m() functions is easier to read than JSX

Yes, that whole page you cited is simply tutorialism.

And Mithril supports jsx. (Not to mention the advantages gained by avoiding JSX in favor of hyperscript)

Might be best to actually use it in a small (or large) application of your own design rather than judging prematurely.

(I’m not suggesting large orgs use Mithril, as other commenter mentioned, community in some situations is more important than the tooling. But “building a web app” does not necessarily imply “employing a team of local developers to build a web app asap for less than x usd”.)

JSX vs hyperscript is a religious issue. You can use JSX with Mithril if you prefer (after all the m() thing is what JSX compiles to).

He spent a chunk of the article defining exactly those terms.

I know we're not supposed to accuse people of not rtfa but sometimes it's a struggle.

Said this somewhere else, but: honestly, that wasn't clear to me from the article, and judging by the comments section to this post, I don't think I'm alone. That's part of why I advocate for defining these terms up front, because one person is talking about whether or not Linear should be in React, another person is talking about whether or not Linear's docs should be in React.

I don't appreciate the rudeness. I wasn't rude to you or the author, don't see any reason for you to be rude to me.

I apologise for my rudeness.

> and an enormous amount of SaaS apps fit in this bucket of things.

Let’s not get ahead of ourselves. An enormous amount of SaaS’s _wish_ they were a web app. A good chunk of them would probably have a net-better UX by dispensing of this delusion.

Reply on news.ycombinator.com