
Switching From React To Vue.js - anthonygore
http://vuejsdevelopers.com/2017/05/28/switch-from-react-to-vue-js/
======
__BrianDGLS__
I have built applications using React and most recently Vue2.

Both are very very similar and if you are familiar with one you will be able
to pick up the other quite easily.

In regards to webpages both are capable of doing the same things and fit the
same uses cases.

That said however if I was to start a greenfield application today, I would
choose React. The reason for this is that react is better known, it is easier
to find solutions for, and it has more mature guidelines for things like
project structure and best practices.

Vue is good competition for React and it will certainly help keep it on it's
toes. However in regards to longevity, I feel React will be around a lot
longer than Vue. React has the full support of facebook and is being used by
other major vendors. Vue is also used by some big sites, however it has no
official backing that I know of and is maintained by a "Benevolent dictator
for life".

In a year or two I predict that I will see another article with a title along
the lines of "Switching From React To <insert new hotness here>". It is very
unlikely in my opinion that I will see a "Switching From Vue To <insert new
hotness here>" article.

~~~
amauta
Vue is backed by one of the biggest companies in China. You need to do more
research. Vue is more popular in China than React. I would say I would rather
start a new an app using Vue because of the learning curve is a lot faster to
pick up than React.

~~~
subpixel
A non-trivial amount of info and discussion around Vue (esp. third-party
packages) is in Chinese. Whether that's a plus or a minus depends on whether
you understand the language.

~~~
piva00
That's for sure a minus, even if you speak the language. You are restricted to
a smaller subset of developers that can improve the ecosystem (and let's be
frank that most good developers should know English but not Chinese,
internationally speaking).

~~~
echaozh
The logic may not be sound as you cannot tell for sure if there are more
English speaking front end developers or Chinese-only speaking ones, given the
population of China.

~~~
voidr
There could roughly be as many front end developers in India ... which has 23
languages.

China also has multiple languages and dialects, see:
[https://en.wikipedia.org/wiki/Languages_of_China#/media/File...](https://en.wikipedia.org/wiki/Languages_of_China#/media/File:China_linguistic_map.jpg)

English is the lingua franca of software development and I don't see that
changing anytime soon.

------
Blixs
I have (some) experience with both React and Vue 2 and definitely prefer the
later. Vue is very minimalistic but unlike React provides a lot of
functionality out of the box. Stuff like the router, the computed properties,
automatic change detection, HTML templates, scoped css, animations, ... . But
what's more important is the fact it does all these things in an extremely
elegant and unobtrusive way. The computed properties are an often overlooked
but good example of this. You simply declare an object property that is
dependent upon other properties and voila, that's it. It's there in your
component together with the rest of your data for you to use in your template.
It gets memoized, it gets change detection, it just works (TM). No need for
Redux, Reselect, selector functions or any of those things. I love the
simplicity of this approach. And this is just an example, but this very
minimalistic approach applies to everything that Vue offers.

~~~
danmaz74
> unlike React provides a lot of functionality out of the box. Stuff like the
> router, the computed properties, automatic change detection,

I never studied Vue, but the article starts saying "Both have separate, but
commonly used, router and state management libraries". This doesn't look like
"out of the box" to me.

~~~
mcintyre1994
[https://vuejs.org/v2/guide/routing.html](https://vuejs.org/v2/guide/routing.html)

For most Single Page Applications, it’s recommended to use the officially-
supported vue-router library. For more details, see vue-router’s
documentation.

[https://github.com/vuejs/vue-router](https://github.com/vuejs/vue-router)

\--

[https://vuejs.org/v2/guide/state-
management.html](https://vuejs.org/v2/guide/state-management.html)

Vue offers vuex: our own Elm-inspired state management library.

[https://github.com/vuejs/vuex](https://github.com/vuejs/vuex)

\--

Out of the box or not, they're part of the same github org, they're officially
supported and they're documented in the official docs. I think this is just
splitting hairs.

~~~
danmaz74
Redux has been from the same github org for a very long time too:
[https://github.com/reactjs/redux](https://github.com/reactjs/redux)

And react-router, while not being on the same github, is pretty much
considered a standard too. It's ok to not split hairs for vue.js, but then you
shouldn't do the same for react...

~~~
wereHamster
react-router, do you mean v1, v2, v3, or v4 (or perhaps v5 and v6, I haven't
checked if there was a new release with breaking API changes during the past
12 hours).

~~~
buchanaf
I mean react-router is almost a 3 year old library trying to handle a rather
complex problem. The first three versions were largely the same with no major
changes that I can think of except for switching from context to higher order
functions.

I think everyone is a little dramatic about the number of versions of the
library, especially when they are going to continue to support v3.

~~~
ricardobeat
Well, that just makes things even worse - now you have to choose which version
to use, which is just proving the OPs point.

~~~
pluma
If you don't like having to choose which version of react-router to choose,
you probably should be using a preset like create-react-app which makes this
kind of decision for you. Or you should use something other than React which
includes everything and the kitchen sink.

~~~
ricardobeat
Exactly! (snark aside)

------
k__
Things you're sacrificing when going away from React:

1\. Stability. FB uses it for their main product, which is probably the
biggest web app of them all, they pay many devs to work fulltime on it. People
coming from Angular, who had to migrate all those breaking changes over the
years know the struggle.

2\. Options like React-Native, React-VR and co. React enables your devs to
acquire a whole new range of possibilities. It isn't just a web framework.

~~~
TekMol

        Options like React-Native
    

When you use React for a web app, how close are you to turn it into a React
Native app?

~~~
chii
the hearsay is that if you used only components that are available for both,
it'd take very little extra boiler plate to get it working on both native and
web. But all non-trivial apps have their own components and that's what makes
native difficult.

~~~
zackify
This really isn't the case. I have built apps with lots of code reuse on
native and web.

Abstract all data logic and you can use the exact same code for both apps.
This of course does not include your view layer. If you do it correctly, all
you have to do is make a new set of view components. Stateless ones. Because
you are injecting the state from your non platform specific components.

It makes it extremely fast to build for other platforms. It just takes a few
apps to fully understand how to abstract these things perfectly.

------
twii
Working with React for almost 3 years now. Came from Angular, Bootstrap,
jQuery, etc.. Done small and very large projects with it. It scales better
than anything I've used before. It's amazingly reliable and robust.

Looking at Vue I cannot think of 1 single benefit I gain by switching. It
doesn't even come close to what React is capable of imao. I really have no
clue why people are pushing this at all.. Are there any examples of large
projects that switched from React to Vue without suffering a loss?

~~~
intellectable
Vue has electrolytes and it is gluten free. Seriously though I think Vue is
the latest shiny example of everything that is wrong with the javascript
community.

Javascripts huge problem is the lack of a standard library or better yet a
standard way of doing anything. To fill that void alone came NPM. With a
million tiny fragmented micro libraries. Then it became a common to start
reinventing the wheel and selling your idea to build up your community by
claiming the trivial syntax changes make it so much easier to use. I like you
have no clue why people are getting so excited about rewriting their apps all
the time.

I think of Vue like attempting to reinvent the calculus of react with a clever
syntax and more simplified form but results in a Riemann approximation.

I think Vue is more frontend focused where react is achieving far more like
react fiber. I do not doubt the power of js community to keep cloning things
into forms they are more familiar with and claim a smaller payload is best
metric of success.

Who would have thought so much open source collaboration would lead to so much
fragmentation?

I wonder what machine learning algos will come up with when they design their
own programming language, because I think programming languages are being held
back by discussing what syntax makes me feel good to type out.

~~~
Double_a_92
The problem is that people assume that old = bad. As soon as one technology is
starting to have a nice big community and enough ressources to be usable, the
hype for something new destroys it.

People could use Angular 2 Years ago just fine, what on earth happened that it
suddenly became so terrible?

Also those are just frontend frameworks! Why is everyone glorifying those???
Is Backend an after thought nowadays? "We got nodeJS... The frontend guy know
JS. He will code something, don't worry."

------
chrislgrigg
I think it's important for any comment or post touting the superiority of Vue
to also provide insight into the author's experience with and feeings about
React. You very rarely hear from devs who were loving React, tried Vue anyway,
and came away believers. This leads me to wonder whether it's not so much that
Vue is "better," it's more that it operates in paradigms that are intuitive to
some individuals and teams in ways that React might not be. I don't see that
as a hit against it or anyone but as a very satisfied React, it does make me
take every glowing Vue writeup with a grain of salt.

~~~
tyrw
They are pretty similar, though one thing this article lightly touches on is
the standalone .vue file, which works absolutely beautifully. JSX feels like a
hack to me, and the ability to write HTML, JS, and CSS _as such_ in a single
file greatly simplifies everything. You can even use different flavors of each
(ES6, Sass, etc) no problem. I would be shocked if this feature doesn't find
it's way into react, angular, and others.

------
elnygren
Vue and React both seem a little too heavy in boilerplate. It's also
interesting that Vue seems to think that mutable state is a good thing (well,
vanilla React does have mutable state too...).

For the boilerplate (and large bundle size!) problem we have
[http://markojs.com](http://markojs.com) that looks very interesting.

However, I think what we really might want is something closer to
ClojureScript's re-frame ([https://github.com/Day8/re-
frame](https://github.com/Day8/re-frame)) and Reagent. However, Clojure and
it's tools aren't really that great for beginners/juniors and/or people with
little experience in FP and lisps.

Maybe in the near future we'll see a little bit more FP style JS solutions pop
up?

~~~
theprotocol
At the risk of sounding like a shill (I bring up Riot a lot), check out
Riot.js. It's a bit rough around the edges in terms of docs/presentation, but
it's by far the most minimalistic and most productive "react-like" ui lib I've
used.

It's all very very expedient and you can pick it up in a day and be churning
out advanced applications with very little mental load. It also supports in-
browser compilation so you can get up and running instantly without having to
set up Webpack/Browserify/Whatever, which is great for testing it out. Later
on you can easily transition to using its offline compiler + whatever packager
you want.

The main downside is the community is small. But it's very close to Vanilla JS
so I've practically never encountered an issue where I needed riot-specific
help.

~~~
elnygren
I've done some work on Riot actually!

If you like them, check out RE:DOM - the author of that one did some work on
Riot too.

RE:DOM might be even more minimalistic and lightweight than Riot.

------
kimjongman
Our company migrated to vue.js, 4 months ago. Our complex app is messy with
JSX, router, and new dev can't keep up with code. Now we start every new app
with Vue.js. The gap between junior dev and senior dev comes closer. They can
collaborate with less bugs, less problems and less time to develop.

~~~
nip
Is it because of the technology or because of the team? Rhetorical question -
I am by no means attacking you or your team, I just clicked on your "is messy
with JSX, router" sentence and decided to put my reply under yours.

I see many people tackling React but not developing in a 'React' way. For
example I recently saw on HN some user complaining that he had to create N
functions to handle N items on a form, while computed properties would have
done the trick with only one.

I have no experience with Vue but extensive with React, having developed both
small and bigger apps and the only real issue for bigger apps was that it was
hard for new users to grok the project initially because of the component-
based approach of React.

I do agree that the learning curve for React is pretty steep, but you reap the
benefits later on as React 'scales' extremely well in my opinion.

~~~
sheeshkebab
router and redux make it messy (or rather lack of standard of routing and
global state management in react makes every one create their own half assed
implementations)...

also transitioning web developers from writing giant HTML pages to thinking
about smaller components is a difficult, without dedicated react designer.

All these make non trivial react apps a graveyard of crappy jsx and messy
untyped tangles of JavaScript code.

~~~
aeriklawson
> also transitioning web developers from writing giant HTML pages to thinking
> about smaller components is a difficult, without dedicated react designer.

Can you elaborate? I naturally gravitate towards separating code into
components in a framework-agnostic sense - React was very intuitive to me and
devs I've talked to seem to feel the same way. Writing huge atomic pieces of
HTML is nothing but a huge headache; it's awful to maintain as it results in
copious amounts of redundancy / tech debt.

~~~
sheeshkebab
perhaps I was being impatient observing a group of web developers and
designers trying to jump into a large React project, practically with no prior
experience in react (although familiar with Angularjs, html, css, js, dom) -
however the fact is that after 3 months of dev, the react codebase turned into
an absolute mess - albeit following best practices around branches, testing,
pull request reviews, continuous delivery to staging environments etc...

The main issues seemed to do with global state management favored by Redux
(hello global variables, I thought we were over you years ago :) ) and
tendency to jam html into react components designed as screens, rather than
components.

------
otto_ortega
I have no doubt VueJS will be the most popular framework in a couple of years,
right now the adoption rate is not as fast as it could be because people have
already invested in React/Angular so switching so soon looks like a downside,
but people just getting started and that have zero investment in any of the 3
frameworks will go for VueJS without a doubt, because is much more easy to
learn and equally or even more powerful.

That was my case, I spent several years sticking to jQuery and waiting for the
wave of "a new JS framework out every x months" was over, and after
researching which framework to learn, VueJS was a clear winner.

The syntax is way more simple and elegant, and as soon as Weex is stable it
will be able to power mobile apps too!

------
jaequery
There is a bit of React kool-aid in here, makes me really wonder if any of
them have actually tried using Vue because the benefits and improvements you
will see with Vue are immediately noticed.

To be frank, the OP actually did a poor job of presenting Vue here because it
only mentioned the similarities, which doesn't do any good for Vue. It did not
get into areas where Vue is better than React, which is what most would be
interested in hearing.

If you ever put React and Vue.js side by side and compare, it is almost a no
brainer to switch. How it handles bindings, the way they got Redux done right,
and the single file component style, are all improvements over React IMO. I'd
jokingly say if React were to keep improving and evolving for the next couple
years, it may possibly look like Vue.js as of today.

~~~
speg
Interesting. I hadn't touched React in months and recently spent a week with
Vue. I had trouble getting up and running and was soon longing for React, or
at least what I remembered of it.

~~~
jaequery
Look up nuxt.js. It is like react starter kit for Vue, comes with SSR and
webpack configured, etc.

~~~
Etheryte
While Vue is awesome, Nuxt is quite horrible. Nuxt's developers have made some
_very_ weird design choices that you can't opt out of if you want to use it.
For example, you have to define your routes by defining a directory
structure[1], which means you have nonsense tree structures, no aliasing, etc.
While they've provided an easy to start SSR solution, the rest of it is simply
bad.

[1] [https://nuxtjs.org/guide/routing/](https://nuxtjs.org/guide/routing/)

------
mpolichette
Do people like Vue because it's more declarative than react? Is it mostly
angular devs switching and getting the best of react but still having
directives?

I like the control react gives me without the black box 'compiler' which seems
like it makes a bunch more choices for you.

I'm probably biased, someone cmv?

~~~
cormacrelf
I hate directives. There is nothing you can do with them you can't do with
just plain callbacks or putting React components inside another that renders
its children. HTML templating directives are stupid too, I find myself looking
up syntax references for angular even though I've used it for ages. (Think
semicolons and magic variables like `$event` or `index` in *ngFor bindings –
you don't need these unfortunate and necessary syntactic choices if you just
use JSX.)

So yeah, Vue is probably slightly more declarative than react, at the usual
cost of having to learn all the declarations. When I first looked at it, I saw
the 'v-' prefix on HTML attributes and just stopped.

~~~
moonforeshot
+1 debugging angular directive was a nightmare... but things might be
different with typescript checking on angular-directives...

(but ironically, react-typescript got props checking faster...)

------
Kiro
The far biggest problem with Vue for me is the template language. Once you've
used JSX you just don't go back to Angular style templates.

~~~
CharlesW
A couple notes:

(1) You can use JSX with Vue. [https://vuejs.org/v2/guide/render-
function.html#JSX](https://vuejs.org/v2/guide/render-function.html#JSX)

(2) By "Angular style templates" do you mean Vue's Single File Components?
Because from my POV they're glorious, and the primary reason I'd be reluctant
to use React instead of Vue.

~~~
p49k
Re #1: for both React and Vue, if you don't stick to the most common and
standard methods for implementing functionality, you're going to cause
yourself a lot of unnecessary pain. Everything around those ecosystems
(documentation, debugging tools, libraries, etc) is designed for streamlining
development for people who don't stray from the mainstream.

------
louisgeo
At our company we built single-page apps using Vuejs. It's very simple to pick
up and easy to merge with existing templates and code (as it looks and feels a
lot like standard HTML).

it takes less than a day for a dev to be up and running with Vuejs, where
React is a bit more tedious to get started with.

------
yunyu
The major problem with this tutorial is that it doesn't cover single file
components ([https://vuejs.org/v2/guide/single-file-
components.html](https://vuejs.org/v2/guide/single-file-components.html)) at
all, which are superior to (and preferred to) implementing string based render
functions (which rely on a runtime template compiler). Indeed, the Vue NPM
package doesn't even provide the runtime template compiler by default. Stuff
like what the article promotes are great for development if you just want to
include a <script> file, but are clunkier than the way that you're actually
supposed to do things.

~~~
deskamess
> The major problem

I did not see it as a problem. I appreciated the light weight approach being
shown first. In fact, for my use case, I prefer not to bring in the ecosystem.
That could change, and the article introduces the heavier approach.

> the way that you're actually supposed to do things

The one message that comes out of the Vue camp and happy users is that Vue can
fit many project types - small to large. Not having to always use single file
components is the pragmatic part of that inclusionary message.

~~~
yunyu
That approach is actually heavier - the template compiler needs to be
distributed (extra 15kb gzipped) and templates need to be rendered at runtime.

~~~
swsieber
I think they meant "lighter integration" \- you need less tooling to get
going. Bad for performance, but good for dipping your toes in.

But that is important to note - it's not the most performance way to do it.

~~~
deskamess
Correct... I was referring to the tooling ecosystem.

------
steve_taylor
I remember a couple of years ago when people were posting about switching from
Angular to React. Now it's React to Vue. I'm going to be honest and concede
that Vue may well be better than React. But having used React productively for
a couple of years now, I don't really see much point in throwing out something
that works well in favour of something else that also works well. Back when it
was "why we switched from Angular to React", it was easy to understand because
Angular 1 is awful. But React isn't awful at all and I don't really see what
I'm going to gain by switching to Vue.

------
TekMol
What are good examples of popular websites (not behind a login) that make use
of Vue or React?

I ask because I keep reading about it, all programmers seem to use it, but I
just don't come across websites that use it. Is it only used for backend
dashboards? Or do all Vue/React sites fail to gain traction for some reason?

~~~
madeofpalk
Mobile Twitter uses React.
[https://mobile.twitter.com/facebook](https://mobile.twitter.com/facebook)

Airbnb uses React
[https://www.airbnb.com.au/rooms/432044](https://www.airbnb.com.au/rooms/432044)

Facebook, Facebook Messenger, Instagram, Netflix, Reddit Mobile, new Reddit
Profile pages are all high profile sites using React that aren't just 'backend
dashboards'.

~~~
TekMol
Interesting. The ones not behind a login (Twitter,AirBnB,Reddit Mobile) are
sites that feel laggy and clunky to me. With slow loading content, loading
animations, laggy scrolling, too much stuff opening in new tabs, confusing
interfaces.

I wonder if React causes/incentivises this or if it's design decisions by the
coders/designers/managers.

In contrast, pages like Reddit Desktop, Google and Amazon work much better for
me.

~~~
patrickaljord
Actually the new Twitter Mobile called Twitter Lite is super fast, did you try
the latest version? It's a full progressive web app that works offline, has
notifications and super fast scrolling. It was designed to work on low end
Android device, give it a try:
[https://mobile.twitter.com](https://mobile.twitter.com)

~~~
TekMol
At first it gives me a white page with a little blue twitter logo. Then the
twitter logo disappears and I see a white page for a second. Then it gives me
a strange blue page with a giant twitter logo and two buttons glued to the
bottom that tell me to log in.

~~~
matt4077
Are you perchance using a RFC6214 network? Because the page is around 600kb
compressed and renders in less than 500ms for me, on an empty cache.

------
fnayr
I'm currently making a mobile f2p game in Unity. I previously had created a
Cocoa app for the game item creation/ db management. Since we changed the
architecture of the game pretty heavily, I needed to rewrite the tool. I chose
Electron + Vue over Cocoa. Despite having very little web dev/JS experience, I
was able to make a fully functioning app in under 3 months that syncs with a
server and has multi user editing. Huge fan of Vue. Haven't had the
pleasure/displeasure of React so can't really compare.

------
fareesh
What is the state of isomorphic / server side rendering for Vue and React? Is
it a straightforward thing to setup?

~~~
CharlesW
I haven't done this with Vue yet, but it looks pretty easy to do both
prerendering and server-side rendering[1].

A more complete solution, Nuxt.js[2], appears to be gaining in popularity as
well.

[1] [https://ssr.vuejs.org/en/](https://ssr.vuejs.org/en/) [2]
[https://nuxtjs.org/guide](https://nuxtjs.org/guide)

------
geordee
I've always felt that React is a constantly churning ecosystem. The patterns
keep changing too fast for me to settle down or catch up. That way Vue.js has
done an amazing job. Sort of reminded me of Rails. Today I'm happy with Vue.js
for my small to medium applications. Keeps things simple and beautiful.

------
danmaz74
> ... If message is passed as a prop to any child components, Vue knows that
> they depend on this will be automatically re-rendered as well. That’s why
> there’s no need for a shouldComponentUpdate method on Vue components.

I think that React does the same? If a component's props and state don't
change, shouldComponentUpdate doesn't get called at all IIRC.
shouldComponentUpdate, instead, is useful when a state or prop _was_ changed,
but it's possible to quickly detect that the change _won 't_ require a DOM
update anyway.

~~~
jefffan241
There's a default shouldComponentUpdate implementation in the React.Component.
It does a shallow compare of state and props. When you define
shouldComponentUpdate you are just overriding that implementation. So it's
always called, its just you don't need to always define it.

~~~
haukur
The shallow check is on React.PureComponent. shouldComponentUpdate just
returns true by default in React.Component components. See here for details:
[https://facebook.github.io/react/docs/react-
api.html#react.p...](https://facebook.github.io/react/docs/react-
api.html#react.purecomponent)

------
nomnombunty
When I switched from Ember to react what I missed the most was the two ways
binding, the computed properties and the router. From dabbling in Vue.js it
seems to have incorporated the best of both worlds. I read over some of the
technical implementation and it seems pretty sane. It seems too good to be
true and I am honestly wondering what is the catch. Everything I have read
about vue has been very positive so far. I am curious what are some of the
cons of using vue

------
grabcocque
It's been eighteen months guys, time to rewrite all our front end code from
scratch!

~~~
a-guest
So true! And now you need to do a re-write with each of the top 250 frameworks
of 2017.
[https://twitter.com/HackerNewsOnion/status/86819780153190809...](https://twitter.com/HackerNewsOnion/status/868197801531908096)

------
forgottenacc57
The things touted as benefits sound like disadvantages.

------
theSpaceOctopus
I'm curious as to why some people refer to Vue as "the new hotness".

I understand the concept but Vue was realeased in February 2014, which seems
pretty ancient in JavaScript years.

Wasn't React released only a year prior? Well, it's been around since 2011 but
it was open sourced in 2013.

Either way, Vue has been around and in use for a little while now.

------
SimeVidas
I dunno. I wouldn’t call React lightweight.

------
moonforeshot
you can use mobx to make react 'vue-like'

------
codazoda
I stopped reading at "both are fast and light weight" because I don't find
react to be "light weight". React is 275K (nearly a quarter of a meg) when it
is minified and gzipped. 750K when it is not minified/gziped.

We're talking about a web page UI here. It should be tiny for users with slow
connections. React seems big to me and I can't justify it except in very large
applications.

As such, I struggle to find the reason React is so popular. Perhaps I'm a bit
old school. People say it's easy to reason about, but I don't find that to be
true in real world large applications with a lot of developers working on
them.

Still, I'm trying to like react, but these things are a struggle for me.

~~~
fonybalony
> React is 275K (nearly a quarter of a meg) when it is minified and gzipped.
> 750K when it is not minified/gziped.

That statement is completely false.

react@15.5.4:

react.min.js is 21335 bytes uncompressed, 7353 bytes gzipped.

~~~
codazoda
I'm including everything you need to deploy in those numbers. You included
only React and not React-Dom. My own try at setting up React results in a 750k
js file when I follow the instructions below. I realize this isn't minified
yet and I welcome feedback on how to make it better.

[https://www.joeldare.com/blog/post/create-a-react-
app/](https://www.joeldare.com/blog/post/create-a-react-app/)

The top search results for react minified size show similar numbers to my
250k. There are a lot of people throwing out a lot of numbers that are
different. Versions likely play a role, especially after 15. Here are some
references.

[https://gist.github.com/Restuta/cda69e50a853aa64912d](https://gist.github.com/Restuta/cda69e50a853aa64912d)

[https://stackoverflow.com/questions/19807946/why-is-
reacts-f...](https://stackoverflow.com/questions/19807946/why-is-reacts-
filesize-so-big-given-its-small-api)

Nothing I can find references a size as small as you mention with react and
react dom. Most recommend writing with ES2016 which probably adds Babel
overhead as well. When I build "Hello World" myself, I can't get anywhere near
the small sizes.

I'd love someone to give me a proper smack-down on this. I want to love React
since it's a recent requirement of my job. But with my current knowledge of
it, I can't seem to get the size down.

~~~
fonybalony
You need to add uglify to your webpack.config.js.

[https://webpack.github.io/docs/list-of-
plugins.html#uglifyjs...](https://webpack.github.io/docs/list-of-
plugins.html#uglifyjsplugin)

------
msmm
Why would anybody do that? Maybe only when you charge by hour it makes sense
because making something more complicated than Todo list is a struggle.

~~~
waibelp
Why?

------
jorgec
I don't get it. Lets say that you have a well formed team, then you have a
designer. A designer is who does the UI but know or care so little about
programming. With React, the UI is practically JSX that very few people know
(in comparison with html) and what we will get instead?, the result is the
same html that it tries to avoid.

~~~
__ddd__
JSX is very close to HTML. Maybe the issue is expecting designers who have
zero dev skills to build front ends in a time of responsive design and rich JS
interfaces. You wouldn't hire a print designer with no Photoshop experience to
design a site, and you shouldn't hire a graphic designer with no web dev
skills to build front ends. If you're team is really well formed, you might
have an experienced graphic designer, a UX expert, and a front end developer
who does the actual building as well as making day-to-day design decisions.
The design/interface experts would work at a higher level of creating an
overarching design language and UX guidelines.

~~~
gustojs
Only in the first world clients pay enough for such a team to make a living.
Not a case for other countries.

