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

181–190 of 433 posts

Re: Breaking up with JavaScript front ends

#181

Post by heather45879 »

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…

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 reinventing the wheel is evil, but it’s not—we do it all the time when we write paragraphs.

It’s of course tempting to grab a library but there’s a learning curve and an often hidden long-term cost with using libraries.

Re: Breaking up with JavaScript front ends

#182

Post by trollied »

t8sr wrote: post #104
qrohlf wrote: post #19

Earlier quoted context omitted.

I both agree and disagree with this take. I started out hand-coding static html pages, graduated to Drupal and Wordpress php stuff circa 2009 (glad that's over!), then worked on a largely server-rendered Rails SAAS in the APM space that I guarantee you've interacted with if you've been in the web game for more than a couple years. These days, I may sling React for my 9-5 but a lot of my personal projects and internal…

> However, it's also true that the baseline expectation for web experiences is a lot higher in 2022 than it was in 2009 in terms of the level of responsiveness, interactivity, and overall "app-like-ness", to the point where I think that even with the massive improvements in bandwidth, latency, and web protocols... What? The exact opposite is true: the average web app (including ones like gmail) is far less responsive…

Agree 100%. Also makes me laugh when people talk about server side rendering. Serving a html page isn’t rendering. The fact that a couple of megabytes of JavaScript ever became responsible for making the simplest of pages even display is possibly the worst technology regression I’ve ever seen.

Re: Breaking up with JavaScript front ends

#183

Post by wruza »

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 haven’t tested the following claim and not at the computer atm (^U, see below), but divs must be cheap. They’re just structures which a rendering engine walks through and computes hierarchical offsets of via stylesheets.

I’m not arguing for using hundreds of divs, because that’s a sign of engineering insanity imo, but it’s not a performance issue. You can create a static page with thousands of them and (likely) see that it still doesn’t use 250Mb+ neither idles at 30% cpu core.

Added:

damn thing keeps messing with the DOM … web frontend is an insane dumpster fire.

Totally agree with these parts.

—————

… I just tested 50 div-rows with 200 spans containing numbers from 1 to 199. Total 10k elements, text doesn’t fit on the screen. Bootstrap css+js is imported via CDN.

Mithril.js implementation uses 50Mb of RAM consistently.

A static page with the exact same content uses 71-96Mb depending on the run.

Both use 5-14% cpu when I shake my mouse and 0% when I don’t.

Refresh is significantly faster with Mithril, idk why, probably because static html parser is slow. (Opera, Windows 10, no extensions).

With a single span per row instead of 200 both take 23Mb.

Removing bootstrap from the head inconsistently frees 0-2Mb for both.

Re: Breaking up with JavaScript front ends

#184

Post by taeric »

nicoburns wrote: post #134
t8sr wrote: post #126

Earlier quoted context omitted.

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.

Google's frontend engineering tends to be pretty poor and out of step with wider industry practice in my experience. They have created not one, but 3 of their own frameworks (Angular, Angular 2 and Polymer), two of which (Angular and Polymer) were rather poorly performing, and the third of which is kinda ok but doesn't seem to be that widely used internally. They tried to create their own frontend language (Dart), wh…

You didn't even mention GWT. I don't know what is causing it, but yeah, Google has dropped some turds over the years.

Re: Breaking up with JavaScript front ends

#185

Post by tmd83 »

The one reluctant use I see of JS based UI (does anyone have an alternative solution?) is to reuse API. Right now we have two code path one where a user action renders the html server side and returns it another where an API call for similar work returns a JSON. A JS UI page can consume the JSON and can render the page reusing the core API.

What's the solution to such a use case?

Re: Breaking up with JavaScript front ends

#186

Post by bluewalt »

holysantamaria wrote: post #149

I still don't consider myself a veteran but I saw the web evolves from 2010 up til now. And imho we took a wrong direction. Web apps and pages have become so bloated and complex that's crazy. I'm just starting to recover from my previous work. I had to maintain migrate and add features to a legacy system (built in 2017) which had initially a GraphQL api and a SPA, but that was later split in 12 microservices (with cy…

I'm gonna screenshot this and show it to basically every dev I know.

Re: Breaking up with JavaScript front ends

#187

Post by eurasiantiger »

knightofmars wrote: post #137
AtlasBarfed wrote: post #24

Earlier quoted context omitted.

Then why is every JS-bro "full stack"?

IMO, I think this is a valid question (though asked a bit crudely). To generalize, it's because someone who has done JavaScript programming can point to NodeJS and say, "I'm full stack." Which, while technically true, skates over the reality of NodeJS as a less than ideal backend (see Ryan Dahl and the dawn of Deno). Second, it's more lucrative to bill oneself as "full stack" even if in reality a person isn't. At one…

Exactly. Full stack engineers are sorely needed in every project because they can see the forest from the trees, not because they are experts in everything from botany to carpentry.

Re: Breaking up with JavaScript front ends

#188

Post by akira2501 »

heather45879 wrote: post #181
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…

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…

> HTML/CSS/JavaScript are good enough as-is—but nowadays the default browser capabilities are incredible compared to a decade ago.

I'm not sure they remember a time when the choice wasn't "X Corporate Framework" vs "Y Corporate Framework" but "Native Desktop Application" vs. "Website Only Application."

I feel like I'm already accepting a huge set of "dependencies" by choosing to develop a web application, and I have a vast stack of technologies to draw upon in building my application already.

Re: Breaking up with JavaScript front ends

#189

Post by bluewalt »

awesomegoat_com wrote: post #50

Good job. This is the next trend out there. Although, this solution feels to be heavily inspired by https://hotwired.dev/ Is there a reason, why new framework (with some extra cool features) have been developed as opposed to contributing to hotwired/turbo frames?

The presentation is 6 years old...

Re: Breaking up with JavaScript front ends

#190

Post by black3r »

arcturus17 wrote: post #124
black3r wrote: post #59

Earlier quoted context omitted.

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.

At work we don't have enough manpower*time to convert our React spaghettis to Next.js, but I'm starting to experiment with Next.js & prisma & postgres aside and plan to use it for my next hobby project which I'm never gonna finish just as the rest of them..., If I'm gonna like the approach and not miss some of Django's features right from the start I'm gonna think about letting Django in the past...

Supabase could be enough for a simpler project where you know you won't need any advanced features.., I wouldn't just start with it if I knew the project's gonna get huge in the future, but I did a couple of smaller projects with Firebase alone..

Post reply on HN