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

221–230 of 433 posts

Re: Breaking up with JavaScript front ends

#221

Post by imbnwa »

shanebellone wrote: post #220
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 agree with the dependency commentary. Tech should value supply chain. Development is slower but Power comes from ownership. I'm also anti-JavaScript, at least in abundance. I noticed this in gaming as well as software... engineers always build for the best hardware. Despite everyone knowing that extremes (in the wild) are a minority. I believe tech needs to focus on building better 4-cylinders rather than expanding…

Partly think that's why there was some dismay at Deno's decision to tunnel packages from NPM, a contingent of folk who wanted a reset on the JS ecosystem and (lack of?) culture

Re: Breaking up with JavaScript front ends

#222

Post by llanowarelves »

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.

It's like ORMs and game engines.

Many times when people try to forgo them, they end up making their own poorly specified and half-baked version of it that only some people (who may leave the company) understand.

Re: Breaking up with JavaScript front ends

#223

Post by esskay »

arcturus17 wrote: post #171
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 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?

it'll be stable when the JS community stops reinventing the wheel several times a year. Every year we have the 'next big thing' and a whole new JS framework and ecosystem thats set to be the one to beat them all.

Fast forward 2 years, its mostly abandoned and upgrading a 12 month old project is a nightmare. That is not stable.

I can pick up a PHP, Python, script written 2-3 years ago and know it'll work if I try to do something with it. With JS you can guarantee that one of the bajilion dependancies has had a backward breaking change or vanished off the face of the earth and the whole thing falls apart.

JS tooling, and always has been a total disaster, and NextJS hasn't fixed that.

Re: Breaking up with JavaScript front ends

#224

Post by minusf »

wruza wrote: post #183
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…

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…

maybe they are cheap, maybe not. but lighthouse prints a warning for "excessive number of dom elements" already at 1500...

Re: Breaking up with JavaScript front ends

#225

Post by lewantmontreal »

dinkleberg wrote: post #26
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…

Just want to point out that unpoly has been around for ages (looks like since 2015). This isn’t a copy of htmx.

Would be interested to know if they stuck with it

Re: Breaking up with JavaScript front ends

#226

Post by bandrami »

ramesh31 wrote: post #16
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'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, What's old is new again. There's an entire generation of developers now who have no concept of the old world. They started with React/Angular/Vue and have no idea that SSR was the standard default for decades. And now it's a "new idea" that is held up against JS development with no…

As somebody who started in the days of cgi-bin and SSIs, I've lost track of how many wheels I've seen re-invented over the past 25 years. Fortunately I do backend which is at least slightly more stable (modulo the fact that I'm sending more or less opaque-to-me javascript rather than html).

OTOH I have really surprised some PMs by producing a Perl cgi wireframe site during the course of the meeting where we designed the wireframe so we could actually try it. It's a skill more devs should really have in their back pocket.

Re: Breaking up with JavaScript front ends

#228

Post by eloff »

I was just building a very light version of this today. I'm just a backend developer sick of the bloated crap I have to maintain in my day job with React. I'm going old school, and going back to server side templates. Native compiled jinja2 templates using askama in Rust, tailwindcss, Postgres, and a little JavaScript magic to do things like server side form validation without refreshing the entire page.

I'm loving it so far. The pages load instantly, they're extremely lightweight, and all the state is on the server where it's easy to debug and all strongly type checked with Rust. I called my little "framework" curmudgeon, because, well I'm under no illusions about what I'm doing. Get off my lawn with those SPA JavaScript frameworks.

Re: Breaking up with JavaScript front ends

#229

Post by arcturus17 »

esskay wrote: post #223
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?

it'll be stable when the JS community stops reinventing the wheel several times a year. Every year we have the 'next big thing' and a whole new JS framework and ecosystem thats set to be the one to beat them all. Fast forward 2 years, its mostly abandoned and upgrading a 12 month old project is a nightmare. That is not stable. I can pick up a PHP, Python, script written 2-3 years ago and know it'll work if I try to d…

I've been coding my front-ends in React for 5 or 6 years. I don't have any of the problems you describe, I can also pick up old projects and run them without much problem. There was the change from classes to hooks but I still remember classes fairly well. Then there's been NextJS which I've picked up in like a weekend. That's it.

There are new frameworks popping up all the time. Some look very interesting. But React has been around since 2013 and it's a world standard.

I agree that JS/TS tooling is largely a mess, it's why I don't like JS/TS back-ends other than maybe some simple NextJS API routes, or an Express server with something like three files. But on the front-end, React CRA and NextJS (with TypeScript) both have served most of my needs with just a few CLI commands and minimal config. I rarely have the need to meddle with the tooling and I can get up and running in seconds.

Re: Breaking up with JavaScript front ends

#230

Post by tartoran »

_the_inflator wrote: post #198
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…

As the old saying goes: "We have a new framework that will make the existing ones obsolete." This makes n+1, not 1. An agency usually deals with different customers, different settings. What I achieved by migrating dozens of apps to a Angular only frontend, is a platform. Reusable components, devs that can easily switch projects. This is the one and only framework we use, monoculture. This is a beast, we could abstra…

I could see Angular working out great for certain type of projects and teams. I used it for one project for front end and didn’t dislike it at all. Unfortunately I see Angular relegated in favor of React mostly..
Post reply on HN