Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's time for modern CSS to kill the SPA

jonoalderson.com

Post reply on HN
Print view View original

421–430 of 516 posts

Re: It's time for modern CSS to kill the SPA

#421

Post by threatofrain »

brulard wrote: post #356
threatofrain wrote: post #23

I don't know what universe this SEO-consultant author lives in. The author gives Next & Nuxt as an example of the kind of frameworks going against his prescription, but that is so wrong. 1. Next won the war in the west, big time. Very very big time. Whenever people talk about new React apps they inadvertently mean Next. On the Vue side Nuxt is the default winner, and Nuxt is just the Next of Vue. That means that by d…

How did next win the React framework war? Is it not few years already that see exodus from next to remix/react router, and more recently to tanstack start etc. because of unnecessary complexity, difficulty to run next on anything but vercel, misguided API changes etc.? You mentioning facebook docs pointing to next, when they explicitly mention remix and other is quite misleading.

Well, you must know how to look at download stats, search metrics, GitHub activity, social media temperature, or job posts. I feel that seeing is believing with your own eyes is sufficient for anyone who wants to investigate the issue of whether there’s any winner in popularity.

To not be misleading I wouldn’t have brought up the existence of remix lest people think Microsoft belongs in the same discussion as my software consultancy.

To be clear I’m using Tanstack Start right now.

Re: It's time for modern CSS to kill the SPA

#422

Post by gmadsen »

suzzer99 wrote: post #415
benreesman wrote: post #394

Earlier quoted context omitted.

I don't know that there's "real" programming, that seems like a hard fight to fight on either side, it's like arguing about whether animals are conscious or something. Are people? Who knows, pass the blunt. But there's been this really sharp over-correction to where now an obvious thing that is just common knowledge and that was never taboo is now considered impolite to even allude to. Frontend programming is among t…

Front-end programming is easier in the sense that you can make little mistakes and your entire app doesn't fall down. As someone who's done decades of both, there's nothing conceptually easier about well-executed front-end programming over back-end. The stakes just aren't as high.

I think the argument might be that it takes less domain knowledge of hardware and all its abstractions, which does require a minimum threshold of reasoning and abstract thinking ability. I have high confidence someone who could built a database or kernel could also do front end work with a reasonable ramp up time.

I don’t share that confidence for the inverse in the nominal case

Re: It's time for modern CSS to kill the SPA

#423

Post by tomhallett »

codingdave wrote: post #14

SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load. Smooth transitions are a nice side effect, but not the reason for an SPA. The core argument of the article, that client-side routing is a solution for page transitions, is a complete misunderstanding of what problems SPAs solve. So absolu…

Depends on the definition of SPA, but in the days of jquery, I hardly consider any of that single page app. For example, the server rendered page had most of the html initial rendered, jquery would attach a bunch of listeners, and then on an update it incrementally. If lucky, we had a duplicated x-template-mustache tag which had a logic-less template that we could use to update parts. Jquery and duplication was the “problem” which drove everyone to SPAs.

Re: It's time for modern CSS to kill the SPA

#424

Post by wredcoll »

dataflow wrote: post #396
wredcoll wrote: post #376

Earlier quoted context omitted.

> Non-JS developers mystified and irritated at a bunch of practices they've never really internalised My current explanation goes something like this: "I'm a smart guy. Front end development looks simple. If I find it hard to do, that must be the fault of javascript somehow"

Note those are not mutually exclusive. It's entirely coherent to believe you find a tool hard to use for reasons relating to the tool itself, and that the task you're trying to accomplish is also difficult independently of that. Analogy: imagine trying to give a good presentation with a horrible text-to-speech (or translation) system. Just because good presentations are hard that doesn't mean you don't get to complai…

Yes, but now you're getting into "there are two types of languages, the ones people complain about and the ones nobody uses".

There are obviously flaws and issues and annoyances in js world, but a lot of those come from having to solve much harder problems (compared to say, do a sql query and turn the results into json).

Re: It's time for modern CSS to kill the SPA

#425

Post by martrapp »

andrewstuart wrote: post #407
martrapp wrote: post #357

Earlier quoted context omitted.

What exactly hurt the reliability? Early on, I often ran into false starts because I did not pay enough attention to proper render blocking.

It’s a ridiculous API that is way too complex. Try using it and you'll see. It takes huge amount of setup which it then seems to pay attention to or not, depending on his knows what factors. Go ahead try it for something beyond basic usage then tell me how reliable and easy it was.

I tried something here: https://vtbag.dev Took me a while to figure things out, but I'm happy to share what I learned. That's why I asked: I would be glad to help with concrete problems.

Re: It's time for modern CSS to kill the SPA

#426

Post by wredcoll »

PaulHoule wrote: post #401
wredcoll wrote: post #375

Earlier quoted context omitted.

> The OG web was missing a few things. Forms were usually written on one HTML page and received by a separate cgi-script. To redraw the form in case of errors you need one script that draws the form and draws the response and a router that choose which one to draw Yes, I was there, I wrote and used these pages. It sucked. Things are better now. > So the knowledge to build the form applications we were building in 199…

I've been in a happy place with React with some projects. I've worked on some where it was valid choice but boy the annoyances, like not being able to test your components because you're on an old version of React where your test framework can never know when the last render happened because you depend on a large number of components which don't believe they'd run on the current react but probably would if you could…

> I sketched out an alternative called "Nemesis" which grew into an HTMX-based system where it takes one programmer an hour to code a task and there is no build, and between Flask and the 15-or-so helpers it is easy

My argument here is basically creating that is really, really hard, and there's no framework or library that will make it easy.

React and friends are a mess because they're dealing with hard problems, kinda like systemd or kubernetes.

Writing code that lives entirely inside the machine is a lot easier than having to interface with the messy real world.

Re: It's time for modern CSS to kill the SPA

#427

Post by racecar789 »

davidfiala wrote: post #40

SPAs are not about view transitions. TFA implies that fancy transition is important between pages (wrong!) and blames a "CMO" or "brand manager" rather than challenging their own preconceptions and exploring the value an SPA does add: - excellent frameworks for client side logic (interactivity) - separation of concerns (presentation logic vs. backend) - improved DevEx => inc. speed of development => happiness for all…

What does TFA stand for?

Re: It's time for modern CSS to kill the SPA

#428

Post by reactordev »

zero_shift wrote: post #275
codingdave wrote: post #14

SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load. Smooth transitions are a nice side effect, but not the reason for an SPA. The core argument of the article, that client-side routing is a solution for page transitions, is a complete misunderstanding of what problems SPAs solve. So absolu…

This article is full of misrepresentations and lazy takes. The author has had other anti-JS polemics widely upvoted on HN, which were just as carelessly written. But people upvote it anyway. What is the cause of this? 1. Bad experiences with JavaScript apps that have aggregated complexity (be it essential or incidental complexity)? 2. Non-JS developers mystified and irritated at a bunch of practices they've never rea…

I don’t know, I think reducing bundle sizes and bloated javascript in favor of built in support for view transitions warranted a blog post against one of the primary arguments for why SPA.

I agree with the author. I love React. I shouldn’t need two dozen more dependencies. We ditched server side for client side in 2010 for speed. Now that we have 200x more compute power, more powerful CSS, more robust html (with web components), we can go back to server side rendering and only send what’s required for the user at the time of action.

Re: It's time for modern CSS to kill the SPA

#429

Post by leptons »

youngtaff wrote: post #269
aryonoco wrote: post #131

Earlier quoted context omitted.

Angular not only appeals to Java developers, it also appeals to .NET developers. TypeScript of course borrowed a lot from C# (having the same designer) and dependency injection, MVC patterns etc closely resemble .NET patterns. Interestingly, new Angular is slowly moving away from these, introducing Signals for state management and standalone components, and I see these developers actually struggling a lot to adopt ne…

Angular was created so Java developers could create browser apps

Angular 1.x seems vastly different than Java. I doubt a Java developer would want to use it, so I'm not sure your claim is valid.

Re: It's time for modern CSS to kill the SPA

#430

Post by leptons »

tanduv wrote: post #244
wolpoli wrote: post #192

Earlier quoted context omitted.

Honest question: Where are the places with low-bandwidth internet? Are we talking about cruise ships and satellites internet use cases?

TBH even in the SF Bay Area "tech capital of the world" you'll find areas with spotty reception. https://www.reddit.com/r/bayarea/comments/1cqhr4i/what_is_up...

Back around 2001 I visited South Carolina, and it was like being transported to the future of mobile internet. They had some kind of high-bandwidth cellular setup in the area that was far ahead of the rest of the country at the time, I think I recall it being around 20Mbit wireless. I was told the area was a testing ground for new tech. I was kind of shocked that somewhere that seemed so stuck in the past had such cutting edge tech deployed. I thought why is this not in SF??
Post reply on HN