13 ms·

No One Ever Got Fired for Choosing React

65 points by petercooper 6y ago

Jakobeha 6y ago
The developer's project was exactly the type of project which should use React: a "web app", an application which is on a webpage. A problem with React (or any big library really) is that sometimes developers use it for blogs, forms, or other simple websites. There are many great tools out there for these websites, React is not one of them.
- jinnko 6y ago
  > sometimes developers use it for blogs, forms, or other simple websites. There are many great tools out there for these websites, React is not one of them. Such as?
  - JackMorgan 6y ago
    Here's a vote for Hugo, the static site generator written in Go. It's blazing fast. I use it for my blog and love it.
    - oknoorap 6y ago
      Have you tried NextJS or Gatsby?
      - anaganisk 6y ago
        Gatsby and its magic comes no where near Hugo, hugo is basically just select the theme and write markdown Gatsby and its quirks, are just too heavy. I would rather suggest Next.js.
        oknoorap 6y ago
        Yep, Next.js export build to static HTML is pretty impressive.
    - bogwog 6y ago
      > It's blazing fast. This seems like an odd value proposition for a static site generator. Even a really shitty, unoptimized single threaded non-incremental build system shouldn’t struggle too hard to compile a static site. And even if it does, if it has a good amount of features, it shouldn’t be a problem for most use-cases.
      - plorkyeran 6y ago
        Using jekyll I've gotten 30+ minute build times for sites. SSGs aren't only useful for sites with a single-digit number of pages.
        JackMorgan 6y ago
        I switched from Jekyll, it's amazing to me how slow it was to build a simple hundred pages of HTML. What Hugo does in Uber a second took Jekyll several minutes.
  - danielheath 6y ago
    For a blog? Give someone a few dollars to run wordpress for you and move on to writing content.
    - andrewingram 6y ago
      Sure, as far as getting up and running cheaply and quickly is concerned, Wordpress is a great choice. But most Wordpress-based personal sites I've come across are significantly slower than the React-based personal sites i'm aware of. There's a big problem with abusing plugins that haven't been designed with any kind of performance in mind.
      - BrianOnHN 6y ago
        If it's a blog then use a CDN.
        andrewingram 6y ago
        This is as true with React as it is with Wordpress. I can’t speak as to wider trends, but anyone using Gatsby or Next.is and deploying on Netlify or Vercel is going to be getting good caching and use of a CDN by default. My point was that the amount of client-side bloat in a Wordpress personal site seems to be higher than the equivalent React site, and the overall performance seems to be worse.
      - cj 6y ago
        If you're starting a blog, chances are you're going to care a lot about SEO. Wordpress is a much better starting point from a SEO perspective than a react app built from scratch. Performance is quick if you put it behind a CDN and disable things like comments (which I suppose you also wouldn't have in a react blog, unless you're building a commenting system from the ground up, too)
        andrewingram 6y ago
        Is that really true? I’m not a big fan of Gatsby, but if someone opts to use that, there are enough popular plugins to make all the key SEO work happen pretty automatically. People building personal sites with React are mostly starting from one of the popular frameworks, these give you pretty sensible defaults for both performance and SEO (for which performance is now a factor).
  - otabdeveloper4 6y ago
    HTML and CSS and Javascript.
- whywhywhywhy 6y ago
  > developers use it for blogs, forms, or other simple websites. Starting to see this on my team, example would be a simple marketing landing page, then for what are perfectly normal things you’d have on the page like a video player or a button they start using the components built for the web app. Then you ask them for things to behave a little different or for some of the normal things you’d expect on a marketing page like a video auto playing silently with subtitles. Then you just start getting told “nah it’s too much work the component wasn’t built to do that”.
flippinburgers 6y ago
Saying that react is boring but also actively developed is a bit contradictory particularly in the land of javascript.
- lstamour 6y ago
  Next you’ll be saying that it’s contradictory for Redis, Postgres, HAProxy and Nginx to be considered both boring and actively developed. I, for one, would argue that JavaScript as a language and the Web (or DOM APIs and features) are both boring yet actively developed, and that the same applies to most programming languages, for example. That said, the problem described here about picking something more “vanilla” but ending up with a non-standard codebase makes me long for the days of Ruby on Rails, especially before Engines, when it seemed like you could open any web app in existence and would be productive on day one just by knowing the Rails conventions...
  - Macha 6y ago
    The thing about HAProxy/Nginx being boring is that if you knew how to use them a decade ago you know how to use them now. Redis is a bit younger but my understanding has not changed for users drastically. Postgres has more features but the day to day is pretty similar. I don't feel the same so true for JavaScript. Node was brand new, package management was brand new, ES6 wasn't even published yet, never mind usable. For the browser/DOM you likely used jquery because you couldn't use it directly, APIs like querySelector weren't available in a time when Chrome was less popular than IE6. You probably wrote "var that = this" a lot as most people didn't understand bind/apply. Modules were done by using a global object and sticking functions on that. So I don't think JavaScript has yet earned being called boring on the same level as the others, even if the "days since last framework" days are over with React the winner and Vue/Angular the other survivors.
- westwing 6y ago
  React rarely breaks your code, and if it does, you must've been doing something peculiar. Then, chances are that the problem is well-isolated and relatively simple to fix.
- 6y ago
vikingcaffiene 6y ago
I'm a tech lead responsible for deciding stuff like what front end framework to use. I have a personal preference for Angular and svelte but earlier this year when given a greenfield project I still went with React (with TypeScript of course). As the author correctly states: always bet on boring.
- dirtnugget 6y ago
  I find Angular much more "boring" than react because it feels much closer to classical HTML/CSS/JS. React basically asks me to mix all of these, which can be distracting
  - westwing 6y ago
    I arrived at the opposite opinion. React really only asks you to mix HTML (or representations of HTML) with JS, while Angular asks you to write some "not-quite-HTML-nor-JS" DSL. Angular is also impossible to use in a lean fashion. React doesn't require "create-react-app" or even JSX.
  - antihero 6y ago
    I found Angular weirdly over-complicated for doing the same stuff React does.
    - Alex3917 6y ago
      It was more complicated before version 1.5, now it’s basically the same. In the last year I think angular is likely the best framework again.
    - dirtnugget 6y ago
      At first maybe but once projects become larger, its often preferable to have a complete toolset which is feature-complete and documented in the same place. I do not like spending time on things such as choosing which router to use, or which extension should be used to handle async operations in redux. Or wether we should write class-based or functional components. Or how to configure production builds. Or wether to use dispatchToProps or hooks. React has gotten quite messy over the years. In my last react project I encountered 3 out of those 5 questions in a 4 week span. Angular projects tend to have the same, reliable dependencies and structure. I admit that Angular adds some overhead if you have not worked with modules and observables, but it does give you a complete toolset to build very scalable frontends. And once you dive into ngrx and its ecosystem it becomes clear that Angular has quite some upsides, especially for enterprise software. There is a reason why NestJS adopted a lot of Angulars patterns such as modules and services. They make the code so much cleaner when used properly.
zinekeller 6y ago
My personal opinion on React is that it may be overkill on simpler projects, but there are mitigations (like SSR) that make it easier to swallow, and in this case it is fine (as it allowed faster prototyping and building). The real problem is that major websites have used frameworks for relatively static pages (news sites are bad at this) but didn't think of the possible side effects (like slower client-side rendering and subjectively "sluggish" website.)
marczellm 6y ago
That blog is weird. Changing to a different browser tab and back changes the scroll position a lot.
- jakelazaroff 6y ago
  Weird, there’s very little JavaScript and there shouldn’t be anything messing with that specifically. Are you sure the culprit isn’t a browser extension?
nobody0 6y ago
React indeed is boring, you can just speak { Javascript } to do the jobs instead of wiring up templates by learning a new template language like in many other frameworks. JSX is a good abstraction layer. And hooks made the development experience even more smooth.
- Nextgrid 6y ago
  The problem is that in the majority of cases you need a backend anyway but now instead of serving HTML from it directly you need yet another layer and a different language. Sometimes it's justified, sometimes it's completely overkill and you waste a lot of time. On a project I've been on I've seen days being wasted to build a basic account management form (think username, password, personal details, etc) in React for no reason, despite the same being achievable with our backend (Django) in a couple hours.
  - kevinob11 6y ago
    This has been my experience, react is now a tool I reach for to build apps that require a very high level interactivity with a non-form based ui. For more standard workflows Django with a bit of vanilla JS has become my go-to tool. Our team has never felt more productive and the dev learning curve is much less steep. Clients are happier with the results, and the apps feel much more maintainable because there are less pieces to break / update / manage in the production environment.
jfax 6y ago
Wrong. Years ago, co-worker of mine got fired (or kinda left himself) because of his campaign to introduce javascript frameworks, React in particular, into our application. This in particular escalated into nasty, sweary arguments I've overheard from the meeting room across the hallway.
- jedimastert 6y ago
  > escalated into nasty, sweary arguments I feel like this person would have been fired at some point, with or without React...
- Nextgrid 6y ago
  Was there a good reason for introducing those frameworks in your opinion? I can see both sides here - could be that the application actually justified a JS framework but nobody would listen - or it could be that a JS framework is totally overkill and would introduce unnecessary complexity.
- mkl95 6y ago
  I think I've never seen a HN post age so badly in such a short time.
  - jakelazaroff 6y ago
    The title isn’t meant to be literal. https://duckduckgo.com/?q=nobody+ever+got+fired+for+buying+ibm https://duckduckgo.com/?q=nobody+ever+got+fired+for+buying+i...
k1e 6y ago
And many of them should be fired for choosing SPA way where its not necessary and only creates bigger initial loading times/eats more RAM.
acvny 6y ago
What A Stupid Title
- petercooper 6y ago
  Whether it is or not, it's a reference to a classic industry phrase: "Nobody ever got fired for buying IBM." .. and the author is drawing some parallels with the motivation behind that phrase also.
bythreads 6y ago
Take a look at preact near feature equality in 3kb... https://preactjs.com/ https://preactjs.com/
- jordic 6y ago
  I'm more used to preact, it's small it's fast, and it's near the DOM. Last, with preact/htm it doesn't need any tooling :)
- dbbk 6y ago
  Preact is always my preference until you bump into compatibility issues, then switch it out for React. But it's great if you're doing relatively straightforward things.
michaelmior 6y ago
This reminds of a conversation I overheard at a previous job where the devs on another project decided to build their own backend framework. I knew the requirements pretty well and I begged them not to. A few months later they had left and I inherited the project with their homegrown framework. Since the project was still fairly new, eventually we made the decision to toss it all and start from scratch.
- tester756 6y ago
  I'd want to assume good faith here, but it's difficult
- andi999 6y ago
  "....toss it all and start from scratch." with a different homegrown framework :-) (this time done right, of course)
  - michaelmior 6y ago
    Actually, we ended up going with Django. Partially because the devs we were able to hire at the time knew Python well.
- dvfjsdhgfv 6y ago
  This is a very common story. The people who push for that do it for two reasons (1) they don't feel competent enough to use a popular solution that would fit better and ensure a more stable future for the project, and/or (2) they realise it might help them to hold their position longer if they author their own solution. It's important the management realises that.
danjac 6y ago
The thing about React is not the library itself but the ecosystem, which feels like building on constantly shifting quicksand (e.g. react-router).
- lowdose 6y ago
  Facebook should have gardened their assets better. Now it's basically a double Whammy without jelly.
- justsomeuser 6y ago
  I always wonder why you need 7 versions of a url router. It should be the type of thing that’s written once and lasts forever with only small changes.
himujjal 6y ago
No one pointed out that the guy didnt know how to pass a style to child the current svelte framework allows you to. And simply ditched it. I assume the type of project he was building means he is really good with web stuffs. But this is a simple thing to do. I am surprised. I am a fair beginner myself and having done it I never thought "this" would be an issue. The RFC is just an extra easier way to do it. If the OP is here, can I know where he faced the problem? Maybe the xommunity could have helped. I would never consider React over Svelte. Except the community size all I see are disadvantages.
- jakelazaroff 6y ago
  I saw the workaround, but I’d rather not go against the grain of the framework like that. I faced the problem when trying to add layout styles to a component from the outside — basically, the parent should decide a component’s position/dimensions/etc. FWIW, I don’t consider myself particularly good with web stuff. I’m just interested in graphics and I’ve beaten my head against it for long enough that I’ve figured out how to make some things :)
  - arderary 6y ago
    It seems like your specific use case could be solved (as you mentioned) by passing down a `className` prop, exactly like React. It's described as a workaround in the RFC because the approach there relies on internal class names (and couples the internal component API to the parent), whereas you'd be passing in the specific class you'd be using. Something like this should work, without going too much against the grain of the framework: // Parent.svelte <script> import Child from "./Child.svelte" </script> <style> .container :global(.child) { color: red // your styles here } </style> <div class="container"> <Child className="child" /> </div> // Child.svelte <script> export let className </script> <h1 class={className}>I am styled by my parent</h1>
axegon_ 6y ago
The statement that is the title... Jesus... I've very briefly had to deal with react in a project that I inherited. 20 minutes into it I hated it with a passion. 2 days later I wanted to kill everyone involved in the development of that abomination. I ended up scrapping the entire project and starting from zero because of react. And whoever chose react should have been fired. Annoyingly he had left by the time. I believe that the web has become a big pile of crap because of all those "modern" "frameworks". They tried solving problems no one had in advance. Back when I was in uni, in the second half of the 2000's, the web-part was actually enjoyable to work on. I'm really glad I ran away from that early on.
- dinkleberg 6y ago
  You want to murder dozens of people because you don’t like a framework? What an enlightened age we live in.
  - bogwog 6y ago
    At least it’s not because of their religion, skin color, ethnicity, etc. Can’t deny that isn’t progress!
  - andi999 6y ago
    it is called 'passion'
- slow_donkey 6y ago
  We've no-hired people for exactly this characteristic. It's great to have strong opinions but forcing rewrites due to that is typically not what you want in coworkers.
  - axegon_ 6y ago
    That's your problem, isn't it. I mean I was the lead developer of the team, it was in line with my manager's views. And as a lead developer of the team I'd never want to torture any of the other devs by having them deal with this pile of callback pile of garbage. It took me(yes, alone, without involving any other poor souls) a month, working 16-18 hours/day+weekends over the Christmas holidays. Users acknowledged the improved performance. As for the developers: "Man, thank you so much for getting rid of this shit". Management happy, users happy, and most importantly (from my perspective), developers happy. Priceless considering the garbage before was developed over the course of 3 years by 3 developers(two of which very experienced) and around 1 million euros in salaries alone. I rest my case.
azangru 6y ago
> I installed lit-html and got to work. “Components” were simply functions that returned lit-html template results. A big singleton at the top of the tree held onto all the application state, stored as a global variable within that module. > The first hurdle came when a component needed local state. I could have lifted it to the singleton, but that would have broken the component’s encapsulation. I noticed that lit-html directives can keep state, so I decided to use them to build a tiny component library — ignoring a warning from the lit-html developers that this wasn’t a supported use case. > My home-brewed library worked great… until I needed to run some code when a component appeared on the screen. I started digging through lit-html documentation and issues looking for a way to detect a directive’s lifecycle, but it became clear to me that going down that path would be painful. So the author knows about lit-html, good. I guess the obvious question at this point is why didn't he continue down the lit path he was already on, and tried lit-element? Lit-element should have given him observable local state (it's class-based web components), and would have given him lifecycle hooks (e.g. connectedCallback for doing something when a component appears on the screen). Lit-element is from the same ecosystem as lit-html; yet the author doesn't seem to have explored it at all. Why?
- spankalee 6y ago
  Yeah, that's disappointing. lit-html is only meant for templating, not components, and while you can kind of shoehorn components into directives. that's not ideal either. lit-html is entirely intended to be used with web components, which is can only create HTML and has no special support or syntax for components. As you note, LitElement is what you should use if you like lit-html and want components. We'll be making this more clear soon by bringing lit-html and LitElement closer together in documentation.
recursivedoubts 6y ago
> It’s a web-based graphics editor Yeah, for something like that you are going to need a lot of libraries and infrastructure to pull it off as a side project without heroic effort, so it makes sense to go with the most mature framework available. Reasonable people aren't unqualified in their criticism of React. There are times and places for it, and this sounds like one of them. It is the over-use of React (and other SPA frameworks) that most reasonable people are criticizing. The headline, a take on "Nobody ever got fired for choosing IBM" is interesting in it's own way, because that's the sentiment that leads to React being chosen for projects for which it is not appropriate.
- deleted 6y ago
  [deleted]
okareaman 6y ago
I've been learning Flutter, which is basically Google React and I'm a bit disappointed. I was hoping for something better.
- sofixa 6y ago
  Not really, it's Google's multiplatform, but mobile-first framework ( iirc desktop and web are still in beta and alpha respectively). Slightly different than React, which was web-first ( so JS, obviously) and then came to mobile.
  - okareaman 6y ago
    Don't get me wrong, Flutter is fantastic. I love that I can write one set of code that covers most of what I need for Android, iOS and web. I just think the way you define component (I'm sorry, widget) layout is ugly. They even have setState like React. I'm hoping when I get further into it that I'll find Flutter Hooks to be a nice addition.
hfourm 6y ago
I wish a lot of the React conversation would focus in on WHY it is so popular even for apps it shouldn't be. In my mind the mental model shift towards completely modular components including their CSS(in JS), behavior and Dom/html(jsx) is just a very pleasant front end development model. Its hard to go back to the old ways once you have experienced the productivity of React. I say this while obviously acknowledging dealing with the tooling ecosystem can be frustrating at times.
- eyelidlessness 6y ago
  This is it, for me. I don’t want React, but I want (a subset of) its API. I’m building a site with Next.js which in theory should be 99+% static and it should be able to ship with a very small JS footprint. But by default all that static junk gets bundled up anyway. And stripping it out would require a lot of manual work, or building yet another layer of build tooling that would be wonderful to have but is pretty daunting to think about.
  - leerob 6y ago
    There's an experimental flag for disabling runtime JS on a per-page basis in Next.js. Not sure when it will land, but the Next.js team is trying to add this directly into the framework.
    - eyelidlessness 6y ago
      That’s cool and I was reading about it today. But it’s really not what I want. I’d like to have a mostly static site but still be able to ship interactive components where they’re actually interactive. What I want, in order of preference (lowest to highest): - The ability to specify that a given component is static and should never hydrate (and never bundle in the build as a result). There’s a bunch of proofs of concept of this out there, it’s definitely a better UX, but it’s not a good DX. It’s a fight to set up, entirely manual, and generally opt in (which means you’re more likely to ship broken components if you forget to opt in, whereas opt out is more likely to deoptimize by mistake) - Static analysis to determine where components are constant at build time and automatically strip them from the build/hydration flow. - Compile to DOM operations like Svelte. Basically, I want a Svelte build with a React/JSX interface. I’m certain it’s possible, given a long enough timeline. I’m not sure how well it would work with real world React code, as hooks and context could deoptimize whole pages in unexpected ways. And that’s frankly where I wish for a much simpler React subset for this use case.
yudlejoza 6y ago
> No One Ever Got Fired for Choosing <technology-X> Hey I got better ones: - No one ever got arrested for choosing <technology-X> - No one ever got convicted for choosing <technology-X> - No one ever got put on a death row for choosing <technology-X> I think the last one is what we should all use. It's a good standard to aspire to, a nice high bar, when we develop a technology.
difosfor 6y ago
I think the most significant factor in developer productivity usually isn't the specific language or framework used but the developer's experience with those. So yeah, use React if you're experienced in React.
brucou 6y ago
I do agree with the thesis that nobody got fired for using React. I don't however think that the conclusion is to use React anywhere for anything. From what I read here, what happened here is that this developer has good knowledge of React for having used it repeteadly in the past. At the same time, he did not have experience in lit or svelte. He hit some issues and then went back to the things he knows better. It is more comfortable and more productive, there is no doubt about that. The conclusion is more like, you will write your app faster in the language, environment, and framework that you already master. I agree with that. Change one of those, and you will go through some moments of loneliness. Change two of those, you may just fail the project entirely. What is true, and proven by many data points, is that you can write complex applications with lit-html, svelte, elm or just vanilla-JS. GitHub is not a web graphics editor but it is entirely vanilla JS. Hum, po*n apparently use plenty of vanilla JS too (https://davidwalsh.name/pornhub-interview https://davidwalsh.name/pornhub-interview). IBM implemented their Carbon design system in Svelte. Adobe's adaptive color tool (https://leonardocolor.io/?colorKeys=%236fa7ff&base=ffffff&ratios=3%2C4.5&mode=CAM02 https://leonardocolor.io/?colorKeys=%236fa7ff&base=ffffff&ra...) is entirely in vanilla-JS. The list is long. So what we have here is one anecdote from one person. All data points issued from real experience are welcome, valid and useful but we should be careful to not get to conclusions too fast.
- pdfernhout 6y ago
  I outline in a ~20 page whitepaper why Mithril for JavaScript/TypeScript UIs (plus Tachyons for Atomic CSS) is a better choice over React and Angular for Single-Page Applications based on experience with all three: https://github.com/pdfernhout/choose-mithril https://github.com/pdfernhout/choose-mithril "tl;dr: Choose Mithril whenever you can for JavaScript UI development because Mithril is overall easier to use, understand, debug, refactor, and maintain than most other JavaScript-based UI systems. That ease of use is due to Mithril's design emphasis on appropriate simplicity – including by leveraging the power of JavaScript to define UIs instead of using an adhoc templating system. Mithril helps you focus on the essential complexity of UI development instead of making you struggle with the accidental complexity introduced by problematically-designed tools. Many popular tools emphasize ease-of-use through looking familiar in a few narrow situations instead of emphasizing overall end-to-end simplicity which -- after a short learning curve for Mithril -- leads to greater overall ease-of-use in most situations. ..." Two key points there are that React's setState(..) approach to minimize redrawing is a premature optimization (which then leads to wastelands of endless opaque boilerplate like Redux) -- and also JSX is completely unnecessary and counter-productive compared to just using HyperScript API to define interfaces in plain JavaScript/TypeScript without needing to introduce extra compilation steps or more complex tooling. Another key point is that Atomic CSS like Tachyons and similar approaches obviates the need for all kinds of specialized CSS encapsulation complexity. Mithril and Tachyons leverage the flexibility of HTML, JavaScript, and CSS without trying to reinvent too many other complex layers above them -- layers which typically just create more problems in the end via accidental complexity unrelated to actually creating UIs. In general that analysis applies to most current JavaScript-based UI libraries. Elm (which perhaps helped inspire Mithril as a vdom) or ClojureScript or other similar tools might be exceptions though for people willing to put the time into learning those languages (which compile to JavaScript) and dealing with integration issues. So, in reading the article and also much discussion here and elsewhere, much of that verbage to my mind fits into the category of seeing (yet again) inexperienced or otherwise constrained developers picking one problematical tool and struggling with it and then jumping to another one with different (perhaps lesser) issues again without having broadly surveyed what is out there or understanding key concerns like simplicity. Of course what is much more painful is working in organizations where such faddish choices are then forced on developers who know better (as is often the case, including sadly why I know so much about Angular and React even after years of experience using Mithril successfully). That said, once a critical amount of time and money has been spend in getting developers to use a particular solution like React, then yes, there is the sunk cost which makes it easier for an organization to do other projects in it and maintain them. Just like why a lot of other legacy software persists... Just like Facebook could promote React aggressively over alternatives (even when React had the problematical patents clause in its license), I'm reminded a bit of when Java overtook Smalltalk in part due to huge amounts of money pumped into advertising and promoting it (including by IBM, which ironically eventually had two good Smalltalks of its own). Every tool has its strengths and weaknesses in different situations (including Mithril and Tachyons). And I can accept that broad industry adoption is a plus for any tool for availability of developers and third-party libraries. Still, it's sad for me -- after having implemented UIs for about four decades in hundreds of different ways -- that when I find something like Mithril that works really well for current needs and has (all things considered) great developer ergonomics and a great (if small) supporting community, it is mostly ignored. While Mithril+Tachyons+ES7 works differently than Smalltalk and related UI libraries, that combination makes UI development almost as fun as it was in Smalltalk -- but with broader reach because HTML+CSS+JavaScript is now everywhere. For good or bad, I guess Mithril will remain a "secret weapon" like Smalltalk used to be. :-)

65 points by petercooper 6y ago

The developer's project was exactly the type of project which should use React: a "web app", an application which is on a webpage. A problem with React (or any big library really) is that sometimes developers use it for blogs, forms, or other simple websites. There are many great tools out there for these websites, React is not one of them.

jinnko 6y ago
> sometimes developers use it for blogs, forms, or other simple websites. There are many great tools out there for these websites, React is not one of them. Such as?
- JackMorgan 6y ago
  Here's a vote for Hugo, the static site generator written in Go. It's blazing fast. I use it for my blog and love it.
  - oknoorap 6y ago
    Have you tried NextJS or Gatsby?
    - anaganisk 6y ago
      Gatsby and its magic comes no where near Hugo, hugo is basically just select the theme and write markdown Gatsby and its quirks, are just too heavy. I would rather suggest Next.js.
      - oknoorap 6y ago
        Yep, Next.js export build to static HTML is pretty impressive.
  - bogwog 6y ago
    > It's blazing fast. This seems like an odd value proposition for a static site generator. Even a really shitty, unoptimized single threaded non-incremental build system shouldn’t struggle too hard to compile a static site. And even if it does, if it has a good amount of features, it shouldn’t be a problem for most use-cases.
    - plorkyeran 6y ago
      Using jekyll I've gotten 30+ minute build times for sites. SSGs aren't only useful for sites with a single-digit number of pages.
      - JackMorgan 6y ago
        I switched from Jekyll, it's amazing to me how slow it was to build a simple hundred pages of HTML. What Hugo does in Uber a second took Jekyll several minutes.
- danielheath 6y ago
  For a blog? Give someone a few dollars to run wordpress for you and move on to writing content.
  - andrewingram 6y ago
    Sure, as far as getting up and running cheaply and quickly is concerned, Wordpress is a great choice. But most Wordpress-based personal sites I've come across are significantly slower than the React-based personal sites i'm aware of. There's a big problem with abusing plugins that haven't been designed with any kind of performance in mind.
    - BrianOnHN 6y ago
      If it's a blog then use a CDN.
      - andrewingram 6y ago
        This is as true with React as it is with Wordpress. I can’t speak as to wider trends, but anyone using Gatsby or Next.is and deploying on Netlify or Vercel is going to be getting good caching and use of a CDN by default. My point was that the amount of client-side bloat in a Wordpress personal site seems to be higher than the equivalent React site, and the overall performance seems to be worse.
    - cj 6y ago
      If you're starting a blog, chances are you're going to care a lot about SEO. Wordpress is a much better starting point from a SEO perspective than a react app built from scratch. Performance is quick if you put it behind a CDN and disable things like comments (which I suppose you also wouldn't have in a react blog, unless you're building a commenting system from the ground up, too)
      - andrewingram 6y ago
        Is that really true? I’m not a big fan of Gatsby, but if someone opts to use that, there are enough popular plugins to make all the key SEO work happen pretty automatically. People building personal sites with React are mostly starting from one of the popular frameworks, these give you pretty sensible defaults for both performance and SEO (for which performance is now a factor).
- otabdeveloper4 6y ago
  HTML and CSS and Javascript.
whywhywhywhy 6y ago
> developers use it for blogs, forms, or other simple websites. Starting to see this on my team, example would be a simple marketing landing page, then for what are perfectly normal things you’d have on the page like a video player or a button they start using the components built for the web app. Then you ask them for things to behave a little different or for some of the normal things you’d expect on a marketing page like a video auto playing silently with subtitles. Then you just start getting told “nah it’s too much work the component wasn’t built to do that”.

flippinburgers 6y ago

Saying that react is boring but also actively developed is a bit contradictory particularly in the land of javascript.

lstamour 6y ago
Next you’ll be saying that it’s contradictory for Redis, Postgres, HAProxy and Nginx to be considered both boring and actively developed. I, for one, would argue that JavaScript as a language and the Web (or DOM APIs and features) are both boring yet actively developed, and that the same applies to most programming languages, for example. That said, the problem described here about picking something more “vanilla” but ending up with a non-standard codebase makes me long for the days of Ruby on Rails, especially before Engines, when it seemed like you could open any web app in existence and would be productive on day one just by knowing the Rails conventions...
- Macha 6y ago
  The thing about HAProxy/Nginx being boring is that if you knew how to use them a decade ago you know how to use them now. Redis is a bit younger but my understanding has not changed for users drastically. Postgres has more features but the day to day is pretty similar. I don't feel the same so true for JavaScript. Node was brand new, package management was brand new, ES6 wasn't even published yet, never mind usable. For the browser/DOM you likely used jquery because you couldn't use it directly, APIs like querySelector weren't available in a time when Chrome was less popular than IE6. You probably wrote "var that = this" a lot as most people didn't understand bind/apply. Modules were done by using a global object and sticking functions on that. So I don't think JavaScript has yet earned being called boring on the same level as the others, even if the "days since last framework" days are over with React the winner and Vue/Angular the other survivors.
westwing 6y ago
React rarely breaks your code, and if it does, you must've been doing something peculiar. Then, chances are that the problem is well-isolated and relatively simple to fix.
6y ago

vikingcaffiene 6y ago

I'm a tech lead responsible for deciding stuff like what front end framework to use. I have a personal preference for Angular and svelte but earlier this year when given a greenfield project I still went with React (with TypeScript of course). As the author correctly states: always bet on boring.

dirtnugget 6y ago
I find Angular much more "boring" than react because it feels much closer to classical HTML/CSS/JS. React basically asks me to mix all of these, which can be distracting
- westwing 6y ago
  I arrived at the opposite opinion. React really only asks you to mix HTML (or representations of HTML) with JS, while Angular asks you to write some "not-quite-HTML-nor-JS" DSL. Angular is also impossible to use in a lean fashion. React doesn't require "create-react-app" or even JSX.
- antihero 6y ago
  I found Angular weirdly over-complicated for doing the same stuff React does.
  - Alex3917 6y ago
    It was more complicated before version 1.5, now it’s basically the same. In the last year I think angular is likely the best framework again.
  - dirtnugget 6y ago
    At first maybe but once projects become larger, its often preferable to have a complete toolset which is feature-complete and documented in the same place. I do not like spending time on things such as choosing which router to use, or which extension should be used to handle async operations in redux. Or wether we should write class-based or functional components. Or how to configure production builds. Or wether to use dispatchToProps or hooks. React has gotten quite messy over the years. In my last react project I encountered 3 out of those 5 questions in a 4 week span. Angular projects tend to have the same, reliable dependencies and structure. I admit that Angular adds some overhead if you have not worked with modules and observables, but it does give you a complete toolset to build very scalable frontends. And once you dive into ngrx and its ecosystem it becomes clear that Angular has quite some upsides, especially for enterprise software. There is a reason why NestJS adopted a lot of Angulars patterns such as modules and services. They make the code so much cleaner when used properly.

zinekeller 6y ago

My personal opinion on React is that it may be overkill on simpler projects, but there are mitigations (like SSR) that make it easier to swallow, and in this case it is fine (as it allowed faster prototyping and building). The real problem is that major websites have used frameworks for relatively static pages (news sites are bad at this) but didn't think of the possible side effects (like slower client-side rendering and subjectively "sluggish" website.)

marczellm 6y ago

That blog is weird. Changing to a different browser tab and back changes the scroll position a lot.

jakelazaroff 6y ago
Weird, there’s very little JavaScript and there shouldn’t be anything messing with that specifically. Are you sure the culprit isn’t a browser extension?

nobody0 6y ago

React indeed is boring, you can just speak { Javascript } to do the jobs instead of wiring up templates by learning a new template language like in many other frameworks. JSX is a good abstraction layer. And hooks made the development experience even more smooth.

Nextgrid 6y ago
The problem is that in the majority of cases you need a backend anyway but now instead of serving HTML from it directly you need yet another layer and a different language. Sometimes it's justified, sometimes it's completely overkill and you waste a lot of time. On a project I've been on I've seen days being wasted to build a basic account management form (think username, password, personal details, etc) in React for no reason, despite the same being achievable with our backend (Django) in a couple hours.
- kevinob11 6y ago
  This has been my experience, react is now a tool I reach for to build apps that require a very high level interactivity with a non-form based ui. For more standard workflows Django with a bit of vanilla JS has become my go-to tool. Our team has never felt more productive and the dev learning curve is much less steep. Clients are happier with the results, and the apps feel much more maintainable because there are less pieces to break / update / manage in the production environment.

jfax 6y ago

Wrong. Years ago, co-worker of mine got fired (or kinda left himself) because of his campaign to introduce javascript frameworks, React in particular, into our application. This in particular escalated into nasty, sweary arguments I've overheard from the meeting room across the hallway.

jedimastert 6y ago
> escalated into nasty, sweary arguments I feel like this person would have been fired at some point, with or without React...
Nextgrid 6y ago
Was there a good reason for introducing those frameworks in your opinion? I can see both sides here - could be that the application actually justified a JS framework but nobody would listen - or it could be that a JS framework is totally overkill and would introduce unnecessary complexity.
mkl95 6y ago
I think I've never seen a HN post age so badly in such a short time.
- jakelazaroff 6y ago
  The title isn’t meant to be literal. https://duckduckgo.com/?q=nobody+ever+got+fired+for+buying+ibm https://duckduckgo.com/?q=nobody+ever+got+fired+for+buying+i...

k1e 6y ago

And many of them should be fired for choosing SPA way where its not necessary and only creates bigger initial loading times/eats more RAM.

acvny 6y ago

What A Stupid Title

petercooper 6y ago
Whether it is or not, it's a reference to a classic industry phrase: "Nobody ever got fired for buying IBM." .. and the author is drawing some parallels with the motivation behind that phrase also.

bythreads 6y ago

Take a look at preact near feature equality in 3kb... https://preactjs.com/ https://preactjs.com/

jordic 6y ago
I'm more used to preact, it's small it's fast, and it's near the DOM. Last, with preact/htm it doesn't need any tooling :)
dbbk 6y ago
Preact is always my preference until you bump into compatibility issues, then switch it out for React. But it's great if you're doing relatively straightforward things.

michaelmior 6y ago

This reminds of a conversation I overheard at a previous job where the devs on another project decided to build their own backend framework. I knew the requirements pretty well and I begged them not to. A few months later they had left and I inherited the project with their homegrown framework. Since the project was still fairly new, eventually we made the decision to toss it all and start from scratch.

tester756 6y ago
I'd want to assume good faith here, but it's difficult
andi999 6y ago
"....toss it all and start from scratch." with a different homegrown framework :-) (this time done right, of course)
- michaelmior 6y ago
  Actually, we ended up going with Django. Partially because the devs we were able to hire at the time knew Python well.
dvfjsdhgfv 6y ago
This is a very common story. The people who push for that do it for two reasons (1) they don't feel competent enough to use a popular solution that would fit better and ensure a more stable future for the project, and/or (2) they realise it might help them to hold their position longer if they author their own solution. It's important the management realises that.

danjac 6y ago

The thing about React is not the library itself but the ecosystem, which feels like building on constantly shifting quicksand (e.g. react-router).

lowdose 6y ago
Facebook should have gardened their assets better. Now it's basically a double Whammy without jelly.
justsomeuser 6y ago
I always wonder why you need 7 versions of a url router. It should be the type of thing that’s written once and lasts forever with only small changes.

himujjal 6y ago

No one pointed out that the guy didnt know how to pass a style to child the current svelte framework allows you to. And simply ditched it. I assume the type of project he was building means he is really good with web stuffs. But this is a simple thing to do. I am surprised. I am a fair beginner myself and having done it I never thought "this" would be an issue. The RFC is just an extra easier way to do it. If the OP is here, can I know where he faced the problem? Maybe the xommunity could have helped. I would never consider React over Svelte. Except the community size all I see are disadvantages.

jakelazaroff 6y ago
I saw the workaround, but I’d rather not go against the grain of the framework like that. I faced the problem when trying to add layout styles to a component from the outside — basically, the parent should decide a component’s position/dimensions/etc. FWIW, I don’t consider myself particularly good with web stuff. I’m just interested in graphics and I’ve beaten my head against it for long enough that I’ve figured out how to make some things :)
- arderary 6y ago
  It seems like your specific use case could be solved (as you mentioned) by passing down a `className` prop, exactly like React. It's described as a workaround in the RFC because the approach there relies on internal class names (and couples the internal component API to the parent), whereas you'd be passing in the specific class you'd be using. Something like this should work, without going too much against the grain of the framework: // Parent.svelte <script> import Child from "./Child.svelte" </script> <style> .container :global(.child) { color: red // your styles here } </style> <div class="container"> <Child className="child" /> </div> // Child.svelte <script> export let className </script> <h1 class={className}>I am styled by my parent</h1>

axegon_ 6y ago

The statement that is the title... Jesus... I've very briefly had to deal with react in a project that I inherited. 20 minutes into it I hated it with a passion. 2 days later I wanted to kill everyone involved in the development of that abomination. I ended up scrapping the entire project and starting from zero because of react. And whoever chose react should have been fired. Annoyingly he had left by the time. I believe that the web has become a big pile of crap because of all those "modern" "frameworks". They tried solving problems no one had in advance. Back when I was in uni, in the second half of the 2000's, the web-part was actually enjoyable to work on. I'm really glad I ran away from that early on.

dinkleberg 6y ago
You want to murder dozens of people because you don’t like a framework? What an enlightened age we live in.
- bogwog 6y ago
  At least it’s not because of their religion, skin color, ethnicity, etc. Can’t deny that isn’t progress!
- andi999 6y ago
  it is called 'passion'
slow_donkey 6y ago
We've no-hired people for exactly this characteristic. It's great to have strong opinions but forcing rewrites due to that is typically not what you want in coworkers.
- axegon_ 6y ago
  That's your problem, isn't it. I mean I was the lead developer of the team, it was in line with my manager's views. And as a lead developer of the team I'd never want to torture any of the other devs by having them deal with this pile of callback pile of garbage. It took me(yes, alone, without involving any other poor souls) a month, working 16-18 hours/day+weekends over the Christmas holidays. Users acknowledged the improved performance. As for the developers: "Man, thank you so much for getting rid of this shit". Management happy, users happy, and most importantly (from my perspective), developers happy. Priceless considering the garbage before was developed over the course of 3 years by 3 developers(two of which very experienced) and around 1 million euros in salaries alone. I rest my case.

azangru 6y ago

> I installed lit-html and got to work. “Components” were simply functions that returned lit-html template results. A big singleton at the top of the tree held onto all the application state, stored as a global variable within that module. > The first hurdle came when a component needed local state. I could have lifted it to the singleton, but that would have broken the component’s encapsulation. I noticed that lit-html directives can keep state, so I decided to use them to build a tiny component library — ignoring a warning from the lit-html developers that this wasn’t a supported use case. > My home-brewed library worked great… until I needed to run some code when a component appeared on the screen. I started digging through lit-html documentation and issues looking for a way to detect a directive’s lifecycle, but it became clear to me that going down that path would be painful. So the author knows about lit-html, good. I guess the obvious question at this point is why didn't he continue down the lit path he was already on, and tried lit-element? Lit-element should have given him observable local state (it's class-based web components), and would have given him lifecycle hooks (e.g. connectedCallback for doing something when a component appears on the screen). Lit-element is from the same ecosystem as lit-html; yet the author doesn't seem to have explored it at all. Why?

spankalee 6y ago
Yeah, that's disappointing. lit-html is only meant for templating, not components, and while you can kind of shoehorn components into directives. that's not ideal either. lit-html is entirely intended to be used with web components, which is can only create HTML and has no special support or syntax for components. As you note, LitElement is what you should use if you like lit-html and want components. We'll be making this more clear soon by bringing lit-html and LitElement closer together in documentation.

recursivedoubts 6y ago

> It’s a web-based graphics editor Yeah, for something like that you are going to need a lot of libraries and infrastructure to pull it off as a side project without heroic effort, so it makes sense to go with the most mature framework available. Reasonable people aren't unqualified in their criticism of React. There are times and places for it, and this sounds like one of them. It is the over-use of React (and other SPA frameworks) that most reasonable people are criticizing. The headline, a take on "Nobody ever got fired for choosing IBM" is interesting in it's own way, because that's the sentiment that leads to React being chosen for projects for which it is not appropriate.

deleted 6y ago
[deleted]

okareaman 6y ago

I've been learning Flutter, which is basically Google React and I'm a bit disappointed. I was hoping for something better.

sofixa 6y ago
Not really, it's Google's multiplatform, but mobile-first framework ( iirc desktop and web are still in beta and alpha respectively). Slightly different than React, which was web-first ( so JS, obviously) and then came to mobile.
- okareaman 6y ago
  Don't get me wrong, Flutter is fantastic. I love that I can write one set of code that covers most of what I need for Android, iOS and web. I just think the way you define component (I'm sorry, widget) layout is ugly. They even have setState like React. I'm hoping when I get further into it that I'll find Flutter Hooks to be a nice addition.

hfourm 6y ago

I wish a lot of the React conversation would focus in on WHY it is so popular even for apps it shouldn't be. In my mind the mental model shift towards completely modular components including their CSS(in JS), behavior and Dom/html(jsx) is just a very pleasant front end development model. Its hard to go back to the old ways once you have experienced the productivity of React. I say this while obviously acknowledging dealing with the tooling ecosystem can be frustrating at times.

eyelidlessness 6y ago
This is it, for me. I don’t want React, but I want (a subset of) its API. I’m building a site with Next.js which in theory should be 99+% static and it should be able to ship with a very small JS footprint. But by default all that static junk gets bundled up anyway. And stripping it out would require a lot of manual work, or building yet another layer of build tooling that would be wonderful to have but is pretty daunting to think about.
- leerob 6y ago
  There's an experimental flag for disabling runtime JS on a per-page basis in Next.js. Not sure when it will land, but the Next.js team is trying to add this directly into the framework.
  - eyelidlessness 6y ago
    That’s cool and I was reading about it today. But it’s really not what I want. I’d like to have a mostly static site but still be able to ship interactive components where they’re actually interactive. What I want, in order of preference (lowest to highest): - The ability to specify that a given component is static and should never hydrate (and never bundle in the build as a result). There’s a bunch of proofs of concept of this out there, it’s definitely a better UX, but it’s not a good DX. It’s a fight to set up, entirely manual, and generally opt in (which means you’re more likely to ship broken components if you forget to opt in, whereas opt out is more likely to deoptimize by mistake) - Static analysis to determine where components are constant at build time and automatically strip them from the build/hydration flow. - Compile to DOM operations like Svelte. Basically, I want a Svelte build with a React/JSX interface. I’m certain it’s possible, given a long enough timeline. I’m not sure how well it would work with real world React code, as hooks and context could deoptimize whole pages in unexpected ways. And that’s frankly where I wish for a much simpler React subset for this use case.

yudlejoza 6y ago

> No One Ever Got Fired for Choosing <technology-X> Hey I got better ones: - No one ever got arrested for choosing <technology-X> - No one ever got convicted for choosing <technology-X> - No one ever got put on a death row for choosing <technology-X> I think the last one is what we should all use. It's a good standard to aspire to, a nice high bar, when we develop a technology.

difosfor 6y ago

I think the most significant factor in developer productivity usually isn't the specific language or framework used but the developer's experience with those. So yeah, use React if you're experienced in React.

brucou 6y ago

I do agree with the thesis that nobody got fired for using React. I don't however think that the conclusion is to use React anywhere for anything. From what I read here, what happened here is that this developer has good knowledge of React for having used it repeteadly in the past. At the same time, he did not have experience in lit or svelte. He hit some issues and then went back to the things he knows better. It is more comfortable and more productive, there is no doubt about that. The conclusion is more like, you will write your app faster in the language, environment, and framework that you already master. I agree with that. Change one of those, and you will go through some moments of loneliness. Change two of those, you may just fail the project entirely. What is true, and proven by many data points, is that you can write complex applications with lit-html, svelte, elm or just vanilla-JS. GitHub is not a web graphics editor but it is entirely vanilla JS. Hum, po*n apparently use plenty of vanilla JS too (https://davidwalsh.name/pornhub-interview https://davidwalsh.name/pornhub-interview). IBM implemented their Carbon design system in Svelte. Adobe's adaptive color tool (https://leonardocolor.io/?colorKeys=%236fa7ff&base=ffffff&ratios=3%2C4.5&mode=CAM02 https://leonardocolor.io/?colorKeys=%236fa7ff&base=ffffff&ra...) is entirely in vanilla-JS. The list is long. So what we have here is one anecdote from one person. All data points issued from real experience are welcome, valid and useful but we should be careful to not get to conclusions too fast.

pdfernhout 6y ago
I outline in a ~20 page whitepaper why Mithril for JavaScript/TypeScript UIs (plus Tachyons for Atomic CSS) is a better choice over React and Angular for Single-Page Applications based on experience with all three: https://github.com/pdfernhout/choose-mithril https://github.com/pdfernhout/choose-mithril "tl;dr: Choose Mithril whenever you can for JavaScript UI development because Mithril is overall easier to use, understand, debug, refactor, and maintain than most other JavaScript-based UI systems. That ease of use is due to Mithril's design emphasis on appropriate simplicity – including by leveraging the power of JavaScript to define UIs instead of using an adhoc templating system. Mithril helps you focus on the essential complexity of UI development instead of making you struggle with the accidental complexity introduced by problematically-designed tools. Many popular tools emphasize ease-of-use through looking familiar in a few narrow situations instead of emphasizing overall end-to-end simplicity which -- after a short learning curve for Mithril -- leads to greater overall ease-of-use in most situations. ..." Two key points there are that React's setState(..) approach to minimize redrawing is a premature optimization (which then leads to wastelands of endless opaque boilerplate like Redux) -- and also JSX is completely unnecessary and counter-productive compared to just using HyperScript API to define interfaces in plain JavaScript/TypeScript without needing to introduce extra compilation steps or more complex tooling. Another key point is that Atomic CSS like Tachyons and similar approaches obviates the need for all kinds of specialized CSS encapsulation complexity. Mithril and Tachyons leverage the flexibility of HTML, JavaScript, and CSS without trying to reinvent too many other complex layers above them -- layers which typically just create more problems in the end via accidental complexity unrelated to actually creating UIs. In general that analysis applies to most current JavaScript-based UI libraries. Elm (which perhaps helped inspire Mithril as a vdom) or ClojureScript or other similar tools might be exceptions though for people willing to put the time into learning those languages (which compile to JavaScript) and dealing with integration issues. So, in reading the article and also much discussion here and elsewhere, much of that verbage to my mind fits into the category of seeing (yet again) inexperienced or otherwise constrained developers picking one problematical tool and struggling with it and then jumping to another one with different (perhaps lesser) issues again without having broadly surveyed what is out there or understanding key concerns like simplicity. Of course what is much more painful is working in organizations where such faddish choices are then forced on developers who know better (as is often the case, including sadly why I know so much about Angular and React even after years of experience using Mithril successfully). That said, once a critical amount of time and money has been spend in getting developers to use a particular solution like React, then yes, there is the sunk cost which makes it easier for an organization to do other projects in it and maintain them. Just like why a lot of other legacy software persists... Just like Facebook could promote React aggressively over alternatives (even when React had the problematical patents clause in its license), I'm reminded a bit of when Java overtook Smalltalk in part due to huge amounts of money pumped into advertising and promoting it (including by IBM, which ironically eventually had two good Smalltalks of its own). Every tool has its strengths and weaknesses in different situations (including Mithril and Tachyons). And I can accept that broad industry adoption is a plus for any tool for availability of developers and third-party libraries. Still, it's sad for me -- after having implemented UIs for about four decades in hundreds of different ways -- that when I find something like Mithril that works really well for current needs and has (all things considered) great developer ergonomics and a great (if small) supporting community, it is mostly ignored. While Mithril+Tachyons+ES7 works differently than Smalltalk and related UI libraries, that combination makes UI development almost as fun as it was in Smalltalk -- but with broader reach because HTML+CSS+JavaScript is now everywhere. For good or bad, I guess Mithril will remain a "secret weapon" like Smalltalk used to be. :-)