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

301–310 of 433 posts

Re: Breaking up with JavaScript front ends

#301

Post by t8sr »

afavour wrote: post #271
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…

> This kinda crap is why the gmail tab uses a GB of memory. It isn’t. Ironically things like memory leaks are why pages use a ton of memory and in my experience everyone coding from scratch results in more of them, not less.

I really don’t agree. When I worked at Google, I filed a couple of bugs for memory leaks in the new gmail, and to my knowledge they still haven’t been addressed two years later, because there are a million dependencies and the thing is so complex no one can debug it, or even come up with a reliable repro.

Re: Breaking up with JavaScript front ends

#302

Post by arminiusreturns »

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…

What irks me is the javascript part. You dont need to run random scripts on my system, just send me some fucking text! Make it a touch prettier with css! The javascripts are so bloated, spy on you, are often a malware vector, and offer little real user benefit.

Re: Breaking up with JavaScript front ends

#303

Post by Aeolun »

CharlieDigital wrote: post #197
arcturus17 wrote: post #171

Earlier quoted context omitted.

I agree with everything you say, but I'm in the camp that thinks that front-end is stabilizing. I feel many web projects can go a long way with something like NextJS, a few classic libs (eg, lodash/underscore/ramda), maybe a few libraries for handling data if you really need them. The design frameworks (MaterialUI, Tailwind, etc.) are also fairly stable. Perhaps that's one dependency too many for some?

Next.js is really bad, IMO and perpetuates more bad practices. Both Target.com and Walmart.com are Next.js apps. Both utilize SSR to render the pages (view the markup in the network tab). Both then STILL send the full data model to the UI (check the `__NEXT_DATA__` on Walmart.com and `__TGT_DATA__` on Target.com) because Next.js doesn't quite offer the right amount of control over what to send back (compare this to A…

Next.js is really easy for developers of all levels to work with though. It’s main benefit is the ease of use, not the optimized client side data transfer.

What I see from Astro.js is a lot of magic. This is great if it works, but chances are it won’t for a lot of people.

Re: Breaking up with JavaScript front ends

#304

Post by 0xblinq »

sodapopcan wrote: post #202
0xblinq wrote: post #150

Earlier quoted context omitted.

Livewire is intended to be used where you’d otherwise need to do an API call anyway. It is not intended to handle every single click and toggle and key press. You still do that on the front end, usually with Alpine. It is a way to avoid writing backend APIs. If you’re sending every click or every key press then it’s not the tools fault. I agree though, that this should be better explained in their docs.

They said LiveVIEW not LiveWire. Same-ish deal, though.

Oh, sorry. I missed that.

Re: Breaking up with JavaScript front ends

#305

Post by t8sr »

Tade0 wrote: post #288
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…

> 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 f…

You can say that about any engineering problem and be right 99% of the time. Because it’s always true, it’s not a super useful analysis.

Somehow, software on embedded, the kernel, graphics, flight control, etc. is all developed by equally large organizations and while they’re far from perfect, they produce far better software than the vast majority of web UX organizations.

Something about web dev is uniquely terrible, in addition to the common factors you mentioned.

Re: Breaking up with JavaScript front ends

#306

Post by t8sr »

smoldesu wrote: post #158
t8sr wrote: post #121

Earlier quoted context omitted.

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…

What browser are you using? Having Gmail open doesn't even use half of a percent of a single core on my machine (Linux, x86, Chromium).

Chrome on an M1 Pro Mac. This is the number that Chrome’s task manager shows me.

I do have a lot of emails, but I think it should only have to worry about 100 of them at a time, so I don’t know why it’s different for me and you. It is possible that my account still receives beta features, because I used to work there, but I remember it being like this for multiple years, since the new gmail came out.

Re: Breaking up with JavaScript front ends

#307

Post by steve1977 »

jillesvangurp wrote: post #297
sph wrote: post #29

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

I would say things are improving. Through WASM we are now getting more languages running in the browser. They are starting to bring alternative frameworks and ways of doing things to the table as well. Instead of this frontend / backend notion, we should start thinking again about the notion of networked applications; like we used to do before the web became a thing. Inevitably you want some computation to be close t…

How is WASM different from what we had with Java applets? (haven’t looked deeply into WASM yet, so seriously asking)

Re: Breaking up with JavaScript front ends

#308

Post by t8sr »

Throwaway23459 wrote: post #270
t8sr wrote: post #121

Earlier quoted context omitted.

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…

Well google use all of their own internal 'frameworks', so you can't really use their web applications to judge the rest of the web.

This used to be true but isn’t anymore. For a while they pushed Angular, nowadays I think a lot of teams are using react. GWT is long deprecated and gone.

Re: Breaking up with JavaScript front ends

#310

Post by omegabravo »

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…

None of what you have outlined is actually a problem.

If your requirement is to deliver an application to users on multiple platforms then a web application is a great target.

People complain about HTML, mean while new platforms (Swift, MAUI, Flutter) still design tree like documents. It's insanely fast, optimised, accessible and the tools are fantastic.

Frameworks don't change browser behaviour, they allow you to go up a layer of abstraction. Static content is great for static content. It would be a terrible fit for a rich text editor, a dynamic chart or anything that requires interactivity.

The ecosystem is great. Native applications can get you a more optimised experience at a cost. That cost is not worth it for many solutions.

Ads are on native compiled apps too, it has nothing to do with HTTP/HTML.

Post reply on HN