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

131–140 of 433 posts

Re: Breaking up with JavaScript front ends

#131

Post by kyleyeats »

tobr wrote: post #71
kyleyeats wrote: post #58

This is so overdue. I'm ecstatic to see this finally happening. The frontend framework bloat trend honestly went on ten years too long. It was like the thin client and thick client debate turned into the thick client and thicker client debate. People will roll a gigantic create-react-app mess for the tiniest of frontend projects. Yes, it's an instant codebase! But that's all code you have to maintain. Stuff like hotw…

I don’t see the difference. Isn’t backend code code you have to maintain too?

Yeah it's gonna be somewhere. I guess it's really about the sweet spot that minimizes the complexity on both sides. This captured it: https://imgur.com/a/mx7Y0uD

Re: Breaking up with JavaScript front ends

#132

Post by futureproofd »

22289d wrote: post #6

If this page is a demonstration of what a future without JavaScript would look like, it's an unintentional advertisement for sticking with JavaScript.

I think the intention was to spark conversation loosely around SPAs vs SSR. It seems we're at yet another turning point and frankly, I'm enjoying the debate.

Re: Breaking up with JavaScript front ends

#133

Post by caseyf »

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…

More like a hotwire but instead of being extracted from Basecamp's work it feels like it could have been extracted from Makandra's work maintaining many different Rails apps.

I think it's very good and for me, the best of the bunch. I'm moving a very large app to it (from old school RJS) and it seems to have thought of everything that I need.

Re: Breaking up with JavaScript front ends

#134

Post by nicoburns »

t8sr wrote: post #126
nicoburns wrote: post #113

Earlier quoted context omitted.

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.

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), which nobody uses.

Meanwhile most of the industry is using React, which is actually pretty well engineered and perfectly fast (you may well find yourself using a slow React app, but that's not React's fault).

P.S. Talking layer of DOM nodes, I actually did a few samples of this the other day. Gmail has 34, which was by far the deepest of any website I checked and probably isn't helping it's performance.

Re: Breaking up with JavaScript front ends

#135

Post by cphoover »

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…

My problem with liveview IMHO is that it requires an active internet connection and doesn't have offline support, which is a step in the wrong direction in terms of UI performance to me.

It makes sense for a subset of applications that require connectivity but many apps or tools should be able to work offline or without a constant connection.

Re: Breaking up with JavaScript front ends

#136

Post by dmix »

kyleyeats wrote: post #58

This is so overdue. I'm ecstatic to see this finally happening. The frontend framework bloat trend honestly went on ten years too long. It was like the thin client and thick client debate turned into the thick client and thicker client debate. People will roll a gigantic create-react-app mess for the tiniest of frontend projects. Yes, it's an instant codebase! But that's all code you have to maintain. Stuff like hotw…

This isn't the only one... JS frontend world as a whole has been moving back to SSR for the last 5yrs. But importantly while still maintaining the benefits of desktop-style interactivity, instant page transitions, componentized code organization, treeshaking/ + lots of small JS/CSS files only loading what's needed vs one massive asset, cached/offline friendly JSON data streams, etc, etc.

It is still SSR but it's much much more than just going back to 2005. Combining the lessons of the last 15yrs with the as much of the past SSR world as possible. It's not simply throwing it away and regressing to the old ways.

Re: Breaking up with JavaScript front ends

#137

Post by knightofmars »

AtlasBarfed wrote: post #24
whatever1 wrote: post #17

Earlier quoted context omitted.

SPAs solved a labor problem I think. It was the reason that front end development grew so fast. It is much faster to train people on a combo js+css framework rather than training someone on backend languages, databases, queues, authentication, scaling + html & css for server side rendering.

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 point in my career I would have considered myself "full stack". Over time I realized that a "full stack" engineer is a jack-of-all-trades type, which in theory, can be valuable in the right circumstances as an individual doing work alongside non-full-stack engineers. Asking a room full of "full stack" engineers to design and build a product of any complexity above CRUD will naturally lead to a self-sorting of UI/UX and server side engineers.

Re: Breaking up with JavaScript front ends

#139

Post by tannhaeuser »

Since TFA is from 2016, it's pretty silly to discuss about trends here isn't it? There's certainly no less JS today, except due to being there less web sites in the first place.

What's with this htmlx shilling anyway? If you want an app, just use JavaScript; what's the point of arbitrary syntactical barriers between page content and logic, except for maybe CSS done by UX experts - though if you're bad at CSS then why tf are you into web frontends anyway?

If OTOH you think about content-heavy sites, document-oriented workflows, and publishing (ie. what the web was originally made for) then just use a competent markup processor. HTML is based on SGML after all, giving you templating, markdown processing, stylesheets, pipelines, toc and search indexing, and whatnot; there's a wealth of SGML/XML-based tools available.

Re: Breaking up with JavaScript front ends

#140

Post by andrewmutz »

jrochkind1 wrote: post #21

It's interesting that they appear to plan to use with Rails as a back-end (they mention Rails bindings), as Rails 7 release corresponded with a solution which appears somewhat similar to me, turbo/stimulus. (I want to provide a link to it, but I honestly don't know any great docs for it!) But I haven't used stimulus/turbo myself. I'd be interested in a compare/contrast between Rails' Stimulus/turbo and "Unpoly" cover…

I agree that Rails 7 has fantastic options for achieving fantastic "UI Fidelity" with traditional Rails high developer productivity.

The official docs are decent:

https://turbo.hotwired.dev/

https://stimulus.hotwired.dev/

Post reply on HN