Hacker News Reader

Comment by lsalvatore | Hacker News Reader

There is no "pain" managing large React / Redux applications for experienced frontend software engineers. If you don't want to write JavaScript, you probably shouldn't be building interactive applications for the web.

The Browser manages HTML, CSS and JavaScript and provides Developer Tools to debug and manage these languages. When you build with a javascript framework, you package a user experience that is entirely run by the browser, only to dispatch and save to the server when necessary.

I doubt there is a future for "backend SPA" frameworks- no one will take seriously the idea of, instead of two REST calls to get and put data, every client must connect through a socket to manage user input. Surely that will dramatically increase server bandwidth, and ignite the same type of "bloat" arguments that SPA critics use.

View on HN

> If you don't want to write JavaScript, you probably shouldn't be building interactive applications for the web.

Wow, thanks! I've been writing production apps in Vue and React for large companies for years now, but good to know I can stop. /s

I have nothing against JS; I have problems with complexity on teams of varying skill levels and tenure. If you're a JS shop, it's great. But if you're an agency of Rails developers building CRUD apps for B2B, you shouldn't feel forced to write a bunch of JS just to get some values updating on the frontend in realtime.

You don't need to write a bunch of JS, that's why JavaScript frameworks like React exist to make this easy. JavaScript is the only client-side scripting language on the browser that you can use to manipulate the DOM. If you want to locally CRUD without making a round trip to the server- you have two options- manual DOM manipulation, or use a JavaScript framework. That idea that HTML streaming will replace JS frameworks and REST APIs, and is easier and less problematic than a JS framework, is preposterous to me.

Who said that JavaScript frameworks and REST APIs are going to be replaced?

I've noticed that many people who enjoy developing SPAs believe that SPAs are the only way that web apps should be developed, and when anyone suggests otherwise, they get very defensive. Pretty weird.

> Surely that will dramatically increase server bandwidth

LiveView can actually decrease B/W and load, because the HTML diffs are more efficient than sending JSON, and the statefulness means you don't need to constantly refetch user information from DB/cache, etc. The details depend on your app and how carefully you optimize it, but it's far from being an unconditional "dramatic increase".

> If you don't want to write JavaScript, you probably shouldn't be building interactive applications for the web.

That's gatekeeping and just plain insulting.

JavaScript is the only language browsers will run. It's not gatekeeping to suggest that you have to learn and use JavaScript frameworks if you want to build web applications- it's a fact.

You can write full-blown SPAs in ClojureScript or Elm, or use the tools we're discussing here like LiveView.

I've had great success with an LV app with minimal JS. The rendering is all server-side in Elixir, plus a few lines of JS hooks for the bits that truly need to happen on the client for a good experience: TZ conversion, countdown timer, table sorting, Chart.js rendering. No framework needed.

The user doesn't notice if a transition takes 100ms because LiveView is fetching an HTML diff from the backend, or 100ms because React is doing an AJAX query to a JSON API, it's the same end result.

This is the problem

>for experienced frontend software engineers

web development skill varies wildly. Much more so than in any other branch of software development.

btw, "backend SPA"? That web world has officially jumped the shark. "page" has no meaning outside of a web browser. backend single string application makes more sense than backend single page application.

I agree with you.

My only, personal, issue with front-end is typescript - I don't enjoy it for some reason.

Reply on news.ycombinator.com