Is it time to ditch Svelte, React and VUE?

Abstract: For front-end developers, the problem that is often hesitant is how to choose a front-end framework. By using JS libraries, development efficiency can be greatly improved, but the author of this article believes that in some scenarios, JS libraries do not bring Multiply the result with half the effort, but get twice the result with half the effort!

Original link: https://ift.tt/g2obqYE

Disclaimer: This article is translated by CSDN, and reprinting is prohibited without authorization.

Author | Sean Schertell

Translator | Meniscus

Produced | CSDN (ID: CSDNnews)

Today, almost all modern web applications are built using some large JavaScript library on the front end, replacing the entire browser viewport with a JS-rendered virtual DOM, and consuming JSON through REST APIs that need to be built separately, but Tightly coupled to the front end.

If you’re building a Single Page Application (SPA) like Figma or Trello, utilizing one of these tools can save you a lot of time and money. However, if you are building a Multi Page Application (MPA), such as a common e-commerce website, or even an application like email, then I tell you clearly, the complexity of using a SPA framework Sex is far more than its own worth.

Problems with SPA Architecture

Treating the server only as a channel for calling APIs means that we can no longer rely on it to maintain the state of the application. So we moved all state management to the client, and with that we invented whole new frameworks like Redux and MobX. Since we can no longer use the server for basic routing, libraries like React Router and Page.js were created to emulate the routing functionality that was previously available for free.

Previously, it was very easy to implement authentication on server-side sessions. However, in SPA architectures, where we usually need to use JSON Web Tokens, this implementation is significantly more difficult (and bug-prone). Even the most basic form submission can no longer rely on the browser’s standard HTML implementation to submit form fields based on their name attribute. Now we need to bind these values ​​to a JS object and manage and submit that object “manually”.

In other words, these features that we used to get for free now require a lot of effort, is it worth it?

Why is there the current situation?

In the past, web development was simple. The browser sends an HTTP request, the server sends a new document, and the browser renders it to the viewport, replacing all previous content. However, this method is a bit clunky. This means that even if you only want to update a small part of the page, the entire page must be re-rendered.

Later, JQuery came along, which could utilize AJAX to update only part of the page without refreshing the entire page. Web applications so constructed are more interactive and responsive, more like “applications”. But JQuery involves a lot of imperative JavaScript, and it is very difficult to maintain. If you want to build some complex functionality, it doesn’t take long for the codebase to become tangled and unmaintainable.

Then came Angular, followed by React, and these frameworks took a whole new approach that forced us to rethink the concept of “front-end”: the front-end was not just a DOM rendered by JavaScript, but a JavaScript application, which eventually renders a DOM. This works well if you want to build a single page application. While you can’t use HTML’s basic client/server architecture, you’re free to build an app-like front-end experience. This new approach was so exciting that it wasn’t long before every new project seemed to be adopting SPAs.

User expectations for modern responsive websites have also increased dramatically over the past 5-10 years. As a result, people are no longer content to build “Web 1.0” style applications that require entire pages to be reloaded.

Modern UI without SPA

So how can we build a modern MPA website without using a SPA front-end/REST back-end architecture, without writing lots of clunky JQuery, and without having to refresh the entire page on every mouse click?

There is a collection of libraries dedicated to providing modern interactivity while still being able to use the basic functionality of HTML and HTTP, both of which start with “HT” meaning Hypertext. The key lies here. The Web is designed to transmit hypertext, not JSON, to and from the web. Libraries like Hotwire, HTMX, and Unpoly allow you to declaratively replace blocks of DOM by adding HTML attributes or tags to your markup, without having to write any JavaScript yourself. For example, the button “Add to cart” could send a request to the server that modifies the server-side state of the cart items in the server-side session, and then sends back two DOM blocks, replacing the cart-sidebar and # on the page cart-icon-badge. This implementation can be very elegant, and it also uses nice CSS animations.

If we send HTML as originally designed by Tim Berners-Lee (inventor of the World Wide Web), we end up with a lot of useless data. The DOM of client state management is the state of the client. Client router? Isn’t this a joke? JSON Web Tokens? Server sessions are authenticated and easier to implement. Our database queries are also easier because all routes are written on the server side, so the database can be accessed securely and directly.

I wrote a simple ExpressJS based framework to implement this architectural style, you can try it out: https://www.sanejs.dev.

Will Ruby on Rails shine in 2022?

Like most modern web developers, I’ve been avoiding Ruby on Rails for a long time because the framework was designed to build huge monolithic web applications, which is outdated. The problem is that if the front end uses a framework like Hotwire or HTMX, the back end can use any framework. Since we’re dealing with HTML elements, the backend can ideally choose the framework that works best for creating server-rendered templates. But we don’t have that many full-featured, easy-to-use frameworks. Today’s mainstream frameworks are Rails, Django, and Laravel. There are also some upcoming frameworks such as Elixer-based Phoenix and Go-based Buffalo. But Rails has a large, mature community that, honestly, has helped us a lot.

But the point is that the latest release of Rails 7.0 last December includes Hotwire, a front-end interaction library. Hotwire can be used with Rails or by itself, but it’s designed to work well with Rails development and comes by default. Believe it or not, in 2022 Rails is still the perfect full stack framework for building post-Jamstack MPA web applications with modern interactivity that controls basic HTML elements, we don’t need to resort to JS Framework, build a front-end application plus a back-end API.

Summarize

If our ultimate goal is to build a modern MPA website in a fast, organized, and maintainable manner, then we should seriously consider whether the SPA/Jamstack architecture is really suitable for the job. With the advent of modern DOM interaction libraries such as Hotwire, HTMX and Unpoly, we finally have a true SPA alternative that allows us to create modern, elegant interfaces that allow us to control basic HTML elements without having to reinvent the app Basic wheels for program state management and form submission. So, if we want to go back to server-rendered templates, it might be time to look again at the reigning champion of web frameworks: Ruby on Rails. Especially with the new 7.0 version with Hotwire built in, Rails may be the best solution for building modern multi-page apps in 2022.

The text and pictures in this article are from CSDN