
An experienced Javascript developer’s account of learning React - gianlucaguarini
https://medium.com/@gianluca.guarini/things-nobody-will-tell-you-about-react-js-3a373c1b03b4
======
olavgg
At our company, we have banned React, Angular and other "overengineered" JS
frameworks.

Our HTML is rendered from a standard boring Groovy server page, with some
vanilla-js for DOM manipulations here and there.

We have hired developers that were React fans, which quickly changed opinion
that this old-school way for developing web applications is indeed better. It
is faster to code, an order of magnitude easier to maintain, DOM rendering
time is faster, so a click to open a new page/view happens instantly. Our web
application is so fast, that non tech people and clients always comment how
smooth and slick it behaves compared to Facebook or LinkedIn.

Our clients are very happy with our solution too, as it is very simple for
their developers to integrate our solution into their web application since it
doesn't mess up their existing web framework. It doesn't block their rendering
time, and it is easy for them to override changes.

We also have one complex UI part in our application, which can consume some
CPU. This part we render with canvas, and it feels like a native app as it
runs stable at 60fps. Who wants to run a lot of slow DOM manipulations when
canvas is a lot more efficient.

~~~
wavefunction
Angular/Angular4 is a joy to develop with, so that's too bad you're limiting
yourselves artificially.

We have groovy in my stack at work and everyone despises it. Fortunately
that's a legacy we're moving away from.

~~~
izacus
But is it joy for customers to use the stuff you wrote in it? So many of these
opinions always focus on the developers having fun instead of wondering what
experience is for the user and maintainers.

~~~
vladgur
It's a valid question that has nothing to do with a tool/framework and
everything to do with product goal and time/resources

------
kasbah
I am confused why people think Redux is complicated. Maybe you were trying to
use React-Redux? Redux itself seems incredibly simple to me, so simple that I
sometimes wonder if I need a library for the functionality at all.

This "Redux in a nutshell" sums up the simplicity nicely I think:
[https://gist.github.com/MarcoWorms/30758235f05faec844b8c06ce...](https://gist.github.com/MarcoWorms/30758235f05faec844b8c06ce2e5bac9)

~~~
sotojuan
I've had the same experience. It took me about a week to "get" Redux as a new-
ish dev back a year or so ago. Why do you think people have trouble with it?

~~~
throwaway2016a
> It took me about a week to "get" Redux

You hit the nail on the head. Devs these days get frustrated if it takes more
than an hour.

------
ckorhonen
Switching to React definitely has a learning curve, especially if you are
coming from old-stool JavaScript or just not used to some of the concepts in
React or Redux themselves. That said, once you get your head around it things
start falling into place.

We're recently built a React Native app and I feel the benefits it brings to
cross-platform development make that ramp-up worthwhile. A single iOS and
Android codebase is a glorious thing, and helps avoid needing silo's of
specialized developers.

I would say that the maturity (or lack thereof) is obvious when using React.
The big ideas are solid, but there is a lot of thrashing - you need to watch
each new version for backward-compatibility issues and carefully manage your
dependencies. Coming from Ruby/Rails, I also feel like React is still at the
point where you're spending a lot of time configuring things vs adopting
standard conventions - it's getting there, and projects like react-navigation
are helping build up that boilerplate, but certainly can be frustrating at
times.

~~~
lawik
I saw a fascinating talk on Redux, I like the idea of how it manages state and
the whole event sourced approach to that.

I've repeatedly tried to get Redux going with either React or Vue but have
found it surprisingly hard. Many outdated seed projects and installation
instructions made it somewhat painful.

I've played a bit with React from the more recent create-react-app and that
got me started with some of it. I haven't been sold yet, I realize that I want
something to cause the events and update the DOM but I haven't been sold on
why React is best for that yet.

Always annoying when you try to approach some tech and have a hard bounce off
of it.

~~~
acemarke
If you've got questions on using React or Redux, please feel free to drop by
the Reactiflux chat channels on Discord and ask. I hang out there most
evenings, and there's many others happy to help as well. The invite link is at
[https://www.reactiflux.com](https://www.reactiflux.com).

In addition, I keep a big list of links to high-quality tutorials and articles
on React, Redux, and related topics, at [https://github.com/markerikson/react-
redux-links](https://github.com/markerikson/react-redux-links) . Specifically
intended to be a great starting point for anyone trying to learn the
ecosystem, as well as a solid source of good info on more advanced topics. It
includes links for learning core Javascript (ES5), modern Javascript (ES6+),
React, and much more. I also published an "Intro to React (and Redux)"
presentation at [http://blog.isquaredsoftware.com/2017/02/presentation-
react-...](http://blog.isquaredsoftware.com/2017/02/presentation-react-redux-
intro/) , which is a good overview of the basic concepts for both React and
Redux.

------
jinushaun
Doesn't mirror my experience at all. Most of the post is complaining about the
ecosystem, which you don't need at all to use React "properly". React is just
the view piece. But in any substantial project, you will have to figure out
routing, data storage, networking and cross component communication.

And you shouldn't write large blocks of conditional logic in the markup code.
That's bad whether it's PHP, React or Angular.

And complaining about className? Really? Is the author not aware of reserved
words?

------
darth_mastah
I agree. React is a great rendering library which somehow became the core of a
mix and match framework, plagued by backwards incompatibility and maintained
by plethora of individuals. As a result upgrading dependencies is never safe
and and each of tens of them is quite likely to introduce breaking changes or
become obsolete, leaving you having to make unnecessary changes in your app.

Don't get me wrong, I think React is good at what it does, which is rendering.
I just don't think the maintenance of a react app, which includes dependency
management, is worth the benefits. Similarly the current model of reinventing
everything in the "react way" is hardly speeding up development.

~~~
chrisco255
There are like 13 exposed functions in React: render, componentDidUpdate,
componentWillUpdate...It's as simple as it gets. What breaking changes? The
core API has changed little. And what they have changed is simple to adapt to.
They've added stateless functions and switched to ES6 style classes and
removed mixins.

~~~
darth_mastah
I was talking about React ecosystem, rather than the library itself. The
latter is solid, the former though... not so much.

------
garysieling
The best explanation I've seen for why React is such a pleasant experience, is
that it's a text-based version of the best parts of Visual Basic - you use
React to lay out pre-built UI components, build your own new ones, and the UI
behavior is a function of the properties you set.

React, and similar libraries, have the advantage of being parasitic - you can
fit them in along with a lot of what's already out there, without necessarily
having to rewrite what you've already build. I.e., you can easily use UI
frameworks that are agnostic to Javascript library pairings.

As an example of this, I built
[https://www.findlectures.com/](https://www.findlectures.com/) with TypeScript
+ React, starting with no CSS library, then added bootstrap, then replaced
Bootstrap with Semantic-UI. This makes me appreciate some of the flexibility
of the ecosystem now, even though it comes with the pain of having too many
options for a lot of the individual components.

~~~
guscost
This makes a lot of sense. In practice each component can function as a
complexity-hiding layer, making integrations with other code a breeze compared
to the status quo.

[https://en.wikipedia.org/wiki/Abstraction_layer](https://en.wikipedia.org/wiki/Abstraction_layer)

------
jaequery
im going to just say whats on my chest.

it makes me wonder if react devs who thinks react is the greatest thing since
sliced bread are somewhat new to web development (less than 2-3 years or so).
because im sure those who inherently know, would find that vuejs is just a
superior framework (sans native). there will always be new frameworks that
comes out and some will be better than the last. and vue to me is leading the
forefront and does things that makes sense for web development. once vue
releases native, i think there arent many reasons to use react if vue is
available.

when ppl say react is the best or that its for complex apps makes me shake my
head, as those who believe that may be just naive or dont have much experience
to make up their mind.

experience over time, leads you to strive for patterns and elegance, and
unfortunately react doesnt have that which makes it feel there is a bit of
immaturity in the framework. this is why i wouldnt be surprised if many if the
react fans are the way they are in their stance.

its just my two cents from an old js dev who have seen through over 15 years,
so your views maybe different from me, but should be similar to those who
knows what im talking about.

~~~
masiulis
I don't think that years of experience has anything to do with liking vue or
react. I know how you feel, because my colleague had similar thoughts on
React, he even created something very similar to vue a few years before
vue(jade+css+js in one file). While I just use pure virtual-dom (no jsx) and
almost nothing else.

The way you put it, some people look for patterns and elegance, while some
look for simplicity (no special v-bind or v-if), modularity and deletability.
There is nothing more senior about one way or the other, just different
personal preferences.

------
mambodog
This post is misleading throughout.

The article shows snippets from the Redux and React Router docs, implying they
are realistic examples of the way that typical React code should look,
however, they are clearly snippets which are trying to show the entirety of an
API on one screen. If your code is just a bunch of snippets copy-pasted from
docs without much thought given to the structure of your code, your choice of
UI library isn't the problem.

On React Router, React Router is not React. You don't need to use React
Router. There are plenty of stable pure JS routing libraries, which don't
release new versions often (or ever, because they are 'done'). Nothing about
React requires you to use a React-related routing library.

The author found Redux and MobX too complex for their use case. However, Redux
and MobX are not required to use React (there seems to be a theme here), and
probably not useful if you don't have a big single page app with a lot of
client side state. Implying they are intrinsic aspects of using React is
wrong.

The bits at the end:

 _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_

The react and react-dom packages are being split so react-native doesn't have
to pull in dependencies which are only used on the web. Not that different to
Rails splitting up into a bunch of gems.

 _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_

This was an architectural limitation which is going away in the next major
version.

 _its apparent simplicity is hidden behind a whole toolchain you need to
configure before you can even writing 1 line of code_

Why complain about this but refuse to use create-react-app? It literally
solves this problem.

 _I started my app with React 15.5.0 knowing that my code is deprecate before
even starting because facebook has just announced that for the next major
release they are planning a complete rewrite of the framework and this means
that they will likely nuke the current source because it can be no longer
maintained._

This is FUD. The team has said that the next version of React will have some
small breaking changes, but the API will remain almost completely the same.
Not sure what they mean by 'nuke the current source' though.

------
tomwilson
The trick is - don't try and learn all this shit at once. Make a react app
without any extra state management. Just store your state at the top and pass
shit down. Add more stuff until it starts to get annoying passing all the
callbacks back up. Now you are ready for redux cos you understand what it is
saving you from.

React itself is actually really simple and a nice way to make complicated UI.

~~~
darth_mastah
Yeah, it gets annoying really quickly. You go three components deep and you're
ready for redux.

------
bryanlarsen
Why is mixing HTML into your code in PHP bad? Because it mixes presentation
and logic.

Why is mixing HTML into your code in React good? Because it isolates all the
view code for a single component in a single file.

~~~
tigershark
In his example in the pre-preface there was quite a big amount of logic.. I
don't really see the point in your post looking at that code.

~~~
haukur
You can have complex logic and functions in JSX but that doesn't mean that you
have to, so the example is very contrived. That way of writing the code is
completely discouraged in the documentation and I haven't run across it often
or at all in the real world.

~~~
autoreleasepool
The example in the article was lifted from the front page of the official
React website [0].

[0] [https://facebook.github.io/react/](https://facebook.github.io/react/)

~~~
haukur
It wasn't lifted from the docs. The tutorial is a tic-tac-toe game, while the
example in the post is an AddTodo function [edit: there appears to be an add
todo section, but the code is completely different]. Furthermore, all the
examples in the tutorials show a pattern where you reference functions instead
of writing them inside JSX.

~~~
autoreleasepool
Check again. On the homepage scroll down to:

> An Application

" Using props and state, we can put together a small Todo application. This
example uses state to track the current list of items as well as the text that
the user has entered. Although event handlers appear to be rendered inline,
they will be collected and implemented using event delegation. "

~~~
haukur
Fair enough - it's a todo app. The code isn't structured in the same manner as
the author's, however, so my point stands. It doesn't look like the code was
lifted from the docs, as you said, but instead transformed to look like
spaghetti.

------
autoreleasepool
Regardless of these complaints, the job market for React is just too damn good
to ignore. I bit the bullet and began learning. As a newbie, I understand the
sentiment of this article. However, it's really not as bad as the author makes
it out to be.

Also, className instead of class took all of 3 seconds to learn.

~~~
xyos
Also `class` is a reserved word in JavaScript, author doesn't even notice
this.

~~~
tpaksoy
As mentioned in other comments, I don't have this issue of not being able to
use `class` in Vue. So it can be done better.

------
danabramov
I wrote a reply to address some of these points:

[https://medium.com/@dan_abramov/hey-thanks-for-feedback-
bf95...](https://medium.com/@dan_abramov/hey-thanks-for-feedback-bf9502689ca4)

Thanks for sharing!

~~~
bigato
I'd love to hear your reply to this:

"what do you expect from a framework with more than 1000 issues on github that
will let you install alpha dependencies by default (React@16.0.0-alpha.6) to
develop your native app?!?"

~~~
danabramov
Thanks, I missed this one! I added a paragraph:

 _> The version of the the react package is generally not relevant because it
contains very little code (Component and createElement). The reconciler code
is synced to React Native separately. So this an artifact of the different
release cycles of RN and React, and doesn’t at all mean that RN apps are using
an unstable version of React._

------
throw2016
The recurring pattern seems to be some new tech gets introduced, preferably by
a well known SV company. Usually it matches their use case and is a struggle
to adopt generically.

People scramble to learn it anticipating demand for jobs or contracts and
become part of the hype cycle. If they can kick start the the cycle then
everyone benefits and they are too vested to discuss quality, architecture,
design or anything that risks the gravy train.

Things can become haphazard. Technical or complexity issues take a back seat
and are hand waved away, apologism thrives. Discussion becomes heated as is
wont when it comes to money.

There can be 100 articles like this about React but it won't matter. Because
this is not about quality but economics. Even the most hardcore react fans
know the ridiculousness of its setup is not tenable technically or otherwise.

Experienced people won't respond to fads and certainly not badly designed one
as they have no need to. If the market for work was stable and less heated it
would be much more difficult to pull off these hype cycles.

------
arenaninja
I don't think the `className` argument sticks. `class` is reserved so you
can't use it. It's annoying but not a difficult concept

The other points are valid though. Mobx/Redux seems like a solution for big
applications, but what's the alternative for small-to-medium React
applications that still need to store state?

I agree I had issues following the snippets (and for one snippet I would
definitely have to check MDN to decipher ES6 syntax), but I wonder if that's
not an issue of style. Just like you can write PHP inline with HTML and you
can write JS with HTML in JSX storing snippets of logic in a variable
increases readability.

~~~
jazoom
It's valid. className was a frequent annoyance with React. That's one of the
nice things about Vue. I can paste HTML snippets and they just work. I can't
say it's the reason I switched, but it was some icing on the cake.

~~~
wand3r
What was the reason?

~~~
jazoom
A few reasons. The render() functions were unweildly. The ecosystem of
router/state libraries were in constant incompatible flux. Difficult
transition animations. Complex server side rendering setup. Probably some
other things I can't remember.

------
hazza1
The stampede to React has probably gone too far but it was very much a
reaction to the domination of Angular which from personal experience had made
web development a nightmare.

React proved you didn't need a huge overbearing framework to get things done
Vue and Riot takes this even further (even if Riot predates React)

------
thatswrong0
> Things nobody will tell you about React.js

Both HN and article title are misleading - this talks mainly about learning
mobx, redux, and react-router, and then has 4 little nitpicks about react at
the end.

------
Tade0
Exactly my experience, but with Angular 2+ instead of React.

To me, in comparison with Vue.js, both of these frameworks are grossly over
engineered.

I'm keeping a list of things that are, in my opinion, unnecessary or badly
designed in Angular 2+. After around two days of hacking I have seven position
and the list will probably keep growing.

------
baxtr
I have used vue as alternative a lot lately, and I must say it's great. Easy
to learn, reactive and fast.

~~~
idleworx
Same here. VueJS is a much better version of what Angular 1.x should have
been, and so much easier to work with.

------
guscost
In general the React approach works best if you are willing to build out a
handful of utilities on your own sometimes, rather than always choosing from
pre-existing open-source solutions. You don't need React Router. You don't
need React-Redux. Heck, you don't always need Redux, you can just throw a
state object on the window (or make a state module or whatever you do these
days).

Here's a React 15 app in a single HTML file, using ES5 and the old in-browser
JSXTransformer:

[https://gist.github.com/guscost/27736c5f0913184695492ac40fd3...](https://gist.github.com/guscost/27736c5f0913184695492ac40fd3a19c)

~~~
rikkus
I had high hopes there, but I don't see an app, I just see enough boilerplate
to put a <span>Hello, world!</span> into the DOM, which could have been done
by just writing that into HTML. I can understand what it's doing, but I don't
think it's a good example of how you can write an actual app without the parts
people are mentioning.

~~~
guscost
You'd include all the modules as separate script files. Each script file is a
revealing module[0] that exports its API to a global variable. If you're
interested I could put together a more complete boilerplate. I don't actually
use this approach much in front-end work these days, but it can be nice to
work with just text editor and browser.

As for building it, you're on your own. You could run jsx from the command
line, concat them all together and minify.

[http://stackoverflow.com/questions/5647258/how-to-use-
reveal...](http://stackoverflow.com/questions/5647258/how-to-use-revealing-
module-pattern-in-javascript)

~~~
darth_mastah
I may be wrong, but I use webpack to remove exactly the the pain point of
running jsx from the command line, concatenating files and minifying them. It
does good job there and saves me time.

~~~
guscost
It's a good solution, but webpack can be overwhelming to newcomers, and it
sometimes can lock you into working with associated dev tools like webpack-
dev-server and all the various loaders.

------
yomly
Thought I'd post this as a skim reveals no one has discussed testing.

While I am sure it is very possible to achieve this in other ways, the React-
Redux structure (dumb components handling presentation and redux handling
state) enforces a discipline that makes testing your client-side app far
easier than other solutions I've seen where logic and presentation are far too
often coupled. Recall that true vanilla ES5 does not even have modules.

There is certainly a lot of cargo-cultism surrounding React, but I'll be
always be grateful for it making the vdom and functional style of coding more
mainstream.

------
ashark
> Then imagine to meet a dev from the future telling you that in 10 years
> anyone will be writing their app routers in Javascript in this way

Yeah. The first time I saw JSX presented as something Super Serious and
Obviously Fine, We Don't Even Need To Talk About It I thought I was being
trolled.

I'd agree that if you'd floated this sort of syntax anonymously, even shortly
before React came out, the overwhelming response would have been "LOL what
talented but horribly misguided junior high student thought up this nightmare-
haunting terror? Lurk moar n00b."

------
vmasto
I was very intrigued by the title:

 _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](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...](http://stackoverflow.com/questions/38206646/do-we-need-to-import-react-
or-just-component-proptypes-will-do)

 _[...] 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?

[https://github.com/facebookincubator/create-react-
app](https://github.com/facebookincubator/create-react-app)

~~~
lawik
I've had really bad experiences trying to get going with React but I just
found this article ranty. I was also expecting something more interesting. No
feeling of depth to the analysis, just "I did not like this and now I will
complain about it".

I'm guessing english is not the authors first language so I won't dwell on it
but I found it somewhat hard to follow.

~~~
gianlucaguarini
Thanks for your feedback I have tried to fix some grammar and syntax errors.
Please ping me in case you find it still confusing

------
mark_l_watson
'skeptical of letting doing my job to cli tools like create-react-app'

I am also uncomfortable with magic boilerplate, reminding me of some
enterprise Java and Microsoft tech like DirectPlay.

That said, for some applications large libraries and frameworks can save a lot
of development cost, increase speed of development, etc. I find myself using
both very high level libraries and also working on stuff where I build most of
what I need 'bottom up' style.

------
dvcc
Things about the React _ecosystem_ pretty much anyone will tell you -- outside
of complaining about why you use className. Yea all the libraries and tools
get confusing. But, you don't need redux, mobx or react-router for most
applications; hell, if you don't like them use some other flux library or
router. That's what people like, React is not an all encompassing framework
it's just the view piece.

~~~
gianlucaguarini
I am glad it works for you and you are happy with it I get your point and I
agree with it. In this post I don't shout against React.js I just wanted to
tell you my experience with it without the need of convincing anyone about
using anything else instead

------
afro88
His point about React Native at the end is very reductive.

As an experienced (6+ years) iOS developer, my experience putting together a
dual platform app in React Native has been very positive. For the majority of
content driven apps, it seems to me that React Native is a no brainer.

------
zebraflask
I had similar thoughts when I first learned React. After building several UIs
with it, I think the core thing that trips devs up is that it's very easy to
make things far more complicated than they need to be. Beginner resources
often don't help, either. Many of the boilerplate and starter pack examples
you can find online have a ridiculous level of complexity in the file folder
structure, component structure, dependencies, etc. - for example, no, you
don't need half a dozen components spread across as many files to render a
simple header or footer.

If you try to stick to a minimalist approach, it can be a pretty convenient
framework. Definitely beats trying to do the same thing the jQuery way.

------
jlarky2012
Those are great points, my solution don't use Redux, Mobx and React Router and
webpack if you can. React itself is great thought, but for some reason it's
surrounded by over-engineered yet popular projects.

------
sergiotapia
Contrived example at the beginning of the article makes everything after it
suspect. My markup in JSX rarely looks horrible and in fact, it made my life
easier as a fullstack engineer.

------
ricardobeat
In fact React/JSX seem to have originated from PHP, though not exactly in the
way meant by the author. See [https://github.com/facebookarchive/xhp-
php5-extension/blob/m...](https://github.com/facebookarchive/xhp-
php5-extension/blob/master/README.textile)

------
idlewan
React popularity seems to me the result of wrongly-headed thinking: that
because facebook is popular, any technology behind it must be good, and
because react is popular (allegedly), react must be good.

I've always been very sceptical of react, and I'm glad I didn't invest too
much time looking into it, as it seems both a time sink and a boilerplate-
filled approach. I wonder why some people like it, writing no-framework
javascript isn't difficult at all, and you can organise it in a nicer,
readable way, plus there are many alternative frameworks that seem better. Is
it because of too many choices, people would hang on to the one they think
will stick?

~~~
dorfsmay
I am not a js dev, but isn't the issue of no-framework that you have to write
a bunch of code to deal for various browsers? And a bunch of more code to deal
with basic web patterns that you'll end up copying from project to project?

~~~
autoreleasepool
I don't see where the parent suggested no framework. It's likely he or she
prefers working a different framework or library, like vue.js or even jQuery.

For me, jQuery is the bare minimum requirement. I would never attempt to write
a large app in pure JS, even with babel. You would definitely run into some of
the problems you mentioned.

EDIT: I see now where he mentioned no-framework JS

~~~
Achshar
I have written relatively large (35k lines) project in pure JavaScript
(without even jquery) and have never faced any of the issues mentioned by the
parent, (Babel helped). I write native first and then run babel to appease my
older browser faring users.

The advantages of native are that it's extremely snappy to use and fast to
load. Bears smaller memory footprint (have to use angular.js at work and god
it's awful) and with newer things like async await, ES16 classes, etc code
management is very good. Can't recall the last time I had to take care of a
specific browser quirk.

~~~
tps5
I have no idea what "native" means in this context, care to elaborate?

~~~
Achshar
I beg your pardon, poor choice of words, native here means plain js. Nothing
more.

------
sdnguyen90
You don't need to use JSX with react-router and Fiber is not a rewrite of the
entire framework.

~~~
ashark
It's being reported like it is.

[https://techcrunch.com/2017/04/18/facebook-announces-
react-f...](https://techcrunch.com/2017/04/18/facebook-announces-react-fiber-
a-rewrite-of-its-react-framework/)

~~~
jlarky2012
People also reported that Hillary would win. In reality so far I don't see how
15->16 is different than 14->15

~~~
ashark
My point is you can forgive someone for that kind of error when there are
articles making the round from semi-reputable sources that include quotes from
sources that appear to back up their claims. Especially when it doesn't seem
to have a political slant or angle to it (aside, possibly, from someone at
Facebook deciding for PR reasons they should frame this as a complete rewrite,
in which case you're being lied to _by the people doing the work_ , so where
does that leave you?)

------
fibo
By the way, the author develops a great web tool called Riot.

