8 ms·

(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 wonderin

• veeralpatel979 7y ago
  I love reading about people's first principles technqiues of different technologies on HN! What do you think React will be supplanted by?
  • onlydeadheroes 7y ago
    jQuery, when people stop fucking around and start making sites that work again.
  • Thorncorona 7y ago
    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.
  • ma2rten 7y ago
    Maybe something like svelte?
    • iluvblender 7y ago
      I just started studying svelte today (alongside Vue). I look forward to sharing my thoughts soon.
      • Can_Not 7y ago
        Things I wish I knew about Svelte: error handling is fragile and/or non-existent.
        • iluvblender 7y ago
          I will keep that in mind, Thank you :)
  • runawaybottle 7y ago
    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.
  • colordrops 7y ago
    web components when they finally mature.
  • aaronbrethorst 7y ago
    HTML is pretty cool.
  • veeralpatel979 7y ago
    Meant to say critiques above, not "technqiues"
• deleted 7y ago
  [deleted]
• efdee 7y ago
  These are all very, very weird points to raise, except maybe the SSR which is inherently hard to do.
  • irrational 7y ago
    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.
    • gherkinnn 7y ago
      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.
      • runawaybottle 7y ago
        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.
    • lumens 7y ago
      You know it's real when it hits you in the feels.
    • baddox 7y ago
      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.
• nexuist 7y ago
  > 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.
  • runawaybottle 7y ago
    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.
  • tomstuart 7y ago
    You can, of course, do the same with React: https://reactjs.org/docs/add-react-to-a-website.html https://reactjs.org/docs/add-react-to-a-website.html
    • terenceng2010 7y ago
      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.
      • nexuist 7y ago
        Exactly. I can still use jQuery too, but the whole selling point of React is its heavy reliance on JSX.
  • siquick 7y ago
    >> 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 https://reactjs.org/docs/add-react-to-a-website.html
  • 7y ago
• artsyca 7y ago
  Amen! A component is like a bag of poop an HOC is a double bagged dog turd with a poorly documented interface
• andrewstuart 7y ago
  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).
  • dvt 7y ago
    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.
• baddox 7y ago
  > 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.)
• osdiab 7y ago
  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.
  • dvt 7y ago
    > 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.
    • osdiab 7y ago
      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.
• sunaurus 7y ago
  > "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.
  • capableweb 7y ago
    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.
    • TomMarius 7y ago
      But what's so hard/bad? Literally zero config and two commands: npm install -g parcel-bundler parcel ./index.html
      • goliatone 7y ago
        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.
        • 7y ago
• noahtallen 7y ago
  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.
• smt88 7y ago
  > 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.
  • osdiab 7y ago
    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.
• bryanrasmussen 7y ago
  As a general rule, although not a universal one, markup languages are declarative.
• deleted 7y ago
  [deleted]
• ddek 7y ago
  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.
  • ivan_gammel 7y ago
    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?
    • ddek 7y ago
      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?
      • ivan_gammel 7y ago
        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!
• grandinj 7y ago
  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.
• onion2k 7y ago
  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 https://caniuse.com/#feat=es6-module and https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules 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).
• quickthrower2 7y ago
  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.
• axegon_ 7y ago
  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.
• dragonwriter 7y 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.
• aylmao 7y ago
  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).
• lopatin 7y ago
  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.