Hacker News Reader

Comment by dvt | Hacker News Reader

(Opinionated post ahead...) React is, imo, garbage, but alas it's here to stay -- you know, kind of like Spring or Swing. In 10 years we're going to be wondering how the hell we ever used React 8 hours a day way back then. These kinds of markup frameworks/libraries were touted as jQuery's successor, but, from an architectural point of view, jQuery is by far their superior.

"Everything an HTML tag" is an insane mantra to have. As author points out, what in the world does a <Query> tag even do? It might make sense to us because we're used to it now, but the semantics of a tag is completely lost in this "new way" of using them (don't call it declarative because that's not what it technically is; it's markup). These days I'm creating HOCs on top of HOCs to support different behavior (from redux stores, to authentication HOCs, to "don't render this thing on the server" async components). It's, simply put, a terrible idea. And everyone just bought into it because the guys at Facebook must be really smart.

The lifecycle hooks are just confusing and unnecessary. They are side-effects of over-engineering. And to add insult to injury, they change every few versions (so old code will inevitably break on new React versions).

SSR. I've brought this point up on HN before, but doing server-side rendering in React is absolutely ridiculous. Every time I need to implement it, I'm constantly battling async stuff, state management, webpack/babel, hot module reloading issues, shimming `window` or `document` on the server side, etc. Boy do I miss the days when I was building stuff in PHP and HTML was simply rendered when I ran the damn thing.

It's crazy to me that it's normal now to have like 3-4 compilation/transpilation steps when working on a simple JS-based app.

View on HN

I personally find “the HTML is a function of its inputs, internal state, and nothing else” to be a much more predictable model for writing large web applications than, “anybody anywhere in your code can pull the rug from under you arbitrarily with jQuery”, and for that alone I prefer the React development experience.

With Hooks I’m happy in that most of the “business logicky” stuff can be split out into those and my components have returned to being pretty much entirely UI code - I don’t really use any of those weird in-between tags like <Query> anymore.

Transpilation will happen if you want to use new JS features at all. If you use React without JSX and not using any ES6 features, then you can certainly support old browsers without those transpilation steps - just include the compiled CDN-distributed script in a script tag like jQuery, it’s even advertised in the React getting started docs. Just turns out nobody wants to do that.

I agree that SSR is a crazy story though and I hope someone makes something better - but jQuery doesn’t really help with that at all, bootstrapping state from a different machine than the runtime and not incurring state weirdness/security vulnerabilities seems like a generally difficult problem, not a React-specific one. NextJS (and maybe prerender snapshotting) seems like the only decent options right now.

> I personally find “the HTML is a function of its inputs, internal state, and nothing else” to be a much more predictable model for writing large web applications than, “anybody anywhere in your code can pull the rug from under you arbitrarily with jQuery”, and for that alone I prefer the React development experience.

Respectfully, that's not at all what HTML is supposed to be, but even so, as it turns out, sometimes you do need state to drill pretty deep down (say you need an icon to be green if you're authenticated). So people started just passing state as props everywhere, but oh no that's an anti-pattern. So now people are using redux, mobx, or the context API to do essentially the exact same thing. Three new tools were developed by dozens of engineers to basically re-invent "global state." It's ludicrous.

What do you think HTML is for?

If you want the hypermedia-concept of mostly static documents with links to each other, feel free to turn off Javascript or not use React.

If you’re using the web as an application delivery platform that works cross platform without installs and instant updates, then HTML is the base of your UI framework, and as such it helps to have predictability that frameworks like React offer.

Re state, for me the “bad thing” about global state is usually the same “bad thing” about jQuery-based apps - that anything can mess with anything. But all the solutions you mentioned, and especially the Context API, force components to declare their dependencies and update shared state in restricted ways, which makes that “bad thing” much less bad.

If you don’t like shared state at all, feel free to not use any of those, and pass around state throughout the app - but don’t complain to me when synchronizing state throughout your web app becomes a problem, or that boilerplate becomes a drag, because those are the problems these solve.

Let’s put it straight: HTML is a Hypertext Markup Language by definition, it’s not an application UI markup language. We are living in a very confused world where inappropriate standard is used just because nothing better got sufficiently big market share. ES, TS, CSS, all the libraries and frameworks in the ecosystem are all just attempts to make the whale fly. For last 20 years we should have been focusing on building semantic web on HTML, while RAD tools should have been standardizing APIs and UIs across platforms on different, probably similarly looking standards (I’d prefer seeing there some DSL with C-like syntax). Unfortunately we have to deal with what we have - jquery, React, Angular etc, the tools that have not invented anything that we haven’t seen yet, but which pretend to be a silver bullet for solving complexity which should not exist in the first place.

On that I agree, I do wish there was a better cross-platform application UI platform. But it doesn’t exist, so as such beggars can’t be choosers.

It would be a strange choice to not use the best tool for the job because one of the acronyms that’s related to that tool stands for something that for historical reasons doesn’t precisely describe the job.

Agree. My point is that it's the best available AND the worst among those which could be standardized.

Totally agree! Additionally I think it goes beyond HTML, it is also HTTP protocol that has been bent and hacked to make proper event-based UI to work with (originally) stateless request-response concept in responsive and secure way. It often deeply frustrates me when I find myself struggling to solve some stupid problem that was completely non-issue 20+ years ago when I was writing applications in Delphi on Windows 95. What happened, guys?

Browsers also don't provide the necessary tools to actually build interactive UIs without reaching for external libraries. If you want to allow the user to select date or time in a decent user-friendly way... you just have to pull some JS thing in. Dropdowns/select boxes still only provide the most basic capability; multiselect sucks, need to pull in another JS thing. The list can go on.

Even if your application is 90% non-interactive, the remaining 10% could end up introducing a lot of complexity only because browsers haven't advanced on that front at all in the past decade. And that 10% could easily outweigh the 90% when it comes to the architecture of your application - you get frustrated with the jumblefuck of JS littered randomly around to support X feature on Y page and so you just grab React and build a more manageable thing with it.

The standards committees for the Web have seriously dropped the ball.

> using the web as an application delivery platform that works cross platform

Therein lies the problem, understandable as it is. If you're using React (or any other modern UI/MVw/whatever for that matter), you're still describing your app as mutating a grossly inappropriate scene graph of divs and spans held together with CSS tricks when your conceptual model is probably more adequately represented in terms of panels, fields, and canvases. On top of that, you pick about the weakest language out there, and over the course of decades, morph it into becoming more like a real programming language with runtime type info, accidental async patterns, decorators, compilation pipelines and whatnot, giving up the two benefits that JavaScript has, namely ubiquity and running OOTB on browsers by simple page reloading.

It doesn't take much imagination to see that in a deep component hierarchy, drilling down states as props is a maintainability nightmare.

> So people started just passing state as props everywhere, but oh no that's an anti-pattern

It's not an anti-pattern because of some abstract aesthetics, it's a pragmatic management nightmare in practice.

> So now people are using redux, mobx, or the context API to do essentially the exact same thing.

Not to do the same thing, but to improve management of it.

> Three new tools were developed by dozens of engineers to basically re-invent "global state." It's ludicrous.

Why is it ludicrous that engineering effort goes into solving pragmatic problems with how things that have always been possible are done?

I don’t understand. Prop drilling or global state libraries like Redux don’t change the fact that the HTML of your site is a function of its inputs. Those are just two different ways to implement this concept of the HTML being a function of inputs.

Use your example of the icon that’s green if you’re authenticated. With React (regardless of whether you’re prop drilling or using something like Redux and context), you just update your state with isAuthenticated: true and the changes to green. There should only be one way to set that Boolean, and the icon will update regardless of where that Boolean is set. That’s all that’s meant by this concept of HTML being a function of inputs.

I don’t really care what HTML is supposed to be.

The SSR data fetching story really isn’t much different than the story for managing global state in React on the client.

It’s true than a client-side React application could just do AJAX requests on component mounts (or in a useEffect hook) to keep that data in local React component state, and that wouldn’t easily translate to React SSR (because the server renderer can’t know when your component tree is “ready”).

But most complex app-style web sites are already going to need some global state management similar to Redux, where data fetched from the network is stored not in local React component state but in a global store, and when you have that (as well as a JS router, something else you’ll probably be needing anyway), the React SSR story really isn’t that crazy at all.

There’s other problems too - all components need to be runnable serverside (which adds complexity to otherwise simple operations on the dom), forcing yourself to put all state into a redux store even if you’re not planning to share it is more unnecessary boilerplate/overhead - and there isn’t any clear canonical way to achieve this for arbitrary apps.

I’m finding it tricky to implement cleanly in my company’s fairly large React codebase, though I do think the fundamental problem is not a simple one and requires tradeoffs.

It’s true that there’s no official React guidance on doing this, and doing so would probably require official React choices for routing, global state management, etc. which the React team is clearly not interested in doing.

But there are popular frameworks like next.js that have pretty simple patterns (like getInitialProps) that can probably be adapted to any React codebase.

I don't really understand why suspending server rendering to load data is still an unsolved problem for React. Ember figured this out 4 years ago with FastBoot.

It’s not an unsolved problem. There are very many React apps with SSR, and popular frameworks that use React and provide straightforward SSR data fetching patterns.

They don't suspend the render though. The main options, like with Apollo/Relay essentially have to do a double-render.

> These kinds of markup frameworks/libraries were touted as jQuery's successor, but, from an architectural point of view, jQuery is by far their superior.

I think everything in this sentence is incorrect.

jQuery started out as syntactic sugar to smooth over the cumbersome and inconsistent DOM manipulation APIs in various browsers.

No one ever seriously says React is a replacement for jQuery. It was a replacement spaghetti-and-meatballs on top of jQuery, Backbone, Knockout, Angular, and whatever other frameworks were popular at the time.

> It's crazy to me that it's normal now to have like 3-4 compilation/transpilation steps when working on a simple JS-based app.

This has nothing to do with React. To get a sane dev environment, you have to do these steps even for a simple site. It's a consequence of browser standards moving slowly and of JS and CSS being awful.

If I can't write front-end code (even for a simple static site) with a decent Webpack flow, TypeScript, and SASS, then I'm doing a lot more work and delivering a lot later. Those tools can be buggy, but most of the time you can just stick with some boilerplate and not end up with anything terrible happening.

> Boy do I miss the days when I was building stuff in PHP and HTML was simply rendered when I ran the damn thing.

You can still do this with PHP (or any other server-side language). It's still a first-class citizen of the .NET world.

Agreed with this - I think it all stems from the browser standards issue, which to me is a general issue about distributing control. It’s design by consensus, which naturally takes a long time, and forces updates to web standards to be conservative and backwards compatible in perpetuity to support every random stakeholder, which is a great recipe for a bloated and abused platform.

So at the core I chalk the situation up to people problems, not technical ones.

> "Everything an HTML tag" is an insane mantra to have.

I don't think this is a React mantra at all. Maybe "everything is a function" would be a modern React mantra? Seeing how React code is mostly hooks and components, and both are nowadays generally written as functions.

JSX is not even required when writing React, by the way. It's just syntactic sugar.

> It's crazy to me that it's normal now to have like 3-4 compilation/transpilation steps when working on a simple JS-based app.

There's nothing about React that requires this. You can simply include the react.js script at the beginning of your HTML document and write all the React code you want, no transpilation required.

If you want to use JSX, then you need transpilation, but again, JSX is not required to use React.

You seem to confuse "normal" with "required". dvt (correctly) states that "it's normal now to have like 3-4 compilation/transpilation" which is indeed true for most React codebases (open source and not) I've came across. In fact, I don't think I've come across a single React application that is seriously built without using JSX and without a bundler (like including react.js in the beginning of HTML).

While not required, most people use JSX + bundler, at least for anything that resembles a serious application.

But what's so hard/bad? Literally zero config and two commands:

    npm install -g parcel-bundler
    parcel ./index.html

It adds complexity. Software rots faster. You are more likely to git clone a 7 year old front end project and be able to run it successfully than a 7 month old project. It’s hard to find projects that successfully pin versions down so that you can build them after regular work on them has stopped.

I have projects from 7 years ago that got dependencies stuck on an old major (that's the default) and the webpack I put there in 2013 still successfully builds. The original versions are noted in package.json, so all you might need to do is fix it to the minor/patch (1min task with search/replace). I wouldn't be afraid of parcel - you can do the same thing.

Those two commands are not just "zero config and two commands", think about the entire stack you're pulling down behind the scenes. Sure, it's easy when you want to render "hello world" but there is so much context and abstraction happening here, that is hidden. Then we haven't even started thinking about HOCs, SSR and lifecycle hooks, none of them addressed by your terminal snippet.

Actually everything is done after this. This is the way I am building a huge SaaS project. Of course it downloads some code, or would you argue that using Javascript is not simple because it needs to run in a browser? Server rendering is trivial to set up with Parcel, but I don't see the point of your remark - you don't have any option of server side rendering with Jquery.

People who use React tend to want to use modern browser capabilities - and anyone who does will need transpilation because browsers have different API support - the cost of not having an all-controlling monopoly.

People developing on other platforms love to complain about the build tools on the web, but those same people only have the luxury of simpler build pipelines because they have greater control over the machines their code will be run on.

I don’t see React as having caused this problem in any way (feel free to include React via a script tag from a CDN and worry about the compatibility of your code yourself), and I also don’t see this as a problem that will go away any time soon for web development.

That all said, I do think it’s getting better - all the major browsers have switched to be auto-updating, so it’s feasible for many projects to drop support for IE altogether and only support ES6; if you manage your CSS in JS, you don’t need to downcompile languages like SCSS; the two of those together mitigates a lot of the need for sophisticated build tools.

Couldn’t that simply be because bundlers/compilers are really nice and that’s why people choose to use them despite the fact that they’re optional?

>JSX is not required to use React

Everyone keeps repeating this, but looking at a pile of 'createElement' calls is so much harder to read than just looking at a page of html.

And so you introduce a simple build step to improve your development experience.

There are a lot of libraries to it more readable:

https://blog.bloomca.me/2019/02/23/alternatives-to-jsx.html

If you don't want to use any of them, convention is to use:

    const h = React.createElement;

I don't know of anyone who actually uses `React.createElement` directly.

Personally, with all the other things needing a transpile step (TypeScript, and support for older browsers), I've just gotten used to having one in every project nowadays.

Hooks, to an extent, improve some of your complaints. For example, with hooks, lifecycle methods are gone and you’re forced to use “useEffect”. This helps you rethink if you needed that side effect in the first place. Additionally, it allows you to remove HOCs. Today, I just refactored a lifecycle-side-effect-filled HOC into a simple hook and I think it reads much better. Plus, it doesn’t confuse the fact that the hook has nothing to do with rendering and so it doesn’t abuse markup tags.

> from an architectural point of view, jQuery is by far their superior.

What do you mean by this? The architecture of the sites I’ve worked with has been much improved by React. jQuery mostly seemed to be used for direct, script-style dom manipulation, which you can do with plain JS these days. You did it in so many places across your app that it was impossible to tell what caused what change and it isn’t immediately reactive to data source changes either. So from an architectural point of view, it certainly didn’t help your code. React is solving a problems that jQuery doesn’t claim to solve.

If you’ve got a basic website that needs a tiny bit of interaction, definitely use plain JS. But if you need to build software running in the browser, you’ll run into the kinds of problems that jQuery and plain JS don’t solve out of the box. If you don’t use a modern library, you may end up writing your own state management and reactivity later anyways.

> simple JS-based app

I’m glad I made it to the end. Why use React for a simple JS-based app when you’re very aware of many reasons you don’t like it for this purpose? If you’re being forced or pressured to by an employer or even the entire job market, that’s not really React’s fault other than for existing.

React (at least many of the features and use cases you mention) is for complex applications and developers that care deeply about the hairy details of user interfaces. (It’s also pretty easy to use without a build step for simpler applications, but that’s another argument.)

It's crazy to me that it's normal now to have like 3-4 compilation/transpilation steps when working on a simple JS-based app.

You don't need a bundler. All the major browsers will run ES6 modules these days (https://caniuse.com/#feat=es6-module and https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...). We use bundlers because we still target older browsers and a lot of library code isn't in a format that works in browsers yet (and probably never will be in a lot of cases).

These are all very, very weird points to raise, except maybe the SSR which is inherently hard to do.

Not if you've been doing web development for a few decades, which I feel the author probably has. I feel like people who came into web development during the past decade really don't understand how much simpler and easier things used to be. It really feels like web development has become crazy complex without much added benefit.

I will never ever go back to the jQuery or vanilla js days.

It might have been simpler (what ever that means) but the result was a nightmare to maintain and add to.

I’m prepared to go back as the developer I am today versus the developer I was before.

It’s almost like just when we’re ready to write some dope Jquery code, it’s time to go write in a new framework.

I can say for certain the best React code we will all write will be 5 years from now, but, it’ll be time to move on to the next one.

You know it's real when it hits you in the feels.

It’s not more difficult now to make dynamic server-rendered web sites than it was 10 or 20 years ago (I don’t know about PHP these days, but it’s never been easier to start a new Django or Rails app), but your clients will probably want features they’re accustomed to in modern web applications that are not easily implemented in server-rendered web sites.

What kind of features require you to use react?

None require React specifically, of course. I’m only referring to the dichotomy between server-rendered apps and apps with significant client-side interactivity.

I sincerely think that dichotomy is not a useful one - that's not a choice you have to make. You can have server-rendered apps with significant interactivity (where it makes sense).

Many large websites still use server side rendering (in whatever language they want), and js to refresh data client-side as required and respond to user actions, pulling data from the server side. There is no need to attempt to move everything to client-side, it doesn't make the UX better IMO, sometimes it makes it worse.

Keeping most logic and templates server-side works just fine on large complex sites serving millions of people, and it's significantly simpler and more stable for development than react or other frameworks, which seem to be in a permanent state of flux.

I should be more clear. I mean the dichotomy between a web site that is only rendered on the server (which is not more difficult to build now than it was 10 years ago), and web sites that have significant client-side interactivity (which are usually and understandably more difficult to build than the former).

Of course, there are different versions of the latter: you can have an entirely client-rendered site, or a site that runs largely the same client-side code on the server for initial HTML renders (like React SSR), or a site that renders HTML from the server and then has separate client-side code to enhance interactivity, or any number of combinations of these and other approaches.

Certainly, the software we write for the browser is much more complex these days. Sure, plenty of website don’t need react and shouldn’t use it. But many of us find react very useful because we are building software with similar creature parity to desktop apps, which wasn’t the case in the early days of the web.

Not only that, but the “simple sites” that used to need a dev to build (like for a local restaurant or business or something) can now be done by the restaurant owner on WordPress.com or Wix or something without much effort

I have been doing web development for over two decades now, and honestly things were only simpler if your expectations were much, much lower. If you have the same expectations today, everything is still just as simple.

If you see no added benefit to having your page run in the browser, then by all means do things the old way, and you'll find that even doing the things the old way is today much simpler than it used to be.

If you do want to create a web application that for a large part runs in the browser, I can only see things getting better every year. The perceived added complexity is simply because we are now doing stuff that's more complex.

TL;DR: Building horse carriages was a lot easier than building autonomous cars.

I started my career with jQuery, and soon after moved to Angular v1. There was nothing simple about those tools - the mental models involved were complex, different parts of an application were difficult to isolate from each other and optimizing performance was a nightmare.

Compared to all that, React is ridiculously simple - it has a very small API surface, different parts of your app are isolated by default and performance optimization is generally very straightforward. As somebody who really loves simplicity, React is by far my favorite UI library at the moment.

I think when people fondly remember simpler times with jQuery, it's not because jQuery itself was simple, it's just that they remember working on less complex applications.

When people say "web development used to be simpler", they're probably not referring to the front-end tooling (which has certainly improved) - but when most of the functionality of web apps were built and rendered on the back end, with new state being displayed after full page refreshes or simple AJAX calls.

> when most of the functionality of web apps were built and rendered on the back end, with new state being displayed after full page refreshes or simple AJAX calls.

Most websites (including this one for example) still function that way. It works fine. JS frameworks simply are not required for most of the work the web does nowadays - you can add interactivity and immediate feedback where it makes sense very easily with vanilla js.

completely irrational comment - the web of the past was garbage and simplistic, and no amount of spaghetti jquery will ever change that HN is full of "le wrong generation"and nostalgia blinded devs who think everything in the past was better when it was complete rubbish just like the 90s

Ending up with HoC on top of HoC is also an extremely salient point. While it's not strictly required, the structure of larger React projects highly encourages you to create or use non-visual higher order components to manage connections to state stores, APIs etc - or make use of the Context API to achieve the same result.

In both cases, you end up with non-UI wrapper components to provide the plumbing in a tree of components that would ideally be entirely presentational. That leads in turn to trying to separate presentational vs. container components, trying to avoid nesting any kind of container component within a pure presentational component to keep it easily testable, creating more HoCs in an attempt to separate concerns, etc.

I certainly wouldn't describe React as garbage like the OP - but I think whether it's the best choice is heavily dependent on the kind of app you're building. The design choices it has made comes with significant challenges and trade-offs and we should not pretend otherwise.

Higher order components haven't really been a thing since hooks were introduced though.

True, but it's important to remember hooks were only released about a year ago - many large projects in existence before then will either not have migrated or be in a state of partial migration.

I'm glad they're putting the effort into making the API simpler and easier to use to address some of those concerns, but React itself has been around for seven years now - the vast majority of existing developments will have been started using versions of React created before hooks were introduced.

I very much agree. It just feels weird to complain about a problem that's been solved a year and a half ago.

> "Everything an HTML tag" is an insane mantra to have.

JSX isn't HTML, it's an HTML-like syntax for JS (it's essentially XAML for JS), and React doesn't have a mantra of “everything is JSX”. It has a mantra of everything is JS, and some of it is conveniently expressed in JSX. It does strongly favor a declarative, functional style whether it's expressed in the form of JSX or conventional JS syntax.

> SSR. I've brought this point up on HN before, but doing server-side rendering in React is absolutely ridiculous.

Yeah, it's basically a client side SPA library. You can do SSR with it, and it supports it, but that's not really it's happy place.

> Boy do I miss the days when I was building stuff in PHP and HTML was simply rendered when I ran the damn thing.

PHP is still around and widely used. If it fits your needs better than React, use it.

I understand this is an opinionated comment, but I thought I'd reply because IMO there's some conflation here regarding what "React" is.

> As author points out, what in the world does a <Query> tag even do?

This is not "React". This API was Apollo's decision, but just like you see libraries that lean heavily in the "everything is a component" direction, others don't. I personally use and like React quite a bit, but find this heavy use of HOCs in some 3rd party APIs a little weird.

> And everyone just bought into it because the guys at Facebook must be really smart.

Facebook builds and uses Relay which doesn't do this, which doesn't use HOCs like these ones Apollo does.

> The lifecycle hooks are just confusing and unnecessary.

It's fair to call them confusing if you feel that way, but I don't think you can say they're objectively unnecessary. They've all come pretty handy at some point or another in my use of React. Learning the lifecycle of a React component allows you to effectively integrate it with libraries that were never built with React in mind— I've used D3 + React extensively and and being able to do different D3 operations at different points in the component lifecycle makes it all work seamlessly.

> they change every few versions (so old code will inevitably break on new React versions).

Do they? React is pretty good about backwards-compatibility as far as I have seen. Wasn't the last breaking change with the release of 16, like 2-3 years ago? They also tend to make code-mods available to automatically migrate things, which can come in pretty handy.

> Boy do I miss the days when I was building stuff in PHP and HTML was simply rendered when I ran the damn thing.

I do miss this too (although it hasn't gone away!), but this is not endemic to React. It is really is a traded-off to make when choosing to make a site rendered by JS (with all the advantages and disadvantages it brings) or the server (ditto).

I am suspect of any argument that says React is better or worse than jQuery. The < or > sign will depend on what problem you are trying to solve.

React and optionally react-redux is more complex in itself, but it is really trying to tame app complexity you'd get with lots a jQuery sprinkled around. With react, you can reason about the state of the app, and know the current view is calculated by a (hopefully!) pure function f that maps state to the view.

Don't really see the issue with HOCs. I am not seeing why they are a terrible idea. I think they are quite elegant actually.

SSR I might have to agree with you. I haven't yet understood why it is needed honestly. Is it SEO or something? Or is it speed of deep linking into a 'page' of your SPA.

As for the compilation steps - meh. This sort of stuff is done a lot on the back end in larger projects too - pre compilation steps and wat not. It's not a big deal with a bit of webpack watching.

What is wrong with Swing?

Coz I use it every day, and despite many little deficiencies, it still compares well to other cross-platform toolkits.

It's not made for "simple JS based apps", it's meant for large complex ones. Sounds like you're using React while you literally never had a use case for it. It doesn't mean it's garbage.

In the context of a website, I completely agree with you. No blog needs react. Reddit is worse because of react.

However, given websites aren’t the only use of react I strongly disagree with your overall sentiment.

My organisation uses react in place of desktop apps, and it’s been a game changer for us. We work faster, we train devs faster, deployment is easier, we can painlessly hit everything from desktops through iPads, and we make far fewer mistakes.

I really don’t see an alternative, at least outside SPA-land.

This is that moment that proves we’ve made no progress on desktop. In 1990s we had Borland Delphi and CBuilder, in 2000s we had .Net and Qt, now this? How on Earth this is better?

Could you explain why, in terms of the reasons for react I gave in my previous comments, any of your suggestions are better than react?

We can look at this from multiple angles. Everything I write below is not React-specific, but concerns all browser-based applications (by browser-based app I will mean here both SPA websites and SPA wrappers).

1. UX

SPAs do not offer native user experience and it's generally harder to provide it on all platforms at once, even with solutions like Cordova or React Native. Usability and accessibility requirements differ, interaction patterns differ, and sometimes you have to produce completely different designs on desktop and small touchscreen devices. On desktop specifically there's a rich history of rapid application development tools and UI frameworks aligned very well with platform guidelines and design patterns. Native development on mobile still beats everything else when it concerns UX.

2. Development

The development cost for browser-based apps and React specifically is definitely one of the lowest, due to popularity of this technology and availability of the tools. RAD and technologies like JavaFX can be inexpensive only if you already have the team familiar with the stack.

The development speed of RAD tools was and still is impressive when it concerns UI. The interactive prototype of a screen created in 15 minutes in a visual tool IS the application that can run. All you need to know as a developer, is the component library and programming language. I do not really see, how React could be better here. One big advantage of browser-based apps is ability to develop both for desktop and mobile platforms at once, but this has UX consequences (see above).

The architecture of native or imperative-style frameworks is generally better than of any of JS solutions. JS ecosystem tends to reinvent the wheel by gradually introducing best practices which are pretty standard everywhere else for decades. E.g. it took some time to build Redux, which is quite similar to the UI event dispatching mechanisms in Java and the like, but uses its own unique terminology - reducers, stores etc - for what is actually a combination of classic design patterns like Observer.

3. Deployment and support

One major benefit of SPAs is instant delivery of new version to all users, achieved by design, but the SPAs packaged in desktop wrappers do not even have this benefit. Also, is mitigated by the existing approaches on distribution of standalone desktop apps via update infrastructure (which also allow canary deployments).

One of the rarely visible costs of WebView apps is the resource consumption on the client, which is usually ignored by the developers of online services. Browser engines are not the most efficient VMs for running application code and they require A LOT of RAM. Just compare Slack and mIRC - similar chat functionality (Slack may have better support for rich content and integrations), but how different they are in utilization of resources!

Do you have to work with it?

Have you considered getting a different job? (obviously easier before pandemic, but from the sound of it you have been in this boat a while).

I do data engineering these days, but I use React/Vue (and a tiny bit of Angular) fairly regularly on side-projects, at hackathons, etc.

> It's crazy to me that it's normal now to have like 3-4 compilation/transpilation steps when working on a simple JS-based app.

This is why I stick with Vue. One <script> tag later you're good to go, and all of the extra stuff (like .vue files) isn't necessary to use the framework.

It's a godsend. I can't imagine how many hours I've lost to obscure webpack errors before switching.

What webpack errors are you getting with basic create-react-app?

Any production-destined app is going to have to go through some baseline transpiling, linting and minifying, and CRA really shouldn’t be giving you much trouble with the defaults.

You can, of course, do the same with React: https://reactjs.org/docs/add-react-to-a-website.html

But if one would lile to write in jsx, which is the default in react, the doc still guide you to use a preprocessor for production.

Exactly. I can still use jQuery too, but the whole selling point of React is its heavy reliance on JSX.

>> This is why I stick with Vue. One <script> tag later you're good to go, and all of the extra stuff (like .vue files) isn't necessary to use the framework.

You can do this with React

https://reactjs.org/docs/add-react-to-a-website.html

Done that. My manager finds it so good when he can hot-fix issue.

Just that some third party plugins are written in es6, it would be cumbersome if you need to support ie11 in a enterprise setting.

Also if you have quite a lot of vue components to load, it would take longer time than compile first with webpack in http1.

As a general rule, although not a universal one, markup languages are declarative.

I love reading about people's first principles technqiues of different technologies on HN! What do you think React will be supplanted by?

jQuery, when people stop fucking around and start making sites that work again.

I've gotten by using a templating engine like Handlebars along with jQuery for async behavior for pretty much all of my apps. Reduced the time I spent building UIs a huge amount.

There are actually very few websites that 'require' an app-in-browser experience. And for many of those, clever usage of jQuery plugins works well enough.

Maybe something like svelte?

I just started studying svelte today (alongside Vue). I look forward to sharing my thoughts soon.

Things I wish I knew about Svelte: error handling is fragile and/or non-existent.

I will keep that in mind, Thank you :)

The long term hope is regular old ES7/Next.

One of the reasons the virtual DOM exists is because it really tries to get around the browser limitations on DOM rendering. We were also all trying to manage templates and data binding. If you remove these three things, most of us could architect very simple JS apps with a singleton object.

It’s as soon as you need to define the dynamic template structure, bind data to it, and do everything in a browser performant way, is when we started trading away the simplicity for off the shelf complexity that solves mostly these three problems.

web components when they finally mature.

HTML is pretty cool.

Meant to say critiques above, not "technqiues"

Amen! A component is like a bag of poop an HOC is a double bagged dog turd with a poorly documented interface

I completely share your opinion here. I've had very little encounters with react but in those few 2 or 3 instances, I hated it with a passion. There are many things wrong with it. Some by design and over-engineering, some inherited from the garbage that is js to begin with.

* jsx: I've been very open about the utterly flawed notion that html should be treated as assembly or cobol: something that only old people with long white beards know and use. As a consequence you have to rely on post-market plug ins for your browser just to figure out where element X comes from. As opposed to what the "old people" would do: grep -rn {pattern} which will genuinely give you the answer in a few seconds tops even for even the largest of projects. As opposed to clicking your way through tons of elements in a browser and staring at a second screen to figure out which is which.

* The endless "compilation" just to get something show up on the screen. Not to mention the ridiculous amounts of system resources required to do said "compilation".

* 5-6mb js files. Holy crap!!!!!!!!!!!!!!!

* Everyone's obsession with mocking data. This is in all cases a terrible idea and leads to tons of "well it works on my machine". In essence you end up with two different applications, one being the frontend and one being the backend and you rely on getting everything right and magically turn that into a "they lived happily ever after". Well... That happens only in fairy tales. That's not to say you can't develop both in parallel without mocking data but for some reason I've hardly ever seen people do this.

IMO, the web is turning into a bigger mess than ever because of this. Even bigger than the flash and coldfusion days. IMO all of this needs to be scrapped and re-done. There have been plenty of attempts to replace js with something that is not garbage by design. But all those attempts were greeted with "No, U fragmentin DA web!!". Well yes, naturally. The point of a migration is to slowly ditch a horrible X for a better Y. Annoyingly, because of this, just like react, it seems js is here to stay.

A real shame really, given several much better alternatives. For instance, I used dart(pure, clean dart, no frameworks or anything) to build my personal page and while I still had to rely on transpiling, there's a strong type system which behaves as you'd expect and pure html and markdown. Yes, even for a simple thing, the generated js is 90kb gzipped but given it's entirely self-contained, no additional code needed and renders markdown out of the box, I'm fine with it. Is it ideal? Hell no. Can I add or remove stuff on the go if I ever need to? Absolutely. I may not be able to add an entirely new functionality while I'm hiking or whatever but add a link or something small and trivial without having to install a ton of crap or have a complex ci-cd setup?

1. vim a.html, add X.

2. git commit && git push.

And just like that, 15 seconds later I'm back to hiking. My argument here is that with some additional tweaks, things like these would be significantly more useful and manageable even for large projects than the huge lumps of fat that the "modern" frameworks enforce us to use.

Reply on news.ycombinator.com