
Why so many front end developers obsessed with React/Angluar? - nogenhat
I really care about a simple question,
why most of frontend developers, which one i know, obsessed with new frameworks.
In fact React &#x2F; Angular &#x2F; Backbone &#x2F; Knockout are born and die again in a couple of years.
Everyone can see some interesting things (virtual dom (simply wonderful!)),
and begin to write &#x2F; rewrite their applications using the new framework.<p>At the same time, most of the projects, which you can see
would be just fine by simply using server-side rendering and for example PostCSS.<p>The development would be simpler, code usually much simple and without MBs of JS libraries.<p>And, important for business, time to market, hiring of developers i suppose would move faster.<p>I understand that this is all very interesting things, good to be in trend and understand whats going on,
but to be aware of technology and immediately implement it in production system...hm, not so sure about this.<p>Now I look at ClojureScript as an acceptable replacement for JS development,
because after release of ES6, and reading ES7 specs, there is a feeling that the direction in which the ecosystem moving is wrong one.<p>So, the frontend world is changing a lot quickly and in different directions, 
but which one is right one, i have a serious doubts.
======
jarcane
I do not work directly with React.

I do however, work in ClojureScript, using Reagent, which is an opinionated
binding to React with a special emphasis on functional reactive programming.

I discovered the FRP approach through Hoplon, and then soon moved to Reagent,
and I must say that it was an absolute godsend.

It is the first real alternative paradigm to interface development in years,
and the first one that actually interfaces well with functional programming at
the most basic level.

FRP allows you to write an interface in a declarative, functional style that
is easy to follow, and largely easy to predict. State is kept to a minimum,
and can be organized and localized in sane ways. View updating is basically
automated, left to the underlying mechanisms of the virtual DOM.

With CLJS' Hiccup syntax, even defining and passing HTML values becomes
painless.

Discovering FRP was basically the same light bulb moment for me as a
programmer that discovering Lisp and FP themselves were. I only wish I could
find a framework for developing desktop applications that was as easy to learn
and use.

------
CuriouslyC
Angular was nice because two way data binding greatly simplified a lot of
user-interface management code, and dependency injection made it easier to
cleanly factor your code. Unfortunately, the boilerplate involved in creating
directives tends to result in monolithic html templates that do way too much
(and are hard to maintain), and the digest cycle/dirty checking ends up
causing a lot of issues when things get complicated.

React makes it easy to create small components, encouraging maintainable,
reusable software. On the flip side, passing data around in your application
is a lot of work, and even the best current solution (unidirectional data flow
with something like Redux) is very oblique and involves significant
boilerplate.

In my opinion the React/Redux model is pretty good, and the libraries are well
designed, there is just a need for a good framework to deal with the
indirection involved in unidirectional state flow. I'm currently working on
something in this space, it just needs some additional battle-testing so I can
settle on the interface and work out all the kinks.

------
plugnburn
Speaking of React/Angular - they are obsessed because they never used
10-years-old computers and slow Internet connection and don't actually know
how users feel when their weak machines are thrown all that stuff at.

I'm not against new _concepts_. Client-side rendering is awesome, reactivity
is awesome. But I'm against all that _bloatware_. If a new concept can't be
implemented without bloatware (hint: it can), we don't really need it.

But these things _can_ and _should_ be done in a different way. For example,
all my JS stack (Z5 + DaBi) targets ES5 and is under 4 KB altogether. Yet it
provides:

\- DOM manipulation and auto-polyfilling some DOM essentials (only for the
stuff that's _really_ uncomfortable to do with native APIs - Q.js);

\- reactive in-memory storage (with an ability to easily populate from
external objects or remote requests - Zen.js);

\- easy data-to-DOM and DOM-to-data binding (DaBi library);

\- ability to easily build DOM and CSS styles from JS native constructs (XT.js
and XS.js - never go through escaping hell again);

\- client-side routing (R.js).

And while I agree that React/Angular are the bloatware (even jQuery is), I
disagree that server-side rendering is any better and that throwing in another
bloatware like ClojureScript would solve this issue. Like I had said in my
article about client-side development
([http://clientside.surge.sh/](http://clientside.surge.sh/)), go native or go
home.

------
arms
There are a bunch of factors in play here, but I'd guess that the reasons are
mainly two-fold: a) developers like shiny new things (myself included) and b)
Angular and React offer opinions on how to build front-end apps, which can be
very hard.

Angular and Ember never quite did it for me. I don't agree with all the design
decisions they've made. I do however enjoy using React a lot. It fits my
mental model much better when it comes to building front-end apps. It's simple
to learn, focuses on building modular components and I really like how it
manages state (either via components or Flux/Redux.) That said, it's not
something I use for every project. But I had something that just wouldn't work
as a traditional server-side rendered project and React was a godsend.

I'm hopeful that ClojureScript continues to gain traction and improved
tooling. I really like the language, and feel that it offers enough to replace
JS for most of my needs. I've played with Reagent and _really_ liked what I
saw there.

------
rpedela
For me, using React makes it possible to write UI code like I am writing UI
code for the desktop (e.g. .NET). When I first saw it my reaction was
"Finally! I can stop pulling my hair out!". And the more I use it, the more I
like it. I am working on a highly dynamic UI right now that I started building
with Knockout, got pissed off, tried React, and haven't looked back.

React really is different than everything else that has come before. I don't
know if React will be the final, new framework most developers use. But
whatever is the final framework will almost certainly borrow many of React's
ideas.

------
AznHisoka
I totally agree with you. I'd love to see more technical expertise/resources
into improving backend technologies like ElasticSearch/Lucene, Redis, etc.

There's only so many incremental improvements to front-end development left.

------
sedeki
Angular is over-engineered and I doubt what they are doing is the right way to
go. React, on the other hand, simplifies the stack a lot actually.

I don't think we will seriously find a consensus until we get WebAssembly.

~~~
speg
Is WebAssembly going to solve anything though? Most of what I've read about it
is that it will be an accessory to JavaScript. Things like databases, video
encoding, 3D rendering, etc.. Will we really be interfacing with the DOM APIs
in C?

Even if that is how it plays out, we'll still have a dozen frameworks to
decided between, at least one for every language that targets WebAssembly.

~~~
sargas
Agreed. WebAssembly won't make the JS framework landspace stop from changing.
But it maybe he meant to say that with WebAssembly, other languages will be
able to be used in the browser, so maybe JS will see less rapid changes.

------
jonesb6
Is code valuable because of conciseness, clarity, and speed, or because it can
provide business value that can be monetized? The prevalence of Angular and
React would suggest it does indeed provide the latter and that the latter is
more valuable to many companies.

~~~
nogenhat
IMHO there is always a balance of power, in abstract world the code by itself
without business or academical value have no sense.

Asking to your topic: >conciseness, clarity, and speed.

Clarity, conciseness and simplicity is matter. I mean it all that matter in
the code, but in our world, in normal one, there not all topic. Sometime is
good to agree with bad architecture decision or with lack of clarity of code,
cause there is importance to release a feature, cause that sales person
deponds on you, you need to make a revenue, etc.

but, what i tried to say, but cause thats my english is not native language,
is not the same thing.

I was thinking that most of frontend world current steps is completely wrong,
its brings only: complexity, unmaintable piech of crap. that you need to know
100s libraries like left-pad, and that you need to follow last trends not in
technology but in frameworks, instead of doing some great UI/UX experience
fast and easy maintainable one.

~~~
jonesb6
Like most things the answer isn't one or the other. The answer is a compromise
based on the situation at hand.

Sometimes Angular (or any other SPA framework) is the right choice, sometimes
it is not.

And if it means anything, I agree with you. I think the internet could use
less SPAs. Developers aren't some super evolved subset of humanity, we get
seduced by shiny new toys (in the form of libraries, frameworks, etc) just
like anybody else.

