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

161–170 of 433 posts

Re: Breaking up with JavaScript front ends

#161

Post by 0xblinq »

chiefalchemist wrote: post #68
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…

Yes "app-like-ness" when that's appropriate. But a lot of the web isn't that. Yet devs / agencies are using a sledgehammer (e.g., React) when a Phillips head screwdriver is what's need. Users get experiences they don't need (nor want). Site owners gets a maintenance dependency they don't want (nor need).

From my experience, this problem is also rooted on designers and product owners.

My own team “modernized” a forum/blog tool used for internal documentation by moving a lot of it to react and SPA architecture and added ton of “app like” features, and I just hate the thing now. The old version, which we still run on some installations, is way, way faster, easier to use, more responsive and more reliable.

But hey, it looks so App-like now…

Sigh…

Re: Breaking up with JavaScript front ends

#162

Post by quickthrower2 »

deafpolygon wrote: post #157

I wonder how much traction we could get with a no-JS approach.

Modern browsers make a no-JS (and that means not even HTMX) fairly nice. Live updates might be an issue but if you don’t need those…

When the browser can reason about your site it opens up nice cool stuff like right click to open in a new tab, bookmarks always working, fast load times, caching, etc.

Re: Breaking up with JavaScript front ends

#163

Post by yetanother12345 »

claytongulick wrote: post #20
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.

Or maybe people don't like waiting for a page to load each time they click a button?

IMHO this is a false argument.

Ask yourself: Do "people2 prefer looking at "spinners" or more-or-less animated "page loading..." texts?

Waiting time is the issue, the technology is not.

A server generated page that loads fast beats a Framework-generated page hanging every time!

As for technology:

With "classic" server generated pages "people" will know what is going on (browser indication tht page is loading) and they will know what to do (wait a few seconds at most). With frameworks "people" are left out in the cold with no indication what the problem really is and no apparent remedy or path for solution as a page refresh might interfere with state logic or whatnot bringing totally undesired results.

Re: Breaking up with JavaScript front ends

#164

Post by quickthrower2 »

aussieshibe wrote: post #151

Maybe it's just me, but needing to press "back" twenty or so times to get back to HN after viewing some of this presentation really made me question the author's authority when it comes to "how the web should work".

Not sure. Does everything on a public url need to be friendly to random forum shares? Maybe this is good enough for the people who needed to see it.

Re: Breaking up with JavaScript front ends

#165

Post by 0xblinq »

TranquilMarmot wrote: post #86
chiefalchemist wrote: post #68

Earlier quoted context omitted.

Yes "app-like-ness" when that's appropriate. But a lot of the web isn't that. Yet devs / agencies are using a sledgehammer (e.g., React) when a Phillips head screwdriver is what's need. Users get experiences they don't need (nor want). Site owners gets a maintenance dependency they don't want (nor need).

I think the basic divide is something like "CRUD forms" vs "interactive applications". I've built basic CRUD forms with ASP.NET MVC. I've built them with Rails. I've built them with React (+ a hundred random libraries). I've also built interactive "apps" in those languages. Looking back, the amount of "interactivity" that React adds to a CRUD form is NOT worth the added complexity. But! Right now my dayjob is creatin…

I agree with everything you said up to the part about fresh and deno, where it looks like you’re falling in the same trap of those wanting to use react. You don’t even notice it but this is the problem. Always thinking the next shiny tool will solve the problems.

Rails, Lararavel and similar frameworks are great for crud apps. No need for fresh or demo or svelte or next.js for that.

Re: Breaking up with JavaScript front ends

#166

Post by hn_throwaway_99 »

mattlondon wrote: post #96
hn_throwaway_99 wrote: post #61

Earlier quoted context omitted.

> The situation is even worse now. Is it really? I have the exact opposite opinion. I mean, I feel like the industry has pretty well standardized on React in Typescript for the front-end on web apps. Sure, there are other technologies that do different things (e.g. Svelte, and someone else mentioned Phoenix LiveView), but for the standard "I'm building a CRUD-focused web app", there are simple choices to make and it'…

React is used a lot, but it is certainly not the standard. Angular is still used extensively, especially in enterprise

I'd still argue that React is very much the default for new applications where legacy interop or existing team familiarity isn't a factor.

I mean, this is obviously an extreme example, but COBOL is also still used extensively in the enterprise, yes it's still not really used for any new projects.

Re: Breaking up with JavaScript front ends

#167

Post by ryanbrunner »

smaudet wrote: post #127
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…

If you can limit yourself to exactly one, maybe two external deps, which are really just to make your dev life eaiser, you may have something of a point. You have to remember that a large chunk of "web apps" means "electron apps" which are absolute bloated pieces of junk next to their desktop cousins. You also have to remember a 'framework' typically doesn't stand in isolation - tens, hundreds, thousands of dependenc…

> You also have to remember a 'framework' typically doesn't stand in isolation - tens, hundreds, thousands of dependencies typically lurk.

While this is true, at least by having a large number of people commit to the same set of dependencies, you stand a higher chance of complications between those dependencies being ironed out, either directly by the framework maintainers or by the user base of the framework.

Re: Breaking up with JavaScript front ends

#168

Post by 0xblinq »

_gabe_ wrote: post #27
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.

We use SPAs and a pretty strict typescript/react stack. And I still have to know: Cloud Tech (AWS) which also includes, lambdas, Iam management, dynamoDB, cdk or serverless, API gateway, S3, secret managers etc. Add to that list the technologies that often get thrown in for extra monitoring testing etc. Jest or mocha/Chai for unit tests. Dynatrace for monitoring. Kibana or something for logs. Some tool for analytics.…

A friend of mine moved to a company where they use plain Laravel (with just some sprinkles of js using Alpine) and they deploy to heroku. A team of 10 devs, no systems/devops/Infra and he’s fascinated how well things go and how fast they ship stuff compared to where we worked together before (with all the usual react/redux stuff and an elixir backend on kubernetes)

Re: Breaking up with JavaScript front ends

#169

Post by 0xblinq »

misterpurple45 wrote: post #74
_gabe_ wrote: post #27

Earlier quoted context omitted.

We use SPAs and a pretty strict typescript/react stack. And I still have to know: Cloud Tech (AWS) which also includes, lambdas, Iam management, dynamoDB, cdk or serverless, API gateway, S3, secret managers etc. Add to that list the technologies that often get thrown in for extra monitoring testing etc. Jest or mocha/Chai for unit tests. Dynatrace for monitoring. Kibana or something for logs. Some tool for analytics.…

I see this “AWS for everything” Well-Architected stuff everywhere. AWS benefits greatly from inserting itself in between all our architectural layers. There’s nothing stopping companies from using the cloud for its primitives (compute and storage), maybe with managed FOSS services (RDS Postgres). We don’t _need_ to go all in on AWS to build a ‘modern’ web application. Yet somehow much of the industry dances to AWS’ t…

And good luck with having a development environment or even decent end to end/integration testing once you start using all those services.

Re: Breaking up with JavaScript front ends

#170

Post by wefarrell »

jokoon wrote: post #45

Why can't anybody talk about the fact that HTML was not designed for being dynamic? Isn't there any format that is a real alternative to HTML, which is truly interactive, lighter than the DOM, use text as a mediu, is multi usage and platform agnostic, can use whatever scripting language, and be easily rendered? It's not another new format, it's just that a new format is needed to make things simpler. I have zero pati…

No markup format will support interactivity well, you need a full scripting language with all of the standard features.

I don’t think it’s possible to couple the interactivity and visual layout in a single language and have it make sense. We can certainly do better than JavaScript, HTML and CSS but I think there will still need to be at least two languages to describe layout and interactivity.

Post reply on HN