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

271–280 of 433 posts

Re: Breaking up with JavaScript front ends

#271

Post by afavour »

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.

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.

Re: Breaking up with JavaScript front ends

#272

Post by Throwaway23459 »

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…

React and Angular are both blazing fast, and are definitely not pointless. Open create react app, spin up a page with 50000 buttons, compare that to a plain js version, then come back and tell us about the atrocious performance.

Re: Breaking up with JavaScript front ends

#273

Post by siquick »

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…

If those are the only complaints you have about Next then they’re doing great.

Re: Breaking up with JavaScript front ends

#274

Post by LudwigNagasena »

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…

There is a reason why modern UI frameworks like SwiftUI or Jetpack Compose look more like React rather than pure HTML/CSS/JavaScript. And it is not because iOS and Android can’t run WASM.

Re: Breaking up with JavaScript front ends

#275

Post by guilherme-puida »

riversflow wrote: post #238
0xblinq wrote: post #146

Earlier quoted context omitted.

Well, get ready for it. GitHub is moving towards React, Next, etc. I bet it will be another disaster like Reddit.

I’m actually happy about how garbage reddit is. I considered installing a redirect plugin to send me to the old.reddit subdomain[1], but ultimately decided I shouldn’t encourage myself to use Reddit, having it load into that dumpster fire of a front end has really helped discourage me from using or interacting with it. I can happily report my reddit usage is at an all time low! [1] fun fact, you can shorten this to “…

> I considered installing a redirect plugin to send me to the old.reddit subdomain

I use RES[1] to force the old layout (along with many other things).

1: https://redditenhancementsuite.com/

Re: Breaking up with JavaScript front ends

#276

Post by chrischattin »

I’ve been saying this for years, and receiving the subsequent down votes.

Front end frameworks are an anti-pattern. They hviolate DRY principles and exemplify premature optimization.

They did not grow organically out of the open source community because they solve a problem only a handful of companies on the planet have. They had to be pushed into the dev mind share by the mega cap tech companies. Unfortunately, they’ve been successful over the years.

Re: Breaking up with JavaScript front ends

#277

Post by heather45879 »

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.

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; JavaScript was for sprinkles of functionality.

So no matter how you spin it—each framework is a workaround making the browser do something it wasn’t designed for.

When I say that I don’t mean “abandon all APIs”—I’m just stating why things are so complicated in the web space.

Moral of the story—give us more static content please. “Dynamic” means ads and wasted CPU cycles.

Re: Breaking up with JavaScript front ends

#279

Post by Yiin »

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…

Not everyone is a fan of throwing away secure sandboxed environment easily accessible apps run on to native applications that might not even be built for your OS.

Re: Breaking up with JavaScript front ends

#280

Post by wwweston »

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.

> 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 the resources to do everything right — is still introducing nav-state related bugs.

Frameworks might focus people’s attention on what needs to be done, but the fundamental capabilities aren’t in the framework, they’re in the browser and the heads of the devs.

And of course, the other possible point the parent is making is not that people should be doing SPAs from scratch (which probably wouldn’t be wise in many cases) but that it’s not wise to start from the assumption that you should be making an SPA.

Post reply on HN