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

121–130 of 433 posts

Re: Breaking up with JavaScript front ends

#121

Post by t8sr »

waboremo wrote: post #106
t8sr wrote: post #100

Earlier quoted context omitted.

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…

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 in the list of messages, and because every message is nested literally 15-30 layers deep in a pointless tree of divs.

I am sorry, but web frontend is an insane dumpster fire.

Re: Breaking up with JavaScript front ends

#122

Post by boxed »

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…

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.

Re: Breaking up with JavaScript front ends

#124

Post by arcturus17 »

black3r wrote: post #59
sph wrote: post #29

Needs a (2016) in the title. The situation is even worse now.

Is it really worse now though? As a full-stack developer since 2013 (Django on backend since the start, React on frontend since 2015), I think it's finally getting better in the past couple of years, and I think it was worst between 2016-2019... After years of not knowing what to use because the libraries I've used 2 years ago are no longer maintained or their APIs changed 3 times since then, there's now Next.JS whic…

Does Nextjs make you use Django less? I think my basic process going forward is going to be Nextjs + something like Supabase as default and only add a more complex backend as needed.

Re: Breaking up with JavaScript front ends

#125

Post by TheRealDunkirk »

I don't understand why so many people are dismissing this because the post is from 6 years ago. Looks like the project is still actively maintained, which, after the 3 lifetimes that 6 years represents in development timelines, seems to be a stroke in its favor.

Re: Breaking up with JavaScript front ends

#126

Post by t8sr »

nicoburns wrote: post #113
t8sr wrote: post #100

Earlier quoted context omitted.

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…

Gmail is just poorly written. The old version of Gmail was still an SPA, and it was perfectly quick.

Yeah, I agree - the old version of gmail was perfectly reasonable. But the current version is IMO representative of trends in web dev. Google is both influential and tends to follow the recent trends. Gmail is by no means unique - every web app created in the past few years is the same insane jumble of frameworky js code and a DOM 100 layers deep, just because someone can't be bothered to learn CSS and plain JS.

Re: Breaking up with JavaScript front ends

#127

Post by smaudet »

waboremo wrote: post #106
t8sr wrote: post #100

Earlier quoted context omitted.

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…

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…

If you can limit yourself to exactly one, maybe two external deps, which are really just to make your dev life eaiser, you may have something of a point.

You have to remember that a large chunk of "web apps" means "electron apps" which are absolute bloated pieces of junk next to their desktop cousins.

You also have to remember a 'framework' typically doesn't stand in isolation - tens, hundreds, thousands of dependencies typically lurk.

We all agree tracking junk makes it even worse, but the whole thing is already overcomplicated before you get to that point.

Re: Breaking up with JavaScript front ends

#128

Post by bottlepalm »

skilled wrote: post #34

I think innovation needs to happen in package management. Has it happened yet? Because I don't know for sure, so I am asking because I might have overlooked it. Even projects from a few months ago can be become unusable unless you are willing to sit down and spend a couple of hours fixing the problem. And don't get me started on packages that have been abandoned altogether but are like glue to functional software. (I…

Innovation isn’t going to prevent people from abandoning projects.

You have to make smart decisions when adding dependencies based on how mature and supported is it. This often means sticking with the big names even if the little project has more hype.

Re: Breaking up with JavaScript front ends

#129

Post by dmix »

ostenning wrote: post #120

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…

Any project that changes often is going to break often. When it involves dependencies that are constantly upgrading or being added it doubly adds risk of breakage.

Test coverage and being conservative with adding new dependencies/concepts is always a valuable culture to develop for any frontend team working with junior devs. A good CTO/senior dev can clamp down on this behaviour.

Re: Breaking up with JavaScript front ends

#130

Post by viraptor »

omnimus wrote: post #75
Waterluvian wrote: post #8

Warning: if you want to look at the content of this page, say goodbye to your back button.

This is not a website. It's a presentation made with reveal.js framework. This has been made as slides for a talk. It is very much feature that people accidentally don't back out of their presentation while they are doing it.

You can easily disable it with "history: false" in the reveal config. (As an author unfortunately)
Post reply on HN