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.
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.
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...?
I wrote some reflections during my last experience:
Chasing the Shiny and New https://www.nemil.com/musings/shinyandnew.html
What additional interactivity do you have in mind when you propose a front-end framework?
You can probably do both of those things without a JS front end but I feel it's more common for monoliths to end up in a spot where they _need_ to be broken up rather than having kept everything isolated and clean from the beginning. That's just my experience though, YMMV of course.
In my experience so far, MVC provides a good enough separation of concerns and in the absence of an immediate need for an API, it is more economical to build a monolithic app.
Avoiding building a second application for the front end offers huge savings.
Adding an API is fairly easy (Rails) and Turbolinks offer a great middle ground for native apps.
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.
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 [1]: https://github.com/deadcoder0904/AMA-reader [2]: https://100dayz.js.org/2016/12/02/AMA-Reader
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
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.
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.
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...
> 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/ 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
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).
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.
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.
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.)
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.
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.
If your front end is fairly simple, then I would stick with vanilla JS.
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.
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.
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.
> 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.
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.
While the initial set-up of a page in Knockout/Web API takes relative more time, further development takes less time than otherwise.
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).
> 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.
- 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.