28 ms·

I'm one of those "old dogs" who don't quite get the advantage of using React in the majority of the cases it's used. This article didn't really help... > What

I'm one of those "old dogs" who don't quite get the advantage of using React in the majority of the cases it's used. This article didn't really help... > What makes these frontends complex? State management. The frontend “knows” a lot of things, and these things interact with each other in non-trivial ways [...] Example: dark mode support. For example, say your app has a dark mode. All your rendered components must know what theme is on, so they can render the UI in the right color. Back in my day.... you'd slap a class on the <body> tag, and you'd have all you'd need for your CSS to style the rest of the page accordingly. How is using Redux an improvement here? None of the examples of "complex" front-ends would be at all difficult in an old-school "just re-render the page" setup using something like pjax or turbolinks. And in my experience (seeing web pages with > 1MB js files) it'd be faster/more responsive for the end-user too.

jfengel 7y ago
React and Redux are for apps. If you can do it with HTML/CSS, you absolutely should. React/Redux are a replacement for what people used to do with jquery or plain JS. They're not for display; they're for complex interaction of the kind that used to require a native user interface (Java Swing, Gtk, Win32, etc). Javascript is a mess, and the DOM is a mess; React makes that slightly less awful. (Redux is an extension to React to help manage global state; again, it's compensating for just how bad Javascript is.) Bonus: React encourages the use of JSX, a language that makes a lot of behavior look as if you were writing it directly in HTML. You don't need React to use JSX, and you don't need JSX to use React, but they do dovetail nicely. You can write in plain JS/jquery if you want. Plenty of people do. React is a framework to make that a bit easier; that's all.
- the_gastropod 7y ago
  I actually write a good bit of React professionally. I'm familiar. I just have yet to see a very compelling case. And the excuse is almost always this nebulous "rich/complex interaction". And.... I just rarely see any good examples of this. The huge majority of apps (web or otherwise) are not video games. They're forms that submit stuff to a server and get a response. There's sometimes a dropdown here or there.... and that's it.
  - acephal 7y ago
    Mmm, I work on a multimedia sequencer (timeline, viewport, etc) in the browser, it would be utter hell if the whole thing was put together via manual DOM updates in something like a Backbone View render function. I know this because when I joined the company, they were trying to do it in Backbone. For a project of that scope, this was a great way to introduce a large surface for error and maintenance (the project kicked off right when React was launching and Typescript wasn't public). Leveraging React as an interface to updating the DOM removes all of those concerns from your implementation work. That's a big productivity boost when you're trying to build a multimedia sequencer. More so when your team is junior-dominant.
    - Jare 7y ago
      > when React was launching and Typescript wasn't public Minor correction, React came out about 7 months after Typescript. That said, Typescript had a promising birth but a rough infancy, so I wouldn't blame anyone for considering it released only after 1.x versions starting in late 2014.
      - acephal 7y ago
        Yeah, that was bad characterization. This was the first half of 2015.
  - itronitron 7y ago
    I've worked on a few applications with 'rich/complex interactions' and everyone on the team was opposed to using any sort of JS framework. That was nice because it was relatively easy for anyone to trace through the application as needed. In my experience if the application state is overly complex then that is a result of the design, and that usually leads to a bad experience for the user.
    - kqr 7y ago
      In my experience, when it comes to rich interaction, the question isn't whether or not to use a framework -- the question is whether to write your own framework from scratch and discover all mistakes you can make on your own, or use one that already exists and builds on best practises as well as we know them.
- lhorie 7y ago
  I think what GP was getting at is that there's a healthy amount of "if all you have is a hammer" mentality going on w/ React/Redux. The tragedy of commons here is that you _could_ conceivably just slap a class at the root of your React tree to implement dark mode, but if one is using something like styled-components, there's a good chance that the library will get in the way of the style cascading semantics that come for free w/ the browser. And ultimately, the end-user is the one paying the price for all the extra code needed to make a "complexity-friendly" implementation of dark mode work. Another observation that I've been finding interesting about "modern frontend development" is that despite all the arguments about how React makes DOM manipulation easier, people still prefer to defer to libraries to do any non-trivial amount of DOM manipulation rather than actually use pure React to do it. This is exactly the same modus operandi as when jQuery was "modern frontend development" ("it makes it easier to work w/ DOM", plus a ton of opaque jquery-* libs)
  - shadowgovt 7y ago
    I don't see why using libraries for complicated interactions atop React is a bad thing.
    - johnmaguire2013 7y ago
      I'm not sure it's a bad thing - but using a library for DOM manipulation on top of it diminishes the argument that React's advantage is to make DOM manipulation easy.
      - dragonsh 7y ago
        Having used react and modern web components to build webpages. I will agree with the first comment which says what is made so hard by react/redux can be easily done if the pages were rendered on server and delivered to client with progressive smaller bits of JavaScript for dynamic interaction. If state management is so critical to running a react app than I feel Elm/ClojureScript is a better choice than react to build web apps. But I doubt they will be as popular given network effect. Now everyone went on a bandwagon that react/angular/SPA/progressive apps is the only future and plain HTML/CSS/JS mix on server side with specific language templates is dead. I am sure we will again go full circle back as you can see now with SSR (server side rendering) is considered as a norm for performant react or angular apps. SSR combined with complexity of react/redux unnecessarily makes everything complicated (worse than even complex). Instead of doing HTML templates in nicer language on server side now people are forced with half baked solution on client side like JSX or angular templates etc. A developer not just need to learn intricacies of HTML/CSS/JS, but then API's of framework like react, combine it with state management framework, combine it with client side templates, combine it with build tools like gulp, webpack, combine it with NPM, Yarn, combine it with babel compiler, combine it with many testing frameworks. The whole eco-system is very complicated (not just complex). This is one of the reason for emergence of compiler based web application development language and frameworks like Svelte, Elm, ClojureScript, PureScripts. They will still be not popular because there is a network effect of jobs available. So inferior tools for user interface like react/angular will continue to thrive.
- GrumpyNl 7y ago
  I disagree with making it easier. Php, jquery and css will bring you a long way. react is far more complex.
- rorykoehler 7y ago
  I've been writing vanilla javascript on the frontend for a recent project. It's really not bad. Much less cognitive load compared to writing react. Easier to read too
- mesaframe 7y ago
  Is JavaScript is a need making a library/framework over it doesn't make it any better. Also, you stated benefits of Fact without stating how it makes it better.
simonsarris 7y ago
I've always preferred hand-crafted websites with readable view-source over frameworks, but I finally switched to react so I could keep my site's background animations persistent over pages. It' somewhat unfortunate that its still not possible without some JS (in this case, a framework that's swapping out portions of the page).
brlewis 7y ago
I get the advantage of using React for single-page web apps, but I'm totally with you on the dark mode example. The modern way to do dark mode is to assume that people who want it won't be using IE or Edge, and just do a CSS media query. https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
some-guy 7y ago
For individuals making small sites, it's absolutely overkill. For my job, with hundreds of developers working on a giant SPA blob with constant feature creep, frameworks like React are a necessary evil to maintain the insanity.
- WilliamEdward 7y ago
  At what point does it stop being a small site and become a giant app? Genuinely curious cus im wondering if i should make the switch.
  - zys5945 7y ago
    I think it's about the number of developers involved. If you have a small team of 3-5 people who understands the architecture as a whole and can keep up with most PRs then I don't think a UI framework is necessary. However, if you have many teams working on the same project and/or cannot keep up with every single PR merged then I think using a UI framework is a must. It forces you to stick to strict rules. Although you will start writing boilerplate code, it makes the entire application much more modular, and easier to reason about.
    - jf22 7y ago
      With 3-5 people you end up building your own UI framework.
- switch007 7y ago
  React is just a library though. Surely there is much more to your story than React alone?
  - frenchyatwork 7y ago
    Sure, React is just a library, but I don't think I've ever seen it used as just a library.
spion 7y ago
One of the reasons is the difficulty of writing reusable interactive components with server-side rendering such as maps, rich text editors, autocompletes, hover previews, menus. The components work with data. Let's say you need an auto-complete component - 500ms after the user starts typing it will query the server and get some data back. You can describe the returned data in partially rendered HTML too but the attribute-based descriptions are often quite limited and for ease of use from the JS side you're likely to end up with embedded JSON as a general data description language with unlimited nesting, which naturally leads you to a client-side templating language. The components are also likely to re-use each other, giving rise to the need for a module system to track those dependencies and make sure they are all loaded when you go to a specific page based on the components being rendered. If you use partial rendering you would also need to ensure to track any components used from the partial html endpoints have their JS included in the page, capturing any of their occurences, making sure to attach the right event handlers to enable interactivity. Sure, one could ostensibly write a set of components that use JS under the hood and add them to the back-end. They could also write a server-side module system that ensures that the right scripts are included in any page that uses them. They could do all that. But then that would work only for a single backend ecosystem, such as e.g. Rails. There is no way this component library would be able to compete with a unified client-side ecosystem in terms of features, flexibility or battle-testedness. Additionally, if you want to try a different language on the backend, you won't be able to - unless you're willing to pay the overhead of a secondary service meant to only generate the HTML and manage the JS plugin system. And all this is before we even consider alternative clients (e.g. mobile)
- spion 7y ago
  For reference, here is a "simple" app - a parametric EQ designer that supports doing pink noise measurements of speakers (or headphones if you have the right equipment) with FFT in the browser: https://eq.spion.dev/ https://eq.spion.dev/ - works as an entirely static website :) Typically what people say is "oh most websites won't need THAT" but the appetite for interactivity only grows with most companies, so you could easily end up in a slowly boiled frog scenario where your serverside HTML-JS mishmash is an absolute mess.
untog 7y ago
To me there’s nothing wrong with React, but everything wrong with people using it in inappropriate contexts. For instance, I’ve seen a growing trend of people creating a whole DOM using React JSX so that they can use React’s server side rendering pipeline. <body> tag all the way down. But the actual reactive components make up about 30% of the page. So you’re wasting download and JS processing time (a serious concern on low end devices) hydrating a lot of elements that won’t even ever change. It’s stupid and it needs to stop. But for fully interactive webapps, React is great.
- IggleSniggle 7y ago
  ...aren't the static portions uh...rendered server side? And possibly even the dynamic ones cached when common? If not, I'm confused about what SSR means in this scenario.
  - untog 7y ago
    They are rendered statically... then hydrated client side, needlessly, because they’ll never change.
- mr_toad 7y ago
  I don’t understand why you would serve up the React library if you’ve already rendered on the server. I use React server side and then serve the static HTML.
  - untog 7y ago
    Because you still need interactivity of some sort. Even if it’s just a navigation menu.
- dgb23 7y ago
  >So you’re wasting download and JS processing time (a serious concern on low end devices) hydrating a lot of elements that won’t even ever change. It’s stupid and it needs to stop. You hydrate the markup because you want to render subsequent state changes in the client. Meaning much smaller downloads (just the relevant data) between route changes and so on.
adamzapasnik 7y ago
While I'm not an old dog myself, rather a puppy. I share your sentiment. SPAs or over-jsed pages are problematic for many reasons. At the moment this is my list when coding frontend on my own projects: 1. The less js the better. 2. If you can solve a problem in a few lines of native js, go for it! 3. Some complex "component"? Use React, it will save you a headache. Why like this? 1. A lot can be done without js. Solutions are many times simpler and easier to modify. 2. A lot of components, like models and so on can be done in a few lines of javascript. 3. I think React isn't bad per se, many times it's a cleaner solution over native js when it comes to complex components, which can be required by designers, shrug.
throwaway55554 7y ago
> I'm one of those "old dogs" who don't quite get the advantage of using React in the majority of the cases it's used. This article didn't really help... When you feel like this, just remember two words, "developer productivity". That will be the excuse (reason?) for using it.
ww520 7y ago
Yep. In my last dark theme effort. It's mainly CSS work.
shadowgovt 7y ago
For the specific example the article gives, you probably should implement it by having a top-level component change one of its class identifiers and having the CSS properly select light mode / dark mode all the way down the chain. ... but the purpose of state is to keep track of whether you're in light mode or dark mode. You don't want the arbiter of that knowledge to live on the DOM if you're doing a web app, because you need to reason about who is allowed to change between light and dark mode and the DOM is global state; anything in your app could be editing it. State (among its other uses) serves as a gatekeeper on the ground truth of what mode you're in (and if all changes to presence / absence of the class in question pass through that component state, you're good to go).
inviromentalist 7y ago
Literally to avoid joining the apple ecosystem. If I can make an app that services 100% of users and merely borrow a friend's Apple product to hit "compile", I will. Heck it's enabled me, because prior, I had only provided services to Android and web.
veeralpatel979 7y ago
Hey - author here. React is just simpler for me to reason about. A app has many pages, a page has many components. I can write components; I can write Redux/MobX code; I can pass data between components. Things work. But absolutely, my speed of development when using React is lower than when I'm using server-generated HTML in a Rails app. On the other hand, I can do things with React I can't do with server-generated HTML.
rajangdavis 7y ago
- Using a UI framework maps well to working with UX designers in that you design the interactions of a given component in accordance to UX spec. - Combining multiple components in a given page to transform or process user interaction becomes simpler as the components are plug and play with the state of the page. - Combining multiple pages where state can move across an entire application can allow for a seamless user interface - Employing techniques like code splitting and Server Side Rendering allows for smaller js payloads with an incremental approach to assets versus loading everything at once. The largest advantage UI frameworks provide is that it makes what you would normally do with javascript a lot more _composable_. You can do the same with vanilla JS, but it gets a lot more difficult when you attach events to the DOM, it's hard to reason about how you might organize your code which doesn't scale well across teams. I think the simplest way to consider the advantages of a UI framework is to build a search application from scratch with vanilla JS. You can get pretty far but once you start adding in things like pagination, it can get a little hairy. jQuery and it's libraries can help you there, but there's a good chance that you're adding in some overhead to the load times of your page. If you rebuild the application with a UI framework and employ practices like code splitting, the code (usually) ends up being a lot more reasonable and easy to extend (which businesses tend to like). Adding features becomes less about reasoning about which DOM event fires what and instead more about transformations in state with the components subscribing to state instead of DOM events.
catchmeifyoucan 7y ago
There are two things that I like about React. 1. Componentization. I've found this to be super useful and helps me build items that I can use in multiple places. Pair that with something like Storybook JS - and you have an app that can be broken up into puzzle pieces with high reusability. This helps isolate the business logic from the UI. Granted - a similar effect could be pulled of with HTML templating. 2. State Management - Love love that I don't have to handle UI updates when the data changes. This I believe is the whole "reactive" model [if I'm not mistaken]. Consider building a Rich Text Editor, and the user is typing, he uses keyboard shortcuts to enable bold, underline and italics. How do you update the UI to reflect those have been selected. Listen to the shortcuts, and add the necessary class? Great, what if that shortcut had to kickoff ten more things? Another method also adds a contradicting class to that same element. At some point, the logic becomes super entangled, and it becomes hard to track where and why. With React/Redux - life runs like an FSM. Each update/action can be traced. [though I use MobX because it takes less effort] P.S. I also don't recommend React for Single Page things. It's unnecessary bloat. Complex in my head means multiple distinct components (like > 5).
jrandm 7y ago
React is cool if you want components. Web components had crap support because browsers needed to implement them; React you could use immediately. I agree Redux isn't an improvement there, media queries for user preference[0] were. However, rendering details aside (this may still use a CSS class), you might choose to give a separate option inside your regular UI or have some other interactive blob that is colorscheme-aware but needs to be told that manually. Maybe you have lots of options. The app-colors state can be set to some explicit value initially or default-inherit from the environment, but it still has to be tracked somewhere that isn't the stylesheet. It doesn't have to be Redux but it does have to be something. Relatively soon I expect web components will start to eat into the UI framework nonsense.[1] React never really hid the need to know HTML, CSS, and JS well just like jQuery didn't. They made it _easier_. They also encouraged a plug'n'play ecosystem that made it easy to kinda-sorta hack together what you wanted -- without having to do much reading. Bold prediction: In the future we'll look back at a lot of "React developers" like we do at "jQuery developers" now. [0]: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref... [1]: https://caniuse.com/#search=web%20components https://caniuse.com/#search=web%20components shows Safari as the only partial out of major browsers, plus some in the long tail. I've only poked at it a bit recently, they were a mess last time I tried (years ago)... it's much better.
sparkywolf 7y ago
https://imgur.com/gallery/91sn32Q https://imgur.com/gallery/91sn32Q On a serious note, I do agree with you. oftentimes things are overcomplicated just for the sake of 'javascript'. Once you get used to setting up a project a certain way you may not stop to consider whether or not it's the best for the specific project.

jfengel 7y ago

React and Redux are for apps. If you can do it with HTML/CSS, you absolutely should. React/Redux are a replacement for what people used to do with jquery or plain JS. They're not for display; they're for complex interaction of the kind that used to require a native user interface (Java Swing, Gtk, Win32, etc). Javascript is a mess, and the DOM is a mess; React makes that slightly less awful. (Redux is an extension to React to help manage global state; again, it's compensating for just how bad Javascript is.) Bonus: React encourages the use of JSX, a language that makes a lot of behavior look as if you were writing it directly in HTML. You don't need React to use JSX, and you don't need JSX to use React, but they do dovetail nicely. You can write in plain JS/jquery if you want. Plenty of people do. React is a framework to make that a bit easier; that's all.

the_gastropod 7y ago
I actually write a good bit of React professionally. I'm familiar. I just have yet to see a very compelling case. And the excuse is almost always this nebulous "rich/complex interaction". And.... I just rarely see any good examples of this. The huge majority of apps (web or otherwise) are not video games. They're forms that submit stuff to a server and get a response. There's sometimes a dropdown here or there.... and that's it.
- acephal 7y ago
  Mmm, I work on a multimedia sequencer (timeline, viewport, etc) in the browser, it would be utter hell if the whole thing was put together via manual DOM updates in something like a Backbone View render function. I know this because when I joined the company, they were trying to do it in Backbone. For a project of that scope, this was a great way to introduce a large surface for error and maintenance (the project kicked off right when React was launching and Typescript wasn't public). Leveraging React as an interface to updating the DOM removes all of those concerns from your implementation work. That's a big productivity boost when you're trying to build a multimedia sequencer. More so when your team is junior-dominant.
  - Jare 7y ago
    > when React was launching and Typescript wasn't public Minor correction, React came out about 7 months after Typescript. That said, Typescript had a promising birth but a rough infancy, so I wouldn't blame anyone for considering it released only after 1.x versions starting in late 2014.
    - acephal 7y ago
      Yeah, that was bad characterization. This was the first half of 2015.
- itronitron 7y ago
  I've worked on a few applications with 'rich/complex interactions' and everyone on the team was opposed to using any sort of JS framework. That was nice because it was relatively easy for anyone to trace through the application as needed. In my experience if the application state is overly complex then that is a result of the design, and that usually leads to a bad experience for the user.
  - kqr 7y ago
    In my experience, when it comes to rich interaction, the question isn't whether or not to use a framework -- the question is whether to write your own framework from scratch and discover all mistakes you can make on your own, or use one that already exists and builds on best practises as well as we know them.
lhorie 7y ago
I think what GP was getting at is that there's a healthy amount of "if all you have is a hammer" mentality going on w/ React/Redux. The tragedy of commons here is that you _could_ conceivably just slap a class at the root of your React tree to implement dark mode, but if one is using something like styled-components, there's a good chance that the library will get in the way of the style cascading semantics that come for free w/ the browser. And ultimately, the end-user is the one paying the price for all the extra code needed to make a "complexity-friendly" implementation of dark mode work. Another observation that I've been finding interesting about "modern frontend development" is that despite all the arguments about how React makes DOM manipulation easier, people still prefer to defer to libraries to do any non-trivial amount of DOM manipulation rather than actually use pure React to do it. This is exactly the same modus operandi as when jQuery was "modern frontend development" ("it makes it easier to work w/ DOM", plus a ton of opaque jquery-* libs)
- shadowgovt 7y ago
  I don't see why using libraries for complicated interactions atop React is a bad thing.
  - johnmaguire2013 7y ago
    I'm not sure it's a bad thing - but using a library for DOM manipulation on top of it diminishes the argument that React's advantage is to make DOM manipulation easy.
    - dragonsh 7y ago
      Having used react and modern web components to build webpages. I will agree with the first comment which says what is made so hard by react/redux can be easily done if the pages were rendered on server and delivered to client with progressive smaller bits of JavaScript for dynamic interaction. If state management is so critical to running a react app than I feel Elm/ClojureScript is a better choice than react to build web apps. But I doubt they will be as popular given network effect. Now everyone went on a bandwagon that react/angular/SPA/progressive apps is the only future and plain HTML/CSS/JS mix on server side with specific language templates is dead. I am sure we will again go full circle back as you can see now with SSR (server side rendering) is considered as a norm for performant react or angular apps. SSR combined with complexity of react/redux unnecessarily makes everything complicated (worse than even complex). Instead of doing HTML templates in nicer language on server side now people are forced with half baked solution on client side like JSX or angular templates etc. A developer not just need to learn intricacies of HTML/CSS/JS, but then API's of framework like react, combine it with state management framework, combine it with client side templates, combine it with build tools like gulp, webpack, combine it with NPM, Yarn, combine it with babel compiler, combine it with many testing frameworks. The whole eco-system is very complicated (not just complex). This is one of the reason for emergence of compiler based web application development language and frameworks like Svelte, Elm, ClojureScript, PureScripts. They will still be not popular because there is a network effect of jobs available. So inferior tools for user interface like react/angular will continue to thrive.
GrumpyNl 7y ago
I disagree with making it easier. Php, jquery and css will bring you a long way. react is far more complex.
rorykoehler 7y ago
I've been writing vanilla javascript on the frontend for a recent project. It's really not bad. Much less cognitive load compared to writing react. Easier to read too
mesaframe 7y ago
Is JavaScript is a need making a library/framework over it doesn't make it any better. Also, you stated benefits of Fact without stating how it makes it better.

simonsarris 7y ago

I've always preferred hand-crafted websites with readable view-source over frameworks, but I finally switched to react so I could keep my site's background animations persistent over pages. It' somewhat unfortunate that its still not possible without some JS (in this case, a framework that's swapping out portions of the page).

brlewis 7y ago

I get the advantage of using React for single-page web apps, but I'm totally with you on the dark mode example. The modern way to do dark mode is to assume that people who want it won't be using IE or Edge, and just do a CSS media query. https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...

some-guy 7y ago

For individuals making small sites, it's absolutely overkill. For my job, with hundreds of developers working on a giant SPA blob with constant feature creep, frameworks like React are a necessary evil to maintain the insanity.

WilliamEdward 7y ago
At what point does it stop being a small site and become a giant app? Genuinely curious cus im wondering if i should make the switch.
- zys5945 7y ago
  I think it's about the number of developers involved. If you have a small team of 3-5 people who understands the architecture as a whole and can keep up with most PRs then I don't think a UI framework is necessary. However, if you have many teams working on the same project and/or cannot keep up with every single PR merged then I think using a UI framework is a must. It forces you to stick to strict rules. Although you will start writing boilerplate code, it makes the entire application much more modular, and easier to reason about.
  - jf22 7y ago
    With 3-5 people you end up building your own UI framework.
switch007 7y ago
React is just a library though. Surely there is much more to your story than React alone?
- frenchyatwork 7y ago
  Sure, React is just a library, but I don't think I've ever seen it used as just a library.

spion 7y ago

One of the reasons is the difficulty of writing reusable interactive components with server-side rendering such as maps, rich text editors, autocompletes, hover previews, menus. The components work with data. Let's say you need an auto-complete component - 500ms after the user starts typing it will query the server and get some data back. You can describe the returned data in partially rendered HTML too but the attribute-based descriptions are often quite limited and for ease of use from the JS side you're likely to end up with embedded JSON as a general data description language with unlimited nesting, which naturally leads you to a client-side templating language. The components are also likely to re-use each other, giving rise to the need for a module system to track those dependencies and make sure they are all loaded when you go to a specific page based on the components being rendered. If you use partial rendering you would also need to ensure to track any components used from the partial html endpoints have their JS included in the page, capturing any of their occurences, making sure to attach the right event handlers to enable interactivity. Sure, one could ostensibly write a set of components that use JS under the hood and add them to the back-end. They could also write a server-side module system that ensures that the right scripts are included in any page that uses them. They could do all that. But then that would work only for a single backend ecosystem, such as e.g. Rails. There is no way this component library would be able to compete with a unified client-side ecosystem in terms of features, flexibility or battle-testedness. Additionally, if you want to try a different language on the backend, you won't be able to - unless you're willing to pay the overhead of a secondary service meant to only generate the HTML and manage the JS plugin system. And all this is before we even consider alternative clients (e.g. mobile)

spion 7y ago
For reference, here is a "simple" app - a parametric EQ designer that supports doing pink noise measurements of speakers (or headphones if you have the right equipment) with FFT in the browser: https://eq.spion.dev/ https://eq.spion.dev/ - works as an entirely static website :) Typically what people say is "oh most websites won't need THAT" but the appetite for interactivity only grows with most companies, so you could easily end up in a slowly boiled frog scenario where your serverside HTML-JS mishmash is an absolute mess.

untog 7y ago

To me there’s nothing wrong with React, but everything wrong with people using it in inappropriate contexts. For instance, I’ve seen a growing trend of people creating a whole DOM using React JSX so that they can use React’s server side rendering pipeline. <body> tag all the way down. But the actual reactive components make up about 30% of the page. So you’re wasting download and JS processing time (a serious concern on low end devices) hydrating a lot of elements that won’t even ever change. It’s stupid and it needs to stop. But for fully interactive webapps, React is great.

IggleSniggle 7y ago
...aren't the static portions uh...rendered server side? And possibly even the dynamic ones cached when common? If not, I'm confused about what SSR means in this scenario.
- untog 7y ago
  They are rendered statically... then hydrated client side, needlessly, because they’ll never change.
mr_toad 7y ago
I don’t understand why you would serve up the React library if you’ve already rendered on the server. I use React server side and then serve the static HTML.
- untog 7y ago
  Because you still need interactivity of some sort. Even if it’s just a navigation menu.
dgb23 7y ago
>So you’re wasting download and JS processing time (a serious concern on low end devices) hydrating a lot of elements that won’t even ever change. It’s stupid and it needs to stop. You hydrate the markup because you want to render subsequent state changes in the client. Meaning much smaller downloads (just the relevant data) between route changes and so on.

adamzapasnik 7y ago

While I'm not an old dog myself, rather a puppy. I share your sentiment. SPAs or over-jsed pages are problematic for many reasons. At the moment this is my list when coding frontend on my own projects: 1. The less js the better. 2. If you can solve a problem in a few lines of native js, go for it! 3. Some complex "component"? Use React, it will save you a headache. Why like this? 1. A lot can be done without js. Solutions are many times simpler and easier to modify. 2. A lot of components, like models and so on can be done in a few lines of javascript. 3. I think React isn't bad per se, many times it's a cleaner solution over native js when it comes to complex components, which can be required by designers, shrug.

throwaway55554 7y ago

> I'm one of those "old dogs" who don't quite get the advantage of using React in the majority of the cases it's used. This article didn't really help... When you feel like this, just remember two words, "developer productivity". That will be the excuse (reason?) for using it.

ww520 7y ago

Yep. In my last dark theme effort. It's mainly CSS work.

shadowgovt 7y ago

For the specific example the article gives, you probably should implement it by having a top-level component change one of its class identifiers and having the CSS properly select light mode / dark mode all the way down the chain. ... but the purpose of state is to keep track of whether you're in light mode or dark mode. You don't want the arbiter of that knowledge to live on the DOM if you're doing a web app, because you need to reason about who is allowed to change between light and dark mode and the DOM is global state; anything in your app could be editing it. State (among its other uses) serves as a gatekeeper on the ground truth of what mode you're in (and if all changes to presence / absence of the class in question pass through that component state, you're good to go).

inviromentalist 7y ago

Literally to avoid joining the apple ecosystem. If I can make an app that services 100% of users and merely borrow a friend's Apple product to hit "compile", I will. Heck it's enabled me, because prior, I had only provided services to Android and web.

veeralpatel979 7y ago

Hey - author here. React is just simpler for me to reason about. A app has many pages, a page has many components. I can write components; I can write Redux/MobX code; I can pass data between components. Things work. But absolutely, my speed of development when using React is lower than when I'm using server-generated HTML in a Rails app. On the other hand, I can do things with React I can't do with server-generated HTML.

rajangdavis 7y ago

- Using a UI framework maps well to working with UX designers in that you design the interactions of a given component in accordance to UX spec. - Combining multiple components in a given page to transform or process user interaction becomes simpler as the components are plug and play with the state of the page. - Combining multiple pages where state can move across an entire application can allow for a seamless user interface - Employing techniques like code splitting and Server Side Rendering allows for smaller js payloads with an incremental approach to assets versus loading everything at once. The largest advantage UI frameworks provide is that it makes what you would normally do with javascript a lot more _composable_. You can do the same with vanilla JS, but it gets a lot more difficult when you attach events to the DOM, it's hard to reason about how you might organize your code which doesn't scale well across teams. I think the simplest way to consider the advantages of a UI framework is to build a search application from scratch with vanilla JS. You can get pretty far but once you start adding in things like pagination, it can get a little hairy. jQuery and it's libraries can help you there, but there's a good chance that you're adding in some overhead to the load times of your page. If you rebuild the application with a UI framework and employ practices like code splitting, the code (usually) ends up being a lot more reasonable and easy to extend (which businesses tend to like). Adding features becomes less about reasoning about which DOM event fires what and instead more about transformations in state with the components subscribing to state instead of DOM events.

catchmeifyoucan 7y ago

There are two things that I like about React. 1. Componentization. I've found this to be super useful and helps me build items that I can use in multiple places. Pair that with something like Storybook JS - and you have an app that can be broken up into puzzle pieces with high reusability. This helps isolate the business logic from the UI. Granted - a similar effect could be pulled of with HTML templating. 2. State Management - Love love that I don't have to handle UI updates when the data changes. This I believe is the whole "reactive" model [if I'm not mistaken]. Consider building a Rich Text Editor, and the user is typing, he uses keyboard shortcuts to enable bold, underline and italics. How do you update the UI to reflect those have been selected. Listen to the shortcuts, and add the necessary class? Great, what if that shortcut had to kickoff ten more things? Another method also adds a contradicting class to that same element. At some point, the logic becomes super entangled, and it becomes hard to track where and why. With React/Redux - life runs like an FSM. Each update/action can be traced. [though I use MobX because it takes less effort] P.S. I also don't recommend React for Single Page things. It's unnecessary bloat. Complex in my head means multiple distinct components (like > 5).

jrandm 7y ago

React is cool if you want components. Web components had crap support because browsers needed to implement them; React you could use immediately. I agree Redux isn't an improvement there, media queries for user preference[0] were. However, rendering details aside (this may still use a CSS class), you might choose to give a separate option inside your regular UI or have some other interactive blob that is colorscheme-aware but needs to be told that manually. Maybe you have lots of options. The app-colors state can be set to some explicit value initially or default-inherit from the environment, but it still has to be tracked somewhere that isn't the stylesheet. It doesn't have to be Redux but it does have to be something. Relatively soon I expect web components will start to eat into the UI framework nonsense.[1] React never really hid the need to know HTML, CSS, and JS well just like jQuery didn't. They made it _easier_. They also encouraged a plug'n'play ecosystem that made it easy to kinda-sorta hack together what you wanted -- without having to do much reading. Bold prediction: In the future we'll look back at a lot of "React developers" like we do at "jQuery developers" now. [0]: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref... [1]: https://caniuse.com/#search=web%20components https://caniuse.com/#search=web%20components shows Safari as the only partial out of major browsers, plus some in the long tail. I've only poked at it a bit recently, they were a mess last time I tried (years ago)... it's much better.

sparkywolf 7y ago

https://imgur.com/gallery/91sn32Q https://imgur.com/gallery/91sn32Q On a serious note, I do agree with you. oftentimes things are overcomplicated just for the sake of 'javascript'. Once you get used to setting up a project a certain way you may not stop to consider whether or not it's the best for the specific project.