
Ask HN: Benefits of front-end JavaScript frameworks? - cryptography
Serious question: what are some benefits offered by front-end JS frameworks (e.g. React, Vue, etc..) over Django&#x2F;Rails monolith on the backend and vanilla CSS &amp; JS on the front-end? Do they even try to solve the same problem?
======
just_testing
Look, you're kinda confusing things.

For instance, I work in a lot of projects with Django on the backend and
Angular or React on the frontend.

The gist of all that stuff is: REDUCING COMPLEXITY. Tying your hands, so you
can free your mind.

As Django and Rails are a way to better organize stuff on the backend, so are
those frameworks a way to organize stuff on the frontend.

For instance, take React+Redux or Vue+Vuex: you bind all the transformations
on your UI to a single object. All stuff that happens on the UI is a
consequence of a transformation on that object.

So: 1) You just gained undo/redo, if you track alterations on your object. 2)
You know the state of your application at all times, just looking at the
object. You can also keep it and save it for later use.

Now, compare that to something you would do on jQuery. It is a great tool, but
it wasn't built with that complexity in mind. So pretty soon you're dealing
with actions happening in 5 different places. It gets way harder to wrap your
head around it.

~~~
nemild
But just to be clear, it's really a function of what you're building. The
answer isn't simply Angular/React good, jQuery bad. (And I'm sorry if I'm
being too reductionist)

For example, I'm shocked how many simple static sites are built with React. It
makes sense for complex sites, especially with realtime, but it also adds
complexity and maintenance issues. Like all engineering decisions, you have to
be thoughtful about the tradeoffs.

~~~
folkhack
> But just to be clear, it's really a function of what you're building.

110% agree here. Sometimes I just need a simple selector/UI event lib and
don't want to fart around with the verbosity of vanilla JS - so I still pull
jQuery (slimmed) in for a some things these days. It's non-opinionated with
how I use it and it's almost universally understood by JS frontend devs. It's
also very cross-platform friendly.

Now for Angular, React, Vue, etc. Some are less opinionated than others, but I
spend too much time thinking about how to do something elegantly within the
constraints of the framework to "follow suit" with their established best
practices.

ALSO - I've seen FAR too many of these frameworks fall out of favor over the
years: Knockout, Backbone, blah blah. My product lifecycle requires 3-10 years
worth of forward maintenance/support/features and for the last decade jQuery
is/has been the most stable and widely adopted option. (think Debian stable
sorta mentality - I still have 1.* in the wild... on purpose for legacy
browser support)

> For example, I'm shocked how many simple static sites are built with React.

Man - me too. It's like using a pneumatic hammer for a roofing nail. I mean,
it works ... _but why...?_

~~~
nemild
Ha ha, I think we shared the same journey — and realizations.

I wrote some reflections during my last experience:

Chasing the Shiny and New
[https://www.nemil.com/musings/shinyandnew.html](https://www.nemil.com/musings/shinyandnew.html)

------
ufmace
What you're essentially asking about is building single-page style web apps
versus a conventional backend-rendered web site. The question is essentially
whether it makes more sense for your site/app to be rendering independent
pages one at a time on the server, or to run what is essentially a JavaScript
application in the user's browser that communicates to the server via an API
as needed.

As a few example reasons, a JavaScript webapp will be similar to a smartphone
app, running in an independent environment and talking to the server via API,
so if your product is primarily a smartphone app, this may be a good way to
go, as you keep the same APIs and test them well.

If your app is mainly about basic CRUD, showing results from DB queries and
adding rows, it's probably simpler to build a conventional site - it's fast
and easy to do security and data processing on the server, and you don't need
the extra steps of retrieving the data, then rending to JSON or something,
then unpacking it on the client site and then rendering it into some sort of
display.

Anything expected to behave in a highly interactive way is best done as a JS
Webapp - reloading pages from the server will crawl if you're clicking around
a lot.

None of these are hard and fast rules, and it takes a decent amount of
experience with each and knowledge of your business plan to make a good
decision.

------
deadcoder0904
The title of the question says something else & the description says something
else.

Anyways I'll try to answer the title "Benefits of front-end JavaScript
frameworks"

I wanted to know the same question a year ago so I tried making a site in
Vanilla JS. Here is the demo [0] & here is the code [1] & my thoughts when I
wrote it [2].

I tried making the application with Vanilla JavaScript without any frameworks
& it sucked. I had to do routing. I had to maintain state & the code
organization in a single JavaScript file was terrible.

That's why there are frameworks like React/Vue/Angular that help us make it
simple. It handles the client state, routing for you & a lot of complex logic.
Try making the same application I made using Vanilla JS & then try making it
in any framework. It won't require more than a week but you will know why you
require a Framework instead of doing it on your own.

In short, if you're not using a Framework, you're building one.

[0]: [https://deadcoder0904.github.io/AMA-
reader](https://deadcoder0904.github.io/AMA-reader) [1]:
[https://github.com/deadcoder0904/AMA-
reader](https://github.com/deadcoder0904/AMA-reader) [2]:
[https://100dayz.js.org/2016/12/02/AMA-
Reader](https://100dayz.js.org/2016/12/02/AMA-Reader)

------
andrei_says_
Managing complex DOM transformations and avoiding pageloads on every change do
carry benefits.

Some examples: chat, Facebook-like functionality, complex custom interfaces.

There is however a strong tendency to build complex front-end apps because of
the trend to do so. This increased complexity results in higher costs without
significant benefits (I’m very open to changing my mind).

Turbolinks for example is a fantastic backend-agnostic library which
eliminates the pageloads in CRUD apps at close to zero development costs and
makes the speed almost indistinguishable from SPA implementations.

I highly recommend this talk on managing the complexity of basecamp and
sharing a codebase between web and native apps.

[https://m.youtube.com/watch?v=SWEts0rlezA](https://m.youtube.com/watch?v=SWEts0rlezA)

Unless you’re building extremely complex interfaces and if you are able to
correct for trendiness you may conclude that a monolithic app with possibly
Turbolinks and some front end sugar is the best choice.

You can always offload some work to the client once you get to a billion users
and servers become too expensive. Until then maybe focus on launching.

------
jbob2000
Off load view rendering to the client to lower server costs.

Having different teams for front-end and backend so they can work and update
at different paces.

You can update the front end without taking your servers down.

Front-end developers tend to be cheaper than full stack or wholly backend
devs. (And many backend/full stack devs HATE html/css/js). Depending on your
app, you might do way more work on the front end than backend, so it'd be a
waste to hire full stack devs only to make them do all front end work.

Front-end apps can handle spotty internet connections much better, so they
work nicely for websites with a lot of mobile traffic.

User experience tends to be snappier since you aren't always waiting for the
server to render your view.

~~~
nathan_long
> Off load view rendering to the client to lower server costs.

Another way to lower server costs is to change tools. Eg, Phoenix renders HTML
_much_ more efficiently than Rails due to its use of IO lists.

[http://nathanmlong.com/2016/11/elixir-and-io-lists-
part-2-io...](http://nathanmlong.com/2016/11/elixir-and-io-lists-part-2-io-
lists-in-phoenix/)

> User experience tends to be snappier since you aren't always waiting for the
> server to render your view.

The "Turbolinks" approach of only re-rendering the `<body>` also makes things
feel snappy if the server response is fast.

[https://changelog.com/](https://changelog.com/) is a site that uses Phoenix +
Turbolinks to achieve a snappy user experience with very little JS. The source
is at
[https://github.com/thechangelog/changelog.com](https://github.com/thechangelog/changelog.com)

~~~
jbob2000
Oh, interesting! Thanks for sharing. But there still is a _little_ bit of
server load, whereas front-end has 0.

Honestly, unless you're serving billions of pageviews on a very tight budget,
I'm not really sure how much of a savings we're talking about here (server
side vs. client side rendering).

~~~
nathan_long
> But there still is a little bit of server load, whereas front-end has 0.

That's true. OTOH, using a front-end framework has downsides, too. You have
another framework involved, a big pile of JS that must be downloaded, more
build tools, maybe you need to render server-side anyway for first page
load...

> I'm not really sure how much of a savings we're talking about here (server
> side vs. client side rendering)

Yeah, me either. I think "what's the easiest way to get & maintain the desired
user experience?" is probably the best question.

~~~
ccachor
Well, Angular has a very heavy initialization penalty, enough that I know of a
few companies that ditched it for React. I'll also add, as your front-end
becomes more complex and uses a number of different libraries, the bundle
becomes huge. There's ways around this of course, but some of pure JS stuff
can get ugly quick.

------
firasd
In a nutshell, they come in handy when your 'Vanilla JS' involves a lot of
changes to the DOM in response to user interactions or other events, and there
are many such events.

------
veza
What you're asking is advantages of SPAs over classic web apps.

For example you write only one REST API for all clients: iOS, Android, Web.
They can use the same endpoints. Otherwise you need to write separate
controllers/views for web templates, which leads to duplication.

~~~
rhapsodic
> What you're asking is advantages of SPAs over classic web apps.

That's not necessarily true. The OP didn't mention anything about server-side
rendering. It's quite possible to build a SPA with the aforementioned stack.
(Although personally I think jquery offers a lot of benefits over plain JS for
DOM manipulation and event handling.)

------
amerkhalid
I see two benefits of frontend JS frameworks:

1\. They are highly optimized for DOM changes. You can use plain JS or jQuery
to manipulate DOM but that would get expensive.

2\. They provide some semblance Object Oriented code organization to frontend.

For a simple app, these benefits probably are not worth it but for a complex
app, these benefits outweigh the cost of these frameworks.

~~~
rhapsodic
> 1\. They are highly optimized for DOM changes. You can use plain JS or
> jQuery to manipulate DOM but that would get expensive.

I keep seeing this claim, or similar ones, postulated, but in my extensive
experience, using plain JS or JQuery for DOM manipulation has never resulted
in noticeably slow performance, even when there was a great deal of DOM
manipulation going on.

And if that were the case, I am quite confident in my ability to optimize my
own code to make it performant.

~~~
glassbordall
Agreed. Furthermore, OO style programming is simple enough with plain JS.

------
wffurr
Many, possibly most, JS frameworks come out of someone's attempt to refactor
their vanilla JS DOM manipulating spaghetti code. Once your front end reaches
a certain complexity, you end up inventing one of these anyway, so why not use
one that's already mature?

If your front end is fairly simple, then I would stick with vanilla JS.

------
Roboprog
I like the approach of having an SPA on top of a REST service back end in that
you have two code bases that deal with distinctly different problems/goals,
and you focus your attention when working on one side or the other.

When you are working on the back end, you worry about security, data integrity
and speed, focusing on “stateless” actions (other than what is kept in a
database, perhaps).

When you are working on the front end, you worry about looks and ease of use
and maintaining state transitions, with a fallback perhaps of simply reloading
a page + route (w/in page) if things go pear shaped. I guess speed is still an
issue on the front, but caching and request count reduction seems to handle
most of that.

As an added bonus, I like working in an FP style in Javascript more then OOP
style in Java, but that puts me in a minority.

------
ccachor
Front-end frameworks are going to give you a few things: more control over
routing, more "app" like behavior, instant state changes (easily done), and
most of all: your front end isn't going to be DOM driven. Lets say you're
tasked with redesigning an admin area and one really ugly area are forms.
Rather than having the logic and styling bound to classes, that functionality
is bound to a component. So, for large front-end applications the
maintainability can be tremendous. I would say the big 3: maintainability, app
like routing, and instantaneous state changes (across diff portions of your
app) without doing much work.

With Rails 5, you get the benefit of both. You're not doing your backend in
javascript, but it plays nicely with modern front-end libraries and
frameworks.

~~~
folkhack
> most of all: your front end isn't going to be DOM driven

I get this and all - but I also want to make a _strong_ case for letting the
traditional DOM manage application state.

Putting a "component" abstraction between what is being rendered on the front-
end often feels like increasing complexity for perceived developer ergonomics
and future-proofing your application. The only time I agree with this
abstraction is when there is a clear need for insane complexity on the UI -
something I actively try to hedge against during design phases. High UIX
complexity generally means crap user experience/design.

 _Also_ \- I would argue on how many different ways do we need to address a
front-end component + tie data to it..? We've got ID's for singular selection,
classes for group selection, HTML5 elements, name attributes, data attributes,
etc etc. Yes, I understand that this conflates the UI DOM node's functionality
(JS) and styling (CSS) but I've never felt the need to decouple that since
they're both addressing/manipulating the same DOM; Which is what I consider
the canonical state representation of the front-end.

------
WorldMaker
Why not both? It's definitely not an either/or, you might have a beefy
monolith of a backend and a beefy monolith of a frontend working in tandem for
the best possible user experience. It depends on your projects; it depends on
your project's needs; it depends on your user's expectations.

> Do they even try to solve the same problem?

They are different tools for different jobs. If a website wants to be, for
instance, offline capable (such as a PWA suggests), you need to do more work
on the client side. The more work you do on the client side, the more it
likely behooves you to use a framework to help you manage that.

Just as you could write "vanilla" Python or Ruby CGI/WSGI instead of
Django/Rails on the backend, you might want that framework to help you manage
things like routing or template systems or ORM layers or whatever else you
rely on the framework for.

Certainly at face value there's some obvious places of overlap there (hence
the rise of "universal" or "isomorphic" frameworks where a NodeJS server can
do the exact same rendering as a static site as the framework might do client
side "live", sharing a lot of code between them), but that also doesn't mean
its a competition between front-end versus back-end and even with
universal/isomorphic frameworks it turns out the answer really is "both";
there are benefits to doing a lot of work on the server ahead of time _and_
having the client capable of doing all the same work, to share and split the
efforts as needed.

------
ozim
Not the same problem they do different things.

Most important thing for frontend is mvvm or mv* you get from frameworks and
imopsed structure. If you have popup on page where you edit some object in a
list updating that object with jquery is mess. Even better if you have the
same object property diaplayed in multiple places. You just have one backing
model like scope in angular or model in Vue or Knockout. Then DOM or your html
is updated automagically by framework. If you add some custom business rules,
good luck maintaining it in jQuery or plain js. You would need to have
military grade team not usual (as in herding cats) devs.

------
sebazzz
From ASP.NET WebForms / MVC perspective: In my experience, not needing to post
back to the server for changing several fields based on state, and in addition
the complex state management logic that needs to exist on the server (either
in viewstate or manual in MVC) improves the user experience and saves
development time.

While the initial set-up of a page in Knockout/Web API takes relative more
time, further development takes less time than otherwise.

------
buchanaf
Short answer: maintainability, performance, cross-browser consistency,
community plugins, easier developer on-boarding, and framework updates and
maintenance (which amplifies most of the previous).

Obviously a lot depends on the complexity of the website, but for the most
part, any web _application_ will be better served by a framework. Heck, most
static sites can now be amplified by layering on frameworks if done correctly
(ie GatsbyJs).

~~~
dmytrish
> performance – I can see how a SPA may be slower to load initially but use
> fewer data and be more interactive later.

> cross-browser consistency \- do you mean that client-side frameworks are
> usually well-tested in different [versions of] browsers, much more so than
> vanilla javascript?

> community plugins \- do you mean that ecosystems around JS frameworks are
> more developed and powerful than around server-side web-frameworks? Can you
> elaborate why?

I still can't understand the points behind "maintainability", "easier
developer on-boarding" and "framework updates and maintenance" for client-side
frameworks.

~~~
buchanaf
All of that and more.

\- Performance: most major frameworks use a virtual DOM to minimize the number
of repaints. Off the top of my head, Vue has computed properties that cache
calculations and React has aysnc/priority rendering. I imagine there's a good
deal of other stuff.

\- Cross-browser consistency: React has a synthetic event system that
normalizes events between all of the different browsers. There's certainly
less "gotchas" between browsers than there used to be, but its nice relying on
a web framework with a huge testing suite to ensure those "gotchas" are taken
care of.

\- Community plugins: I was more alluding to the number of UI components that
are available for use. Have you ever tried to make an accessible, styled
dropdown menu? How about one with search capabilities or multiple selections?
There's a lot of tricky UI components that have been created by the community
at large that you can just drop into your application without having to spend
a day or two developing and another month or two debugging.

\- Maintainability: front-end frameworks generally come with conventions. They
encourage modular, reusable components. This is much more difficult to achieve
with vanilla, and if it is achieved, you have in essence created your own
"custom" framework.

\- Easier developer ob-boarding: Like I mentioned above -- framework
conventions. In addition, framework documentation and examples by the
community. You can't run through a bunch of tutorials if Joe Schmoo "winged"
the entire front-end code base with vanilla.js.

\- Framework updates: React just released Fiber, a huge update that
dramatically lowered the size of the library, increased the perceived
rendering performance, and added additional APIs. There is a huge group of
open source contributors continuing to perfect that library. That's pretty
sweet.

