Hacker News Reader

Would this example be considered "trivial"? https://www.youtube.com/watch?v=3GObi93tjZI

But also, you can mix things togheter. You can just use react based app 'embeded' into mpa for when you need that heavy lifting, and the same keep the content part of your app simple.

"But why would i do that, if i'd already use react for some parts, why not every where".

Becuase then it leads to abominations like reddit or facebook, where websites that are basically glorified text forums will use gigabytes of memory, have terrible UX, be slow and will crash your browser if you leave them open for too long.

The wall of HTML soup he shows for facet "component" (time 11.33) is something I don't want to ever see again in professional setting.

Stringly typed logic and CSS / JS somewhere miles away in directory structure making it very hard to reason about.

I very much prefer sticking to small, composable, encapsulated, actual components made in React or sth similar.

That file has like, 60 lines. Calling it a "wall of HTML soup" is a bit disingenuous. But if you REALLY have that much aversion to code, there is no inherent reason why you couldn't split it even more. CSS being miles away is again, just a matter of taste. No inherent reason why you could't use Tailwind for example.

> why you could't use Tailwind for example

To have even more HTML soup? No thanks. Luckily I live in a world of better DX. With styled-components my CSS primitives are typechecked. Hell even with SCSS and CSS modules I have more sane and IDE supported experience.

But this styling lives in your component file, doesn't it? So it makes just as much "wall of [code] soup there as it makes it here". Tailwind was just an example pointing out you don't need a separate your code across entirely different directories, not recommendation of specific technology

I don’t like Facebook but claiming it’s a “glorified text forum” is utterly absurd. Please argue in good faith here

But it is though? I'm not talking about everything facebook provides, but main content page is just a list of posts with with discussion underneath them. Sure, you can embed some media into the it, but still. There is nothing inherently different about structure of facebook post compared to a post on a forum.

And yet, despite everything facebook is doing, the most (and only) reliable way to load new comments under the post is to force refresh entire site. Except it's not easy anymore, because facebook tries to be SPA.

So we gave up simple and reliable solutions in favour of over engineering that doesn't even work. And all that for no good reason, other then being trendy and having an SPA

Inherently different things:

- the social graph underlying every post and content producer (one of the reasons FB introduced graphql)

- the recommendation and advertising algos that are interdependent on the content feed

- the realtime “fire hose” nature of the feed integrating a huge number of disparate data sources

Again I don’t like FB the app and I’m not on it. But even its core product is vastly more complex than a forum.

FWIW I’ve developed social networks and forums professionally; social networks are inherently more interactive. My first real exposure to front end dev was when I worked on a social network. If I had to build the same webapp today there is zero consideration of writing it as a backend rendered application or restricting to only progressive enhancement. It would only put off the inevitable migration to real FE tech.

The things you mentioned are backend dependant, though, not intrinsic to how you render and present them.

What specific aspects of facebook's comment section under post make it that json response is so much better then a html one?

>But it is though?

At some point quantitative change achieves a qualitative effect. I would think Facebook or LinkedIn or Twitter have all reached that qualitative effect to change from being just a discussion forum.

However qualitatively the social functions of these apps present an extra functionality missing from traditional discussion forums. Being able to track users, notifications of the users updates, blocking certain users from being in the message - which is a traditional messaging function not found in discussion forums. Suggestions of people or subjects to follow given on what you have done in the past, weighted based on various algorithms to determine how recent your past activity was and what your current interests seem to be.. I'm sure you could think of a load of other functions that are not traditional discussion forum functionalities.

I don't know if you are doing that intentionally, but you are completely ignoring the context of the argument, which is advocating of mixing and matching statically generated content and using component based spas only where it's needed.

In the parent coment alone I emphasized that I acknowledge that Facebook as a whole provides more then just a forum, but it's core content inherently doesn't differ much from being one.

Moreover, functionality like notifications or suggestions are inherently server generated, as such they don't require content itself to be served in specific way.

Cool what Contexte did with HTMX, but personally I really dislike the amount of data packed into those HTML templates, those hx-get attributes are frighteningly long.

As a counterpoint: I consult for government agencies that have all separately decided to standardise on Angular.

They mostly publish static content: alerts, updates, reports, etc…

At most they might have a single page somewhere for submitting a payment or a simple form.

But because of this JS framework by default policy all their apps end up with extra complexity, extra build steps, and an awful amount of dependency maintenance.

Most of their sites could have been static HTML files on disk.

That's understandable. Though I actually can see some logic in it. It's got to be way easier to hire Angular developers than it is to hire someone who wants to eek out the maximum performance with this lightest-weight approach (and do it in a maintainable/understandable way).

I'll never say Vue/React/Angular are "light" and I'll fully admit we give up some performance for DX (and UX) but it's a tradeoff I think is worth it (I understand if you don't agree).

In the same vein, I know cross-platform frameworks like Ionic/Quasar are nowhere near as good as native apps. That said the skill set you need (and dedication to actually embracing the platform idiosyncrasies) to make _good_ native apps is not cheap or easy. Cross-platform apps might not fit in as well and might be heavier but they allow fewer people to do more with less. Heck, I have a side-business that relies _heavily_ on apps and it would not exist if I couldn't write them in HTML/JS/CSS as much as that makes some people's stomachs turn.

> It's got to be way easier to hire Angular developers than it is to hire someone who wants to eek out the maximum performance with this lightest-weight approach.

I disagree, at least around here. Frontend developers with react/angular experience are a hot commodity and really hard to hire, yet just about anyone from any tech tech can knock out html and some minimal css.

Kind of obvious why, any of the react based frameworks all fail an audit.

Doesn't even make sense to me why anybody uses them.

You cant audit static sites (ones thing I don't like about having traditional linked libraries).

What makes certain libraries auditable? I doubt react was compliant when first came out.

Why can’t you audit a static site? Seems very straight forward. We already audit static sites for accessibility (503 compliance).

Any resources you can point to? Seems like it would be a worthy effort to make other tools compliant.

Definitely something I want to learn about.

What kind of audit are you talking about?

Probably since 99% of websites don’t need to pass an “audit”, whatever that means

I think the future of webdev is a framework-like system that can be added gradually to basic HTML, rather than one which requires that you totally replace it with JSX, etc. from the start. Webcomponents are a huge step towards a time when we can add state managers and things like that without bringing in a monolith all at once.

Some projects require 1% of a framework, others require 98%, but the majority are in a range between 25% and 75% which currently need you to re-architect for a total perfusion of React or a competitor.

Svelte is pretty close to this (at the expense of a build step). It gives you (in my opinion) better ergonomics that React, has no runtime and outputs sites that don’t require JS unless they do.

Sveltekit (its official fullstack framework) even encourages building apps that fall back gracefully for users with JS disabled.

Of course, none of that is to say that you can’t build bloated, badly performing apps in Svelte. Just that you *can* have the best of both worlds, even for simple/static sites.

And I'll happily use such a system once it exists but Vue/React/Angular exist today and have allowed a level of productivity, DX, and UX unheard of with what browsers provide by default. If browsers want to compete then be by guest but FF seems to busy doing next to nothing, Chrome is eating everyone's lunch and giving the middle finger to standards, and Safari is derided for not being Chrome and slow to implement some things (while being fast on others).

I think it's more likely to see some kind of WASM-based replacement take off rather than browsers get their act together. That's not to say browsers aren't improving, they absolutely are, but when it comes to competing with the existing frameworks the only answer so far has been Web Components and it was very lackluster IMHO.

All the things that "monoliths"[1] bring web components ate not bringing, and won't bring in any conceivable future.

[1] There are very few monoliths among the frameworks these days, and apart from React and Angular [2] most aim for rather small bundle sizes

[2] Out if the blue Angular just released version 17 with all the goodies you'd expect from a framework in 2023

> The thing is there are just vanishingly few places where you only need a "sparkling of interactivity on top".

I would say it's precisely the opposite.

Say 97% of work done by web pages and web apps in practice boils down to "render some data available on the server as HTML, then show it to the user". For these cases, putting what amounts to an entire GUI framework written in Javascript on the frontend is massive, bandwidth-sucking, performance-killing overkill.

There are absolutely exceptions. Google Sheets exists. But your project is probably not Google Sheets.

What is this “entire GUI framework written in JavaScript”? React isn’t a GUI framework, even Angular despite being quite batteries included is not that.

I swear the people writing these comments aren’t working in web development?

> try using the default date/time picker and get back to me.

Building my first web application in react currently and this resonated with me on such a deep level.

React is not a framework.

It is a fancy HTML templating library first and foremost and you should use it when you need HTML templates, which means you that can use as little or as much of it as you want.

I’ve built mostly static pages with React loaded and embedded into parts of the page. The webpages would function without JavaScript enabled.

How does the React part of your page work without JavaScript enabled? Are you using a static site generator (or another server side rendering tool) like Next.js?

Fully agree, thanks for elucidating.

IME there’s a crazy amount of strawmanning that goes on with these “anti-react” technologies/cults. Yes of course your html and css static site doesn’t need react. But most of us who are actual software devs/engineers aren’t working on static websites like that!

I think this is a little gatekeep-y. Building static sites is real engineering. When you're building a site that scales in content (for e.g. one that contains thousands of pages that are updated regularly) you need to really know what you're doing. A CMS can help you manage your content, but you need to decide how to build your pages from it. There are things in the React space that can handle a lot of the complexity (for e.g. Next.js on Vercel with ISR), but you need an engineer to make the right trade offs.