HN is rarely the place to read constructive comments about JavaScript and frontend development.
Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel productive with it.
Also, TypeScript is awesome.
While I'm not particularly hostile to javascript or React myself, I do notice that over time, I tend to avoid it whenever I can. It wasn't too long ago that I made (gentle) fun of Intercooler.js (what happened to that person and their tireless efforts to insert it into any vaguely relevant conversation?), for example.
But nowadays, I'm fully on the Phoenix LiveView bandwagon (React/js on the server!), and I would absolutely use Svelte or Intercooler if LiveView wasn't an option, I grumble whenever I need to deal with my js pipeline (Webpack, PostCSS, etc.), and whenever I do need to deal with it, I get an almost existential 'where did things go wrong' feeling. Maybe I'm just getting old, in front-end developer terms anyways.
All I know is that for the past year I've barely kept up to date on the latest in React (Hooks?!), CSS (grids? flexbox?), js bundlers, browser features (webworkers? the latest in LocalStorage? webcomponents?), and so on, and instead I've been dealing with databases, servers (nginx, linux, etc.), and other 'back-end' things instead.
I feel much, much less frustration because suddenly things stop working and I need to dive into the complex world of webpack and its loaders, CSS and it's various browser incompatibilities, and so on. But I also feel that the things I /do/ learn will probably be valuable for years to come.
The insane amount of stuff I've learned about jQuery is practically worthless now. The same goes for Bootstrap and Backbone.js. Or various CSS layout tricks (dear god the floats). But what I'm learning about Postgres and Ngix and Railsy back-ends seems like the kind of stuff I'll be able to use (and make a living off) for a long time to come.
I do really like TypeScript though. I'd love to use that more :).
So, so true. Not even just JS though. Community can be rough on people generally.
/r/webdev, /r/javascript and /r/reactjs too
I consider this a slight inconvenience but still a better system than having the dang hammer around to pound spammers ..
JS isn't going to get compile time anything. There was an attempt at adding "strong mode" by one of the google / chrome teams iirc and that went nowhere.
I think there were discussions of doing that at some point, but it seems to have gone nowhere.
And you could transition off of Typescript just as gradually as you could transition on to it.
On the other hand Flow is much less cool than TypeScript these days. Plus using it for development under Windows have issues, although FB has started paying attention to them.
Although I still hit enough annoyances that I'd go straight to `.ts` files for my next project.
You have to be aware these features would need to be manually converted back to JS were you ever to switch back. Honestly this would likely not be a significant amount of work, especially if you don't overuse them, but just to make you (GP) aware.
- It starts you off with about 40kB of minified gzipped javascript; some developers feel that it's too much.
- It is not and probably never will be the most performant framework out there, which upsets quite a few people (although the work that the React core team is doing with Concurrent Mode probably means that from the end user's perspective React will feel fast enough).
- It has become the default way for many frontend developers to write JavaScript; I know I am personally guilty of that. This generates a lot of resentment from more experienced developers who have learned to prioritise minimalistic JavaScript bundles over developer experience.
I've seen it in a couple of other individuals as well, and I feel it's becoming more widespread, though I hope I'm wrong. In these instances, I see the framework existing both in the code as well as the mind, and operating outside of it is often a leap too far.
this has been my experience too, I'm a full stack engineer playing a devops role right now on a greenfield govt project. Getting our CI/CD pipeline going within our environment constraints with react has been a pain in the ass. Every time something goes wrong the front end dev just kinda throws his hands up and basically tells me its my problem. I ended up having to go through all the issues opened on github to find solutions and implement them myself. I'm no javascript expert but to me the solutions seem to be super hacky when I've found other frameworks out there that handle these things out the box or more gracefully.
I was on a project supporting legacy code for a long time before this, and was quite looking forward to working with newer js frameworks but this left a sour taste in my mouth. And I already had a bad impression of react prior. I might look into pushing for some of the alternate frameworks out there.
> the solutions seem to be super hacky when I've found other frameworks out there that handle these things out the box or more gracefully.
I'm curious to hear what alternative frameworks handled these things better? The only one I've used recently, other than React, is Vue.
There's a slew of workarounds offered in that github issue, most people (including another team in my org) opted to just rebuild the app every time a docker container is created which kind of defeats one of the major pros of using docker IMO.
I ultimately ended up forking off this repository and customizing it to my needs https://github.com/beam-australia/react-env
that solution in itself is very hacky.
as far as I know, vue doesn't have this feature either but I think next.js and nuxt.js does.
I probably don't appreciate the complexity of the issue, but I would say environment variables are not React's concern; it’s up to you how to architect your code. If you want runtime environment variables, then either add them to the html that React will render into, so that the javascript code can read these variables in before rendering, or have an api endpoint that your app will query before or during rendering and will get all the relevant config information from it.
> but I think next.js and nuxt.js does
Probably because they server-side-render. And even if your app renders on the client side; even if you don't use next, nuxt or whatever, there is no-one stopping you from dynamically serving the html skeleton with the relevant variables in it.
But then, it all probably has been mentioned in that issue. I wonder why it wouldn't be a good solution.
I don't consider it part of the "code" but part of configuring the application based on the environment you're deploying it on(Precisely why the FE dev basically said its not his problem). The fact that a lot of people are suggesting you just build the app every time you deploy a docker container is really concerning to me.
> I wonder why it wouldn't be a good solution.
it just feels dirty. it's the fact that I have to add these into the code that it feels like a hacky solution for a production app. using a shell script to read read the OS environment variables to create an ENV file then convert that ENV file to a javascript file that is then read, it seems like many things can potentially go wrong.
Ideally they would just deal with this within the dotnev library
Here, for example, is an article describing such an injection at the nginx level: https://medium.com/@jans.tuomi/how-to-use-environment-variab.... Or you can serve index.html using a full-fledged dynamic server, such as Node, and inject environment variables there (and probably cache the response for good measure as well, not to overstrain Node). This really is not something that is React’s responsibility — although it may very well be the responsibility of the frontend developer to set this all up.
All those solutions you mentioned I've considered and are mentioned in the github issue. I just think its way too much work and overly complicated for what is basically a prototype. Which is why I opted for the simple hacky solution.
> This really is not something that is React’s responsibility
This is why I'm already pushing for our team to move off react I don't think its the right fit for us. We also don't like JSX
I don’t think it’s really too big of a deal, but I wish people would be more realistic and use less hyperbole. Everything has trade-offs, one’s own personal honey moon ending does not mean we were all blind and/or ignoring the faults with things.
When the latter become dominant, there should be even more subsequent, innovative ones.
And the cycle will repeat.
But it's less net shittiness with every generation. And how many generations are we even in so far? C is '70s security gore, C++ is an '80s attempt to force OO memes that we've come to regret onto the '70s security gore, Python and Java are '90s OO memes in earnest, JavaScript and PHP were kludgy mistakes slapped together in a fit of desperate confusion to get some web shit to run, aaand...
Not necessarily because I have many complaints about it, but because I consider it in essence very similar to C++17, with (not-too-)different syntax and a few different but important design decisions in the core language and standard library. Seeing it sold as a radical paradigm shift from C++ has always left me feeling that some people are in for disappointment down the line.
As I continue to see how very experienced C++ programmers make exploitable bugs that passes all reviews and that are compilation errors in Rust saying that Rust is C++ with a different syntax is very naive.
- if you learned react by yourself years ago, you had to go through a lot of pain: the doc was terrible, the ecosystem a moving flaky target and conventions were not established. Things are better today, but it's not something you forget. Somebody starting react in 2018, and with create-react-app, will feel much happier.
- if you come from projects were you sparkled JS a bit, and suddenly you move to SPA with react, which is the experience of many, it feels like a wall. In fact, for many, React is the gateway to JS, and it pays the price for it: if you dislike working with JS (which is not uncommon if you come from another language like Ruby, Python, etc), you associate it with React. If you don't do JS full time and suddently must embrace the full stack of it just to make a UI, it's overwhelming. And despite the message you can use bare bone react, nobody does that: you use react, you eat the burger tower with it. Webpack reputation espacially, tainted react reputation.
- react has been oversold and overhyped. It doesn't help that the react community has been in deny of all its problems for years. They fixed many eventually, but before they did, they claimed it was all wonderful. It felt insulting for some people, espacially senior devs from other techs who knew the youngsters in front of them were full of it.
- the whole store concept has been a debacle. First there was a mysterious name (it's a plane, it's a train, it's flux!), but no solution. Then there were too many. Then Redux won. But Redux is so full of boilerplate. But wait, "you don't need Redux". But then people hacked many solutions internally to avoid redux with no guidance. Then redux toolkit and react provider arrived. In general, react and its ecosystem changed too fast. Way too fast. Unless it's your full time job, it's very hard to keep up. If all techs did that, we'll never be working. Combine that with the JS community desire to always use the latest toy, and you get a rat race. People have work to do, they don't want to deal with drama. React ecosystem is a drama queen.
- there is no convention on how to write a react project. Everytime you move to a project, it's a new project. You relearn the layout, the naming convention, the way store is handled, how things are passed around, the libs used for basic things, the testing infra, glue code for said libs, how you deal with css, the granularity of components, API best practices, etc. Not to mention the flavor you are in, depending of the version of react used and the fashion at the time. That's just for react. Then you deal with the other JS techs.
- so now, how do you know what to do? Who to trust? Where to get the gospel from? Thousand of tutorials, many imcomplete, obsolete, unpractical, specialized or dishonest. Just the way to manipulate something as simple as props have so many variants with different implications, and you got them all online. All. Of. Them. If you come from the ordered and well established world of backend frameworks, it's a mad house.
- then there are the gotachas. setState() is asynchronous, auto bind on createClass, but not on extends (but yes if render()). There you gotta call super(props), not here, useEffect dependancy management... React is full of them.
- when the magic doesn't get you, it lets you down. Some basic operations, like settings classes, preventDefault, communicating with the parent, etc. that you do all the time, are incredibly verbose for no good reason ("it's just JS you all!). Most other libs have shortcuts for them. In fact, most react projects add libs to get on par. When I train people in react and they ask me how to do this simple thing, I get desperate looks: "really?".
- integrating react with legacy frameworks like RoR, Symphony or Django is really, really not fun if you don't have a SPA with an REST API. And everybody does it differently.
- react native code reuse was a lie. A damn lie. And its great perfs as well. Nobody likes to be lied to.
- the immutability story is the last straw. I get the benefit of it. But for the vast majority of projects I met in the wild, the cost is way to high. This has so many ramifications I would need another comment just for this one.
Bottom line, if you work with seasonned programmers like it's often heard on HN, you can make the best of react. If you don't, and I work a lot with schools, administrations, average corporate IT deps, etc., the cost of react is going to weight on the team.
The teams that can manage React correctly are not that many outside of our bubble.
And for the ones that can, the price of using react may just be not worth it.
When I give the same exercice to do with Vue and React, beginners doing Vue finish in half the time. So I usually advice for Vue. Life is short, and you are probably not facebook at scale.
Stuff like this is rarely part of the sales pitch for any framework. You only find out after being locked in neck deep. Still from all the browser gui frameworks I think react is the safest choice.
Why? Well it is reliable and scalable enough and create-react-app makes the whole experience acceptable. It will not get you into trouble. Choosing any of its non-mainstream competitors might get you into deep shit if the project fails. Choosing any of its mainstream competitors like Vue or Angular seems like not a big improvement over react (if it even is) and will make you go into defensive mode anytime a junior dev knows that feature x would have been easier to implement in react.
React native performance is good too it just doesn't come for free. You need to know how to do native animations and you need to do late binding and all the other performance optimisations you should be doing with React anyway.
The only thing that lets React Native down is the tooling. I've had the debugger repeatedly push stale code on refreshes, the source mapping is atrocious and sometimes the network debugger just refuses to work. Also sometimes the app fails to load and you need to reload the app and or restart the debugger and or restart the packager in the right order.
I've found RN performance passable but underwhelming. It seems generally worse than a good native UI, and no better than a mobile web UI.
I don't understand why the JS is run in a separate thread, rather than just using the UI thread for UI (as it's intended for). By making all the interaction with the native toolkit asynchronous, it adds extra latency and leads to unavoidable glitches in native widgets used as controlled components.
Animation in React Native is much more of a hassle than UIKit or even CSS. (About the same as native Android, though, where it's also pretty tedious.)
My experience was that RN was way more helpful on Android than on iOS, in general. But that has more to do with Android than RN, which achieves its utility on that platform by papering over a pile of bad decisions, inexplicable awkwardness, and half-finished-apparently-by-the-Summer-interns APIs, none of which should be problems in the first place. I'd seriously consider using it for just for Android even if I wrote a separate, native iOS version of the same app.
The tools are starting to get fairly good on Android. There’s a lot to like about Android Studio. But the actual platform APIs are still a mess.
The extra latency for a layout change is most noticeable if it's an animation hence why you should use native animations not JS polling animations. I agree the Animations API is not as easy as CSS. If you want to do complicated stuff you need a lot of experience with it. This is one of the major hurdles for new RN devs.
Its possible to get good performance our of it, better than mobile web UI, you just need to have some experience with what costs and what doesn't.
I’m working on an alternative to React Native that does exactly this, and it works absolutely fine: React NativeScript.
In NativeScript (and thus also React NativeScript), the JS logic and the UI both execute on the UI thread. Furthermore, you can synchronously access any native API without needing to set up bridging code; bindings to the whole Obj-C/Java runtimes are ready-generated.
If I'm coding in a style that works fine on web, and also works fine in native code, but is slow in React Native, then I'd suggest I'm not the one doing it wrong, it's React Native itself.
This way layout changes are smaller packets so it doesn't saturate the low bandwidth of the thread bridge.
Even if they were to stick with the multithreaded architecture, it should be possible to build a layout structure in the background thread and just hand ownership over to the UI thread. I believe the RN team are working on doing this with their new Hermes runtime (sharing objects directly rather than marshalling them into and out of the JS engine), so that ought to help a bit. But I really think the threading model is just wrong-headed in the first place.
Its possible to get good performance our of it, better than mobile web UI
Is there a case study or even just an example that demonstrates that? I'm skeptical. Mobile browsers are very fast these days, so there's no obvious reason why RN should necessarily be faster.
I suppose RN might have an edge if you're making extensive use of native code. But then calling native code from RN is very laborious, so RN doesn't exactly pull its own weight in that scenario.
I think the reason RN is faster is because mobile browsers have to support decades of crufty CSS in their layout engines while native layout engines are much more lean and ripe for optimisation. React Native uses Yoga layout engine so there may actually be benchmarks available on that.
Totally agreed. I’m working on an alternative to React Native that addresses exactly this: React NativeScript.
In NativeScript (and thus also React NativeScript), the JS logic and the UI both execute on the UI thread. Furthermore, you can synchronously access any native API without needing to set up bridging code; bindings to the whole Obj-C/Java runtimes are ready-generated to begin with.
Give it a little time, see a few codebases, extend and build a few apps, then come back. Now people have some credible stuff to say. We can’t comment much about how great Hooks are after reading a few Medium posts. I’ll see in a few months when it’s all over the codebase.
HN will be full of ‘we rebuilt our api in GraphQl and boy things are a mess’ in 2 years.
For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it. For the former, I find writing GraphQL mutations more verbose and cumbersome than Redux.
In the latter, you need to worry about fetching, changing and saving state every time you need to make a change. With Redux on the other hand, your current state is fetched and saved for you automatically and you just need to worry about describing the state change in the reducer.
I also dislike the Query and Mutation components. The Query component can be fine for simple use cases, but it still ties your API calls directly to your component. What this often means that any business logic associated with the request goes in the component as well, leading your components to become bloated and untested.
The mutation component is even worse leading to super hard to understand code - you are basically writing your API request layer using HTML markup. For me its so much simpler to just have functions that call APIs directly instead of trying to understand some strange markup hierarchy.
In short, I can see the appeal of Apollo if your app had very little frontend state and just needed to be a reflection of the server. However, as your codebase grows in complexity, the patterns that Apollo encourages you to use lead to bloated and unmaintainable code.
Apollo is for GraphQL. I'm not sure why you'd try to use it's internal caching system to add local application stuff. Note that using Apollo does not stop you from continuing to use Redux.
> The Query component can be fine for simple use cases, but it still ties your API calls directly to your component.
This is what hooks aim to solve.
The Apollo caching system hasn’t been all roses; it can be pretty easy to wipe out parts of a cached entity you were needing on a view with the response to a mutation on a different view if you’re inconsistent with query and mutation response structure. But I find it convenient after getting the hang of its pitfalls.
To me that "entire stuff" is about the only thing that is good about redux (barely does dependency injection). See people need to understand that hook is a good API from the library authoring point of view (the react team's and react component library authors') it's not such a clean abstraction for people to write application on top of while unneccesarily make their code depend on magic react functions all over the place.
I cant count how many "data fetching hook solutions" I've seen on twitter. If something does data fetching, then it needs to know about fetch() and may be a reactivity abstraction like promise or rx. A hook is completely unjustified.
Hooks definitely lead you towards a different approach for writing components with a different set of tradeoffs. I talked about this in my post "Thoughts on React Hooks, Redux, and Separation of Concerns" [0], and my ReactBoston 2019 talk on "Hooks, HOCs, and Tradeoffs".
For React-Redux specifically, `connect` still works fine and we will be supporting it indefinitely. However, we're now recommending that people use our hooks API as the default approach, because it's typically simpler to work with and there's less indirection.
[0] https://blog.isquaredsoftware.com/2019/07/blogged-answers-th...
[1] https://blog.isquaredsoftware.com/2019/09/presentation-hooks...
I don't use React day to day in a big team so I can't comment on the maintainability gains, but as a user all I see is websites degrading the experience when migrating to SPA. If state of the art front end engineering with React is Facebook or Reddit then it's hugely disappointing.
Nothing surprising. Infact, I don't understand why the article is so highly upvoted.
Any jokes, memes or puns are frowned upon the community 99% of the time. I suppose it's considered redundant or not-constructive...
HN has a great sense of humor. I know this of course because my jokes have been upvoted.
But the pretentiousness annoys me sometimes, at the end of the day it's another forum of people who don't think they're part of a hive-mind... which we definitely are
HN readership is as establishment and conventional as it goes, it is the "study hard for the SAT/GRE/GMAT" crowd.
There are lot of very smart people there. You compare the recommendations in music/books/cinema between them and reddit and it is "People" vs "Cahiers du Cinema".They tend to create lots of Internet culture, the humor is caustic but it can touch genius from time to time and they are very open regarding topics like sexuality,depression, economics and so on.It is proof there is always more that meet the eye.
My point is there are affectations in both communities (4chan and HN) that are strange opposites of one another. Here, people often pretend to be more polite and erudite than they are, there, people often act more rudely than they normally would, because that's the culture, that's the mask you're expected to wear.
And on both sides there's a pretension which you're kind of displaying. You're talking about a site as vast and varied as Reddit as a whole as if it were a single forum, and dismissing it as qualitatively lesser than an anonymous imageboard that has shitposting as a central part of its identity. Find some well moderated subreddits for any particular genre and you'll find quality of conversation equal to anything on 4chan, or even HN.
Also, you know, 4chan has been around long enough at this point that a lot of "out of touch academics" and "journalist boomers" have probably been there.
And it's also constantly evolving and getting better. Just recently I started a React project with class components only to learn that hooks are now a thing and they remove a lot of boilerplate code. Even with redux, redux supports hooks as well so you can scrap that entire connect() stuff alltogether. Just back to simple function components.