Live data from Hacker News

Breaking up with JavaScript front ends

triskweline.de

251–260 of 433 posts

Re: Breaking up with JavaScript front ends

#251

The biggest problem facing the front-end space today isn't so much of complexity of a particular library, rendering technique, or view/model architecture, but rather lots of bad ideas glued together, creating nightmare scenarios for companies trying to maintain products. A micro dependency system with never ending breaking changes to glue different tools and libraries together - bad idea. Using un-opinionated "librar…

I like to go back to the basics. It irks me that folks don’t think HTML/CSS/JavaScript are good enough as-is—but nowadays the default browser capabilities are incredible compared to a decade ago. We basically have a full programming environment and add WASM to the mix! Back in the day the frameworks were first-and-foremost a platform compatibility solution. People often have it ingrained in their psyche that reinvent…

In a modern web framework you still have HTML and you still have CSS files.

The problem is JavaScript and in particular the way that you interact with the DOM: browsers use an imperative API, that this day is obsolete, and makes writing web applications a mess rapidly, and produce spaghetti code difficult to modify and isolate.

While practically all modern frameworks use a functional approach: you have the component, that has an internal state, a function to render DOM elements from that state, and if you need to update the view you don't directly manipulate the DOM elements, but update the component state, that causes the framework to call again the render function that updates the DOM elements as required. That is so much simpler, because you don't have to ensure that the state of the application is aligned with the state of what the user sees on the screen!

Re: Breaking up with JavaScript front ends

#252

Earlier quoted context omitted.

SPAs solved a labor problem I think. It was the reason that front end development grew so fast. It is much faster to train people on a combo js+css framework rather than training someone on backend languages, databases, queues, authentication, scaling + html & css for server side rendering.

Or maybe people don't like waiting for a page to load each time they click a button?

People want responsive interfaces, absolutely. Whether the interface is implemented as full page requests to servers or AJAX requests is irrelevant to users.

Bare AJAX itself almost always will perform better than a full page request, but as you layer on additional requirements, frameworks, libraries, etc. that isn't always true.

I think old reddit and new reddit are a great example of this - both are processing the same data and presenting a very similar UX. But at least for me, the relatively javascript light old reddit interface with full page reloads feels much more responsive and usable than the new site.

Re: Breaking up with JavaScript front ends

#253

Earlier quoted context omitted.

I like to go back to the basics. It irks me that folks don’t think HTML/CSS/JavaScript are good enough as-is—but nowadays the default browser capabilities are incredible compared to a decade ago. We basically have a full programming environment and add WASM to the mix! Back in the day the frameworks were first-and-foremost a platform compatibility solution. People often have it ingrained in their psyche that reinvent…

Throwaway for anonymity. I work at a place that is mostly like this, I can tell you that using html/css/javascript raw, with a bit of bootstrap is a nightmare with a SPA. Menus are constantly broken, back button is a game of roulette, caching is constantly a problem showing stale data, xss and other vulnerabilities are ubiquitous. There are modern affordances in many of these frameworks others take for granted.

As someone trying to create a frontend with plain HTML/CSS for quite a complex backend, I can attest to the fact that's impossible to maintain consistency between browsers.

It's not even about how each block's styling behaves, but how different combinations of tags, blocks and widgets are able to exhibit very specific issues in each one of the 3 main rendering engines around. In very different ways, that require incompatible solutions.

It's quite egregious.

Re: Breaking up with JavaScript front ends

#254
post #122

Earlier quoted context omitted.

I've tried to use htmx exactly two times. Both times it just ran directly into a brick wall, because it's so limited and has no escape hatch where you can put your own logic. Their solution to this is their half baked new language, which isn't ready, a new language, and seems very much unclear. All they needed was proper hook points.

In my opinion Unpoly does this in a very nice way, with what they call “compilers”.

I think htmx can do the same with built-in events---just not built-in. In fact you may even skip that one today because custom elements are wildly supported since 2020.

Re: Breaking up with JavaScript front ends

#255

Earlier quoted context omitted.

I like to go back to the basics. It irks me that folks don’t think HTML/CSS/JavaScript are good enough as-is—but nowadays the default browser capabilities are incredible compared to a decade ago. We basically have a full programming environment and add WASM to the mix! Back in the day the frameworks were first-and-foremost a platform compatibility solution. People often have it ingrained in their psyche that reinvent…

In a modern web framework you still have HTML and you still have CSS files. The problem is JavaScript and in particular the way that you interact with the DOM: browsers use an imperative API, that this day is obsolete, and makes writing web applications a mess rapidly, and produce spaghetti code difficult to modify and isolate. While practically all modern frameworks use a functional approach: you have the component,…

I definitely see the elegance of the modern reactive approach, but in practice I'm not sure how much better it really is. I still see spaghetti code, and I still see stupid bugs in production. Doesn't seem to matter whether it's JQuery or Vue. Right now I'd bet that careful architecture and thorough testing are still #1 for making good software.

Re: Breaking up with JavaScript front ends

#256

Probably worth mentioning that the submitted link is just the presentation by the author of Unpoly, with some history and reasoning, but the better explanation of Unpoly itself is on their website: https://unpoly.com/ Essays on HTMX website also help a lot: https://htmx.org/essays/

I didn't even realise it was a presentation until this comment. I was clicking stuff and scrolling trying to see content.

Re: Breaking up with JavaScript front ends

#257
Clients are getting more interactive over time. People want more interactivity, not less. Interactivity increases with visual complexity, which in turn requires increasingly complex code. UIs are evolving in the direction of more realtime updates, more animations, more menus and options, etc., etc.

It's no coincidence the most popular frameworks are analogous to video game game engines. They both listen to user input, calculate the input against the state, and then render the results to the screen. It's also no surprise UIs are moving in the direction of becoming "gamified" (actual term), and adding elements that guide the user/player's attention. What this means is that we can expect UIs to increase in complexity until they match game engines, at least in terms of how it models interactivity. I should add, there will always be the static, simple pages, but web apps which are currently considered complicated will certainly keep evolving by providing a more immersive experience.

Re: Breaking up with JavaScript front ends

#259
post #257

Clients are getting more interactive over time. People want more interactivity, not less. Interactivity increases with visual complexity, which in turn requires increasingly complex code. UIs are evolving in the direction of more realtime updates, more animations, more menus and options, etc., etc. It's no coincidence the most popular frameworks are analogous to video game game engines. They both listen to user input…

> People want more interactivity, not less.

Nobody cares about "interactivity" or "immersive" experiences except the devs who make them. People want to get their shit done as quickly as possible using software that feels simple and works as they expect the first time.

A SPA might be the best way to achieve that. But often it isn't.

Re: Breaking up with JavaScript front ends

#260

Earlier quoted context omitted.

I like to go back to the basics. It irks me that folks don’t think HTML/CSS/JavaScript are good enough as-is—but nowadays the default browser capabilities are incredible compared to a decade ago. We basically have a full programming environment and add WASM to the mix! Back in the day the frameworks were first-and-foremost a platform compatibility solution. People often have it ingrained in their psyche that reinvent…

Throwaway for anonymity. I work at a place that is mostly like this, I can tell you that using html/css/javascript raw, with a bit of bootstrap is a nightmare with a SPA. Menus are constantly broken, back button is a game of roulette, caching is constantly a problem showing stale data, xss and other vulnerabilities are ubiquitous. There are modern affordances in many of these frameworks others take for granted.

The problem was choosing an SPA
Post reply on HN