No One Ever Got Fired for Choosing React(jake.nyc)
jake.nyc
No One Ever Got Fired for Choosing React
https://jake.nyc/words/no-one-ever-got-fired-for-choosing-react/
99 comments
> 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”.
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”.
> 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?
Such as?
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.
I use it for my blog and love it.
> 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.
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.
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.
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.
HTML and CSS and Javascript.
For a blog? Give someone a few dollars to run wordpress for you and move on to writing content.
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.
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.
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)
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)
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).
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).
If it's a blog then use a CDN.
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.
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.
Wordpress is extremely horrible the second you want to do anything to it. It's overkill for even blogs, to be honest. You need a database, you need to dockerise it if don't want it to shit up the rest of the server.
My whole point is "do not do anything to it". You don't need plugins (I'll make one exception - have & test backups), you don't need docker/database/whatever because you're paying someone else a pittance to deal with that.
If you want a blog, stop fucking around with your configuration and write.
If you want a blog, stop fucking around with your configuration and write.
> If you want a blog, stop fucking around with your configuration and write.
Agreed — this was the point of the article. Tooling is a distraction from what you wanted to do in the first place. Just pick the one you can get the thing done with, whether it’s Hugo or Gatsby or WordPress or whatever.
Agreed — this was the point of the article. Tooling is a distraction from what you wanted to do in the first place. Just pick the one you can get the thing done with, whether it’s Hugo or Gatsby or WordPress or whatever.
The thing about React is not the library itself but the ecosystem, which feels like building on constantly shifting quicksand (e.g. react-router).
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.
It should be the type of thing that’s written once and lasts forever with only small changes.
Facebook should have gardened their assets better. Now it's basically a double Whammy without jelly.
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.
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.
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.
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.
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.
- 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.
It helps with working with a team
of people with varying mental models.
If React didn’t exist, every team member would have their own way of writing up, I don’t know, a multi-select drop down component. With React, you can nip a little bit of creativity out of each individual team member for sanity’s sake. You would be shocked just how different people’s mental models actually are without a framework.
I already go nuts at how some people structure some components, and to keep this post at peak hyperbole, I’d give up on life if I had to see their vanilla js components.
It would be unmanageable emotionally. I’ve seen some people write components that are straight up php-like includes (e.g import ‘./FilterCategories’. Doesn’t take any args. Just for sanity’s sake, the fact that React is helping teams write composable/reusable modules (or that a module is a function that takes params, so don’t be a dick and make a shrink wrapped component with vars baked in), with brain-dead ways of wiring up component logic is probably one of the most stress-reducing advents in frontend.
Lots of finger pointing by me here, but I’m doing it to vent to strangers, instead of taking it out at work.
If React didn’t exist, every team member would have their own way of writing up, I don’t know, a multi-select drop down component. With React, you can nip a little bit of creativity out of each individual team member for sanity’s sake. You would be shocked just how different people’s mental models actually are without a framework.
I already go nuts at how some people structure some components, and to keep this post at peak hyperbole, I’d give up on life if I had to see their vanilla js components.
It would be unmanageable emotionally. I’ve seen some people write components that are straight up php-like includes (e.g import ‘./FilterCategories’. Doesn’t take any args. Just for sanity’s sake, the fact that React is helping teams write composable/reusable modules (or that a module is a function that takes params, so don’t be a dick and make a shrink wrapped component with vars baked in), with brain-dead ways of wiring up component logic is probably one of the most stress-reducing advents in frontend.
Lots of finger pointing by me here, but I’m doing it to vent to strangers, instead of taking it out at work.
> I wish a lot of the React conversation would focus in on WHY it is so popular even for apps it shouldn't be.
I didn't think this was a mystery. It's because a lot of devs are coming into the web ecosystem having primarily learned frameworks at boot camps (or on their own).
Most front-end devs that I've worked with who started in the last 5-10 years have such framework-specific knowledge that they can't really jump between frameworks or work on vanilla JS.
I'm not saying this is categorically bad. I use heavy abstractions on top of web languages (TypeScript, Webpack, Sass, Svelte) even for static sites, so I'm not arguing that they should be writing vanilla JS.
It's just interesting that JS is so flexible, and some of these abstractions are so strong, that you can learn something like React without really learning JS at all. It's like a DSL on top of JS.
I didn't think this was a mystery. It's because a lot of devs are coming into the web ecosystem having primarily learned frameworks at boot camps (or on their own).
Most front-end devs that I've worked with who started in the last 5-10 years have such framework-specific knowledge that they can't really jump between frameworks or work on vanilla JS.
I'm not saying this is categorically bad. I use heavy abstractions on top of web languages (TypeScript, Webpack, Sass, Svelte) even for static sites, so I'm not arguing that they should be writing vanilla JS.
It's just interesting that JS is so flexible, and some of these abstractions are so strong, that you can learn something like React without really learning JS at all. It's like a DSL on top of JS.
JSX abstraction exists not because JS is so flexible but because it has a separate compiler for the code.
Otherwise if you don’t use JSX then you get something akin to programming with Ruby on Rails or Django - still quite integrated, but the syntax is familiar.
Otherwise if you don’t use JSX then you get something akin to programming with Ruby on Rails or Django - still quite integrated, but the syntax is familiar.
I actually didn't mean to include JSX in any of my comment. It is a DSL unquestionably.
I meant that the JS you write in React, Vue, and Svelte feels like a DSL.
I meant that the JS you write in React, Vue, and Svelte feels like a DSL.
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.
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
I found Angular weirdly over-complicated for doing the same stuff React does.
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.
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.
> I do not like spending time on things such as choosing which router to use,
Build the app in such a way that you can change it. Or just use react-router.
> wether we should write class-based or functional components
Functional
> Or wether to use dispatchToProps or hooks.
Hooks.
But I see what you mean, React's idiomatic patterns do change. Thing is, if you have a class based component you can still use it in amongst your functional hook-based ones. It's still compatible.
Build the app in such a way that you can change it. Or just use react-router.
> wether we should write class-based or functional components
Functional
> Or wether to use dispatchToProps or hooks.
Hooks.
But I see what you mean, React's idiomatic patterns do change. Thing is, if you have a class based component you can still use it in amongst your functional hook-based ones. It's still compatible.
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.
Indeed. Modern Angular is a pleasure to work with. You get a lot of value and productivity right out of the box and it really shines for really large apps. The "boring" aspects help me focus on what I need to build and less how.
I really don’t understand all the hate, also occasionally here.
Also I don’t understand why everyone is building with and hiring for react.
Its main selling point is that it is "just a library, not a framework" which I also find to be its biggest disadvantage. When I build an application and I choose SPA, I want a framework, not a loose collection of libs.
It’s a little like Django vs Flask. Sure Flask has less overhead but if I know what I am doing I can do 4 times as much with a framework like django in the same time, given that I know what it can do for me. Because I don’t spend time (more or less consciously) reinventing the wheel
Also I don’t understand why everyone is building with and hiring for react.
Its main selling point is that it is "just a library, not a framework" which I also find to be its biggest disadvantage. When I build an application and I choose SPA, I want a framework, not a loose collection of libs.
It’s a little like Django vs Flask. Sure Flask has less overhead but if I know what I am doing I can do 4 times as much with a framework like django in the same time, given that I know what it can do for me. Because I don’t spend time (more or less consciously) reinventing the wheel
> 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?
> 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?
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.
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.
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.
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.
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.
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.
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.
Take a look at preact near feature equality in 3kb...
https://preactjs.com/
https://preactjs.com/
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.
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 :)
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). IBM implemented their Carbon design system in Svelte. Adobe's adaptive color tool (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.
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). IBM implemented their Carbon design system in Svelte. Adobe's adaptive color tool (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.
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
"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. :-)
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. :-)
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.
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.
"....toss it all and start from scratch." with a different homegrown framework :-) (this time done right, of course)
Actually, we ended up going with Django. Partially because the devs we were able to hire at the time knew Python well.
I'd want to assume good faith here, but it's difficult
Saying that react is boring but also actively developed is a bit contradictory particularly in the land of javascript.
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...
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...
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.
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.
I do front-end dev and React is pretty much all I see people hiring for. I write React at work but I don't use it on any of my personal projects because I find it boring now.
What does that have to do with its development status?
What does that have to do with its development status?
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.
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.
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 :)
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 :)
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>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.)
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.
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.
You want to murder dozens of people because you don’t like a framework? What an enlightened age we live in.
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.
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.
Strange you say that because React is one of the most unopinionated frameworks in the space. What problems did you find it tried to solve that you wouldn’t have encountered?
Maybe this isn't react-specic, but the places I usually work at have "react experts" who turn the frontend into an multi-gigabyte abomination of dependencies, unpredictability ("Just blow away and npm install again"), and multi-minute "compiles" of an interpreted language.
[deleted]
Precisely.
None of that is about React, it’s about npm and webpack which are also used by the other libraries. With the compilation, it’s damned if you do and damned if you don’t. People complained before we had static analysis tools that JS wasn’t a real language, and now that they exist and add wait time, people complain as well. But all of that is beside the point where you were claiming that React doesn’t even need to exist, not that the development cycle is less than ideal.
React is a symptom of the disease that is js. Unorganized, entangled spaghetti of unreadable and undebuggable code and callbacks. And js is not a real language. Or to put it in another way, javascript is to a programming language what a paper plane is to a Eurofighter typhoon: one is a toy to entertain little children, the other one is an actual product of engineering.
That sounds very much like you’re just not trying. Debugging is simple in JS, just set a breakpoint or put a debugger statement, you can even evaluate arbitrary expressions at the console when execution is paused. As to spaghetti code, well that’s just what someone would say if they had no clue about the architecture of React, it forms a very specific flow of data from the top down. Some libraries allow or encourage spaghetti code such as jQuery, but that’s hardly specific to JS as the number of spaghetti code C programs is essentially uncountable.
JavaScript interpreters are present and used on more systems than any other language which makes your claim extremely inaccurate and even ignorant.
JavaScript interpreters are present and used on more systems than any other language which makes your claim extremely inaccurate and even ignorant.
The problem is that javascript is fundamentally flawed by design. It has the __WORST__ and most idiotic type system out there, it has no clue whether it wants to be oop or a functional language and there are outrageous amounts of inconsistencies everywhere you look. The argument for spaghetti C code is valid, but you'd find a lot more js spaghetti than C spaghetti, even if you adjust for the number of C code to match the amount of js code. And there are two reasons for it:
1. The horrid language that is javascript in it's core.
2. Everyone and their dog is a developer these days, and in 99% of all cases js developers without any fundamental understanding of memory management, data structures or algorithms(basically cs 101). For C, you need some fundamental understanding of all of those things for anything beyond "hello world". I'm willing to bet that if you ask 10000 js developers what the heap and stack are and how they work, 9998 of them would have never heard of those terms. And you'd probably have to add a few zeros before you get to someone who can answer that correctly.
As for the extensive usage - well yeah... All you need is a browser to interpret it. In the same way all you need to keep yourself warm in winter is to chop down a tree and set it on fire. That doesn't mean it's a wise idea to go out chopping trees in mass, does it? I lost the countless attempts to make a better language for the web and they were all killed off by the Stalinists at w3 and mozilla. As I said, react is a symptom of that stupidity, not the cause. I've said it before, I'll say it again: a good engineer and a good community are defined by their ability to say "OK, that was a stupid idea, let's go back to the drawing board". The web is in it's worst shape it has ever been. Coldfusion, flash and the ridiculous java applets were heaven compared to what we have now.
1. The horrid language that is javascript in it's core.
2. Everyone and their dog is a developer these days, and in 99% of all cases js developers without any fundamental understanding of memory management, data structures or algorithms(basically cs 101). For C, you need some fundamental understanding of all of those things for anything beyond "hello world". I'm willing to bet that if you ask 10000 js developers what the heap and stack are and how they work, 9998 of them would have never heard of those terms. And you'd probably have to add a few zeros before you get to someone who can answer that correctly.
As for the extensive usage - well yeah... All you need is a browser to interpret it. In the same way all you need to keep yourself warm in winter is to chop down a tree and set it on fire. That doesn't mean it's a wise idea to go out chopping trees in mass, does it? I lost the countless attempts to make a better language for the web and they were all killed off by the Stalinists at w3 and mozilla. As I said, react is a symptom of that stupidity, not the cause. I've said it before, I'll say it again: a good engineer and a good community are defined by their ability to say "OK, that was a stupid idea, let's go back to the drawing board". The web is in it's worst shape it has ever been. Coldfusion, flash and the ridiculous java applets were heaven compared to what we have now.
Whether the aesthetics are good or bad does not dictate whether a language is a “programming language.” That is determined by whether you can write programs with it. JavaScript is used to generate billions, if not trillions of dollars each year, through the fact that you can run programs on a computer with it, therefore being a programming language. There’s no subjectivity there, JavaScript is not a toy. Incidentally, there are a lot of spaghetti code encouraging platforms like LabView, Matlab, and PLC which nevertheless accomplish similar results, even in safety critical applications. Those are not toys either, despite their lack of sophistication.
What the language designer accomplished is not simple. JS packaged functional expressivity and dynamic binding from Scheme and Smalltalk into a marketable form using Java/C syntax. That is not a corruption, it’s a design feature. Languages that use S-expressions, while pleasing to the purists, do not see much market traction. The best languages are the ones that balance functional idealism with pragmatism. It is true that the language has warts, but there is ultimately a reason that all the JS alternatives, such as Flash, Applets, Silverlight, VBScript and Pyodide failed.
I agree the web is worse now, but it’s not due to technical reasons. We have more options for web coding than ever before with AsmJS and Wasm, plus all the compile-to-javascript languages. You can choose to write using one of those ‘superior languages’ like with Scala.js, Elm, Elixir, Clojurescript, or any number of runtime translation layers like Brython or Skulpt, but people don’t choose to. Because that isn’t the problem. The problem is that businesses want less logic in the backend and don’t find sufficient benefit in optimization to prioritize it over feature work. That’s a disturbing business trend and hardly related to technical choice. For most operations, JS is blazingly fast due to the millions of hours that have gone into optimizing it.
Last, the people who are beginners and don’t understand the stack or heap, are not the ones running Webpack and writing (a significant amount of) React code. Those are distinctly different personas, and conflating them is insane. Either you are seasoned and can deal with the complexity that is the JS tooling infrastructure, or you are not and you probably aren’t using it as a result.
What the language designer accomplished is not simple. JS packaged functional expressivity and dynamic binding from Scheme and Smalltalk into a marketable form using Java/C syntax. That is not a corruption, it’s a design feature. Languages that use S-expressions, while pleasing to the purists, do not see much market traction. The best languages are the ones that balance functional idealism with pragmatism. It is true that the language has warts, but there is ultimately a reason that all the JS alternatives, such as Flash, Applets, Silverlight, VBScript and Pyodide failed.
I agree the web is worse now, but it’s not due to technical reasons. We have more options for web coding than ever before with AsmJS and Wasm, plus all the compile-to-javascript languages. You can choose to write using one of those ‘superior languages’ like with Scala.js, Elm, Elixir, Clojurescript, or any number of runtime translation layers like Brython or Skulpt, but people don’t choose to. Because that isn’t the problem. The problem is that businesses want less logic in the backend and don’t find sufficient benefit in optimization to prioritize it over feature work. That’s a disturbing business trend and hardly related to technical choice. For most operations, JS is blazingly fast due to the millions of hours that have gone into optimizing it.
Last, the people who are beginners and don’t understand the stack or heap, are not the ones running Webpack and writing (a significant amount of) React code. Those are distinctly different personas, and conflating them is insane. Either you are seasoned and can deal with the complexity that is the JS tooling infrastructure, or you are not and you probably aren’t using it as a result.
The language designer's intentions were completely different(very similar situation as the situation with php). His intentions were to give very basic interactivity to the plain documents that was the web. And for that purpose javascript is fine. For anything beyond that, it's simply retarded. I've worked in large corporations for most of my life and in all instances stunts like javascript-only development or react were the consequence of either someone from management being a javascript "developer" or management blindly trusting their "top engineers". Just open up history books and look at how many times humanity has been wrong. Hell, just turn on the news and look at the political landscape - the people who were democratically elected, and you'll instantly see what I'm on about. My argument remains equally valid for the people developing those frameworks. The fact that their barebone examples eat up 200 megabytes of memory and basic navigation pumps up my cpu to at least 40% is a clear indication. And my personal computer is not a raspberry pi gen 1. Far, far from it. Look around HN and you'll see a growing support for my message: javascript is crap and needs to be abolished.
As for javascript being "blazingly fast": lol. Compared to what? calculating 924^42 with pen and paper? Yeah, in that respect it's fast. For anything beyond that it remains a paper plane. Wasm initially terrified me because it potentially opened the floodgates for all the "developers" to jump into what are real programming languages and make a mess out of them too. For the time being it's fine though: Jumping from
this.prop.element.parent.third_degree_cousin.grandParent.neighbors_dog.value.get_value().toInteger() = this.prop.element.parent.third_degree_cousin.grandParent.neighbors_dog.value.get_value().toInteger() + 1;
to
type ConnectionError = Box<dyn std::error::Error + Send + Sync + 'static>;
is not humanly possible... For now...
As for javascript being "blazingly fast": lol. Compared to what? calculating 924^42 with pen and paper? Yeah, in that respect it's fast. For anything beyond that it remains a paper plane. Wasm initially terrified me because it potentially opened the floodgates for all the "developers" to jump into what are real programming languages and make a mess out of them too. For the time being it's fine though: Jumping from
this.prop.element.parent.third_degree_cousin.grandParent.neighbors_dog.value.get_value().toInteger() = this.prop.element.parent.third_degree_cousin.grandParent.neighbors_dog.value.get_value().toInteger() + 1;
to
type ConnectionError = Box<dyn std::error::Error + Send + Sync + 'static>;
is not humanly possible... For now...
JavaScript is fast compared to what it used to be, and faster than Python for example, in many circumstances. [1]
As far as large groups of people being wrong, that also applies to HN. The industry trend has been toward larger frontend components, and that’s not because of tyrannical engineers (since when do engineers have business power?). It’s just cheaper to create code on the frontend a lot of the time, especially if you have to weigh writing the code in JS versus e.g. Go with a properly formed GraphQL backend.
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
As far as large groups of people being wrong, that also applies to HN. The industry trend has been toward larger frontend components, and that’s not because of tyrannical engineers (since when do engineers have business power?). It’s just cheaper to create code on the frontend a lot of the time, especially if you have to weigh writing the code in JS versus e.g. Go with a properly formed GraphQL backend.
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Go unfortunately suffers from something similar: packaging. Even if you don't know the history of go, you have to look at it only once to figure out that this part is a hacky afterthought. Like everything in js. Also comparison of scripting languages is the stupidest thing one can do and I'd have expected better from debian but oh well...
My point remains: javascript is the stupidest language ever made(including the esoteric languages) and it should have been scrapped a long time ago. I have 1000+ books on my shelves next to me and if I start describing the utter crap found in javascript, I'd have to write 10 times as much. Stupid type system, idiotic paradigms, no clear structure, shit standard library, inconsistent naming conventions even in the standard library alone, it's as compatible with lower level languages as olive oil and alcohol(ffi is absolute shit with outrageous overhead), slow, unpredictable, does not have a clear way to do basic stuff like deep cloning.
But you are right, it's cheaper to write an interface using javascript. But if cost saving is our top priority, there's yet another argument for scrapping it altogether: ncurses. 10 times faster to write, 10000 times better performance, runs on anything with a screen. I'd totally vote for dropping the current web in favor of console-based web.
My point remains: javascript is the stupidest language ever made(including the esoteric languages) and it should have been scrapped a long time ago. I have 1000+ books on my shelves next to me and if I start describing the utter crap found in javascript, I'd have to write 10 times as much. Stupid type system, idiotic paradigms, no clear structure, shit standard library, inconsistent naming conventions even in the standard library alone, it's as compatible with lower level languages as olive oil and alcohol(ffi is absolute shit with outrageous overhead), slow, unpredictable, does not have a clear way to do basic stuff like deep cloning.
But you are right, it's cheaper to write an interface using javascript. But if cost saving is our top priority, there's yet another argument for scrapping it altogether: ncurses. 10 times faster to write, 10000 times better performance, runs on anything with a screen. I'd totally vote for dropping the current web in favor of console-based web.
> 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.
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]
> 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.
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.
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.
> escalated into nasty, sweary arguments
I feel like this person would have been fired at some point, with or without React...
I feel like this person would have been fired at some point, with or without React...
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.
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.
I think I've never seen a HN post age so badly in such a short time.
The title isn’t meant to be literal. https://duckduckgo.com/?q=nobody+ever+got+fired+for+buying+i...
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.
I've been learning Flutter, which is basically Google React and I'm a bit disappointed. I was hoping for something better.
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.
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.
That blog is weird. Changing to a different browser tab and back changes the scroll position a lot.
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?
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.
What A Stupid Title
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.
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.