Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Breaking up with JavaScript front ends

triskweline.de

Post reply on HN
Print view View original

281–290 of 433 posts

Re: Breaking up with JavaScript front ends

#281

Post by throwaway0asd »

throwaway999528 wrote: post #216
heather45879 wrote: post #181

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.

That sounds like a training problem more than anything else.

Re: Breaking up with JavaScript front ends

#282

Post by cdogl »

wwweston wrote: post #280
throwaway999528 wrote: post #216

Earlier quoted context omitted.

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.

> 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. So… what’s the difference between this and SPAs using frameworks again? Because it sure seems to me I see many of these in sites that are apparently using frameworks. Hell, Facebook — presumably the poster child for the react ecosystem and certainly with t…

I agree with the sentiment of your post, but:

> Hell, Facebook — presumably the poster child for the react ecosystem and certainly with the resources to do everything right — is still introducing nav-state related bugs.

This doesn't necessarily disprove the framework's value proposition. Bugs like this are hard to squash and at great scale (like Facebook) they're a huge challenge. Frameworks propose trade-offs to manage them, but can't eliminate all classes of bugs. We don't know how much worse it'd be without the framework approach.

Re: Breaking up with JavaScript front ends

#283

Post by EugeneOZ »

hn_throwaway_99 wrote: post #166
mattlondon wrote: post #96

Earlier quoted context omitted.

React is used a lot, but it is certainly not the standard. Angular is still used extensively, especially in enterprise

I'd still argue that React is very much the default for new applications where legacy interop or existing team familiarity isn't a factor. I mean, this is obviously an extreme example, but COBOL is also still used extensively in the enterprise, yes it's still not really used for any new projects.

And you are still wrong. Bigger companies often pick Angular.

Re: Breaking up with JavaScript front ends

#284

Post by hliyan »

recursivedoubts wrote: post #250
boxed wrote: 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.

htmx is focused on hypermedia exchanges in the mode of normal HTML, so client-side stuff is out it does, however, have an extensive event model to hook into, including pre and post request processing: https://htmx.org/reference/#events as well as an extensions API: https://htmx.org/extensions/#defining for client side scripting, I think you are talking about hyperscript, which is definitely more speculative than htmx…

Just checked alpine.js. While it's very nice, was a bit worried about this potentially risky eval use:

Re: Breaking up with JavaScript front ends

#286

Post by [deleted] »

heather45879 wrote: post #277
throwaway999528 wrote: post #216

Earlier quoted context omitted.

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 underlying issue with web applications is that it’s like a square peg going in a round hole. Remember, HTTP is designed traditionally as a stateless protocol delivering static web pages, more or less. But here we are, with stacks-on-stacks-on-stacks of layers emulating what truly should be a native application. “Web Application” should not be a thing. HTML/CSS were supposed to be for content and presentation; Jav…

[deleted]

Re: Breaking up with JavaScript front ends

#287

Post by DHPersonal »

t8sr wrote: post #121
waboremo wrote: post #106

Earlier quoted context omitted.

Tools like htmx aren't the reason the gmail tab uses a GB of memory. You'll find the majority of cases where pages are using way more resources than it should, are due to reasons forced on web developers, like a billion different trackers and several different ad networks, and workarounds to ad blocking to sell more subscriptions, etc. This is what is so shocking to me when HN spends such an absurd amount of time ral…

According to my browser, the default view in gmail needs 8.32 MiB of javascript spread over 90 files to render. While IDLE, the gmail tab uses 10-30% of an M1 CPU core. That stuff is not down to tracking - it's because the damn thing keeps messing with the DOM, because it has some insane structure where javascript controllers are attached as strings to DOM elements, because it uses about 100 divs to render every row…

I keep saying the same thing at work on the NextJS / MaterialUI project I’m working on and I largely get blank stares in response.

Re: Breaking up with JavaScript front ends

#288

Post by Tade0 »

t8sr wrote: post #100
qrohlf wrote: post #11

Seems like a half-baked agency-built version of htmx[1], no? I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, but IMO when you need more than statically rendered pages, it should look a lot more like htmx or Phoenix LiveView (if you're using a framework) or something ultra-minimal like Slimvoice[2] if you want to go the bespoke ro…

Alternatively, web developers could calm down and just write mostly HTML with some plain javascript where warranted. I've recently done some web development for the first time in 12 years, and I was horrified at all these pointless frameworks that break every usability win web browsers have made in the past 20 years, cost extra bandwidth and have atrocious performance. Like, why? Can web devs really not learn the 4 f…

> This kinda crap is why the gmail tab uses a GB of memory.

Actually no, and the real reason is organisational.

It has been a pattern for years now for front-end projects to consist of multiple, independent modules developed by separate teams - banking apps are a prime example of this.

Gmail appears to have went the same route, because it now sends over 200 requests when loading - a hallmark of a highly modularized front-end.

The organisational benefit is less knowledge required per developer, which in turn brings other advantages like resistance to turnover.

Re: Breaking up with JavaScript front ends

#289

Post by jonahx »

proc0 wrote: post #269
jonahx wrote: post #259

Earlier quoted context omitted.

> 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.

That's not what the trend shows. Apps have added more interactivity like live chats, conferencing calls, more editing options (i.e. editing videos when uploading to YouTube), and this is probably going to keep going adding things like voice commands, customizable layouts, and more realtime information being displayed at any given time. The reason it converges with video games, is because both are clients and both pro…

There is jump going from "I see this happening" to "this is what user's want." For example, the trend is also towards massive tracking, more ads, and heavier and heavier pages. Users don't want these things, but business forces create them.

I think this is probably true of many (not all) of the kinds of things you are calling "interactivity". In any case, the reasoning isn't sound, even if you think your conclusion is.

Re: Breaking up with JavaScript front ends

#290

Post by vbezhenar »

throwaway999528 wrote: post #216
heather45879 wrote: post #181

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.

I agree. I like pure JS, but it just does not scale by default. You need to have awesome architecture skills and you need to constantly observe your codebase, you need to write half of framework if you want to avoid frameworks. Of course it's possible, but it's not possible for vast majority of developers, including myself.

May be we need some education: how to write 100 kLoC pureJS WebApp and keep sanity. I didn't see that kind of articles. I know that my pureJS web apps can survive few hundreds LoC. Then it becomes a mess. With React it's much easier to structure an app so it's maintainable, different parts are separated, etc.

Post reply on HN