For front-end development some strong options in different languages are: Elm, TypeScript, Reason, Coffeescript (although Coffeescript usage has fallen dramatically every since the newer versions of JavaScript added a lot of its great features).
739 karma · joined July 16, 2013
Things nobody will tell you about React.js
Immediately had high hopes that someone is going to try and give a well researched, novel critique that maybe can spur out some constructive conversation.
And then, sadly, the author goes on to write exactly what countless other articles have already covered and discussed to the death for years now. "HTML in JS", "JSX is bad", "Redux is complicated", "The tooling is too much". And then here we are again in the front page of HN for some reason.
To me, this is, again, an extremely common case of "trying to learn everything at once".
Still, a couple of points I'd like to try to mention:
JSX: Has been argued about so much it's pretty much useless to try and add anything to this discussion at this point honestly. For whomever likes it, fine, for those who don't, thankfully the JavaScript ecosystem provides with a multitude of alternatives. For new-comers still trying to reason about it, this talk by Pete Hunt is a good start https://www.youtube.com/watch?v=x7cQ3mrcKaY
Redux:
> Anytime I work with redux I need to go back to its documentation because its core concepts are so complicate that my mind struggles retrieving them back puking them out as soon as I stop working with it.
While I agree that working with Redux at scale can be complicated, the core concepts are extremely simple: Async Action -> Action -> Reducer -> Connect data to your components -> Display -> Async Action -> enter an extremely simple data flow paradigm (flux).
(state, action) => state
Redux can get complicated when you add to the mix schemas, normalization, selectors et al. My advice and I can't stress this enough: Don't try and learn everything at once, start with simple core concepts, iterate later, add tiny new pieces when it makes sense. You don't always need Redux anyway.
RE: Redux boilerplate: It's a lot, yes, but that's by design. Redux is simply a tradeoff between boilerplate and repetitive, dead simple management of your complicated state. I'd rather write a few lines of code more if it means I'd avoid having logic bugs or getting confused where my data comes from.
RE: React Router:
[...] the maintainers had the great idea of bumping 3 major versions in 5 months completely not backward compatible to each other
This is simply not true. React Router has had a single major breaking API change in 2 years. RR 2 and 3 where the same thing and 4 has just now been released after 2 years of stability.
RE: Final complaints:
[...] you must use className instead of class to define the DOM css classes
This is an extremely weak point to complain about.
[...] you will need to import in your scripts react-dom and react without never using the last one instance for some wild reason known only by the React team
You only need react-dom once, to the point where you ReactDOM.render your application. You need React because you're using it implicitly with JSX. I'm not on the React team by the way, it's a simple google search: http://stackoverflow.com/questions/38206646/do-we-need-to-im...
[...] you can render functional components just by using js functions but you will need to wrap all your markup always in a wrapper tag to properly allow the Virtual DOM creation
Valid point, although it's a nitpick. In any case, this is going away with the newer version of React's reconciler (Fiber).
[...] its apparent simplicity is hidden behind a whole toolchain you need to configure before you can even writing 1 line of code
create-react-app is great, officially supported, and does everything, is it the fault of the ecosystem that the author is reluctant to try the official CLI?
This article goes into more depth: https://www.scirra.com/blog/173/just-how-evergreen-is-micros...
I'd be interested in the maintenance strategies you have in place (if any).
I assume that for plugins who don't output styles or scripts you use other methods, maybe some HTML output etc, so you've probably hard coded a lot of stuff for some popular plugins.
How have you set your tests and how do you plan on knowing when a certain plugin stops emitting the signature you're checking for? Most probably an E2E test with a local theme containing everything, care to share tech specifics ok this part?
Many people, especially newcomers, believe that just because their code initializes a class only N times it's being instanced exactly N times. This is false more often than not, especially in server environments.
It's not like you can describe it exactly, I've seen a lot of "the most accurate description of depression"s that really hit home, but there's no way to make someone understand what it's actually like.
I believe there was an idea of adding it as a pre-commit hook, a second one as a manual step and another one as a post-commit amend.
Have we reached a consensus on that? Not up to date what they went with, what seems to be the best way to do this?
It only takes a couple of outliers to bring everything down. I'm not exactly well-versed in defining specs for large scale backend apps (not a back-end engineer) but it seems to me that preparing for the average would not be a wise decision?
For example, designing with an average of a million requests per day in mind would probably fail, since you get most of that traffic during daytime and far more less at the nightly hours.
Could anyone more experienced shed some light?
What's more interesting to me is that everyone who converts their code into Flow or TS immediately finds at least N bugs (albeit small).
It's also quite amusing that this article came out today where HN's top article for a few hours was a bashing against Electron (and Slack specifically).
The author is claiming it's built on Electron, which is false.
It is and was, however, always built on Chromium Embedded Framework (the UI), even when you say it "was" fast.
Can you please share how you came to the conclusion that Spotify is made with Electron? (hint: it's not)
e.g. http://math.stackexchange.com/questions/2121175/is-it-possib...
I would suggest starting reading from here https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...
If you want to critize JavaScript you can do better with something more substantial. If anything, the speed at which problems you linked get remedied is a plus for the language. Even more so if you take into account the extremely unique position JavaScript is in where you can simply never change an API after it goes public.
> The fact that there are so many abstractions that compile/transpile into javascript is also a big red flag
What did you expect? JavaScript is the only language browsers natively understand. If you want to write code in your favorite programming language you will have to transpile/compile it to JS.
While this is certainly feasible (largely depending on the requirements of your app), it is important to clarify that RN never promised "write once ship twice".
RN's promise is "learn once, write anywhere", meaning that the technology and mental model is what transcends platforms, not the codebase itself.
Just wanted to make this clear so as to avoid any possible frustration for newcomers after the fact.