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

Second-guessing the modern web (2020)

macwright.com

Post reply on HN
Print view View original

281–290 of 309 posts

Re: Second-guessing the modern web (2020)

#281

Post by catlifeonmars »

disjoinder wrote: post #278
catlifeonmars wrote: post #263

Earlier quoted context omitted.

Absolutely I can understand QBE being prior art for a number of querying paradigms. However, the two aren’t closely related. As far as the name goes, the “graph” in GraphQL likely refers to the data graph (as opposed to “graphical”) as data graph traversal is one of the key selling points of the language. The other one being homoiconicity between request and response.

"prior art" Are you suggesting GraphQL is novel and non-obvious? The term "prior art" of course comes from the patent law. Are you suggesting that the term "prior art" does not imply any relation (as in "relate to")? If so, that's false.

I made no such suggestions. I was suggesting that it’s certainly plausible that QBE influenced aspects of GraphQL. The “prior art” being QBE, not GraphQL.

Re: Second-guessing the modern web (2020)

#282

Post by h0l0cube »

scrollaway wrote: post #256
h0l0cube wrote: post #165

Earlier quoted context omitted.

Not really. If you have to make database queries in order to display the page, there's no way of getting around it. Even if your webserver isn't in a cluster with your API and database, while you might be sharing the load between your servers, it's still server load that needs to be accounted for. And if it is in the same cluster, probably cheaper to make those fetches from your webserver than to have multiple connec…

You're still making assumptions. Some stuff is harder to calculate server-side, period. For a very simple example, I'm currently replacing a SSR feature that takes a list of items and renders a "screenshot" of them. The screenshot has to go through PDF rendering, conversion to JPG, it's insanely expensive. I'm replacing it with a client-side generation of an SVG, and in-browser conversion to PNG. It's very clean, ver…

Firstly, thanks for providing an explicit criticism to the argument. It's more helpful than a dismissal (or an inexplicable downvote), and it's appreciated.

As I see it, the subject of the OP, and this broadly this thread, is about the downsides of using SPAs (e.g., React) vs SSR for applications that require server-side persistence. Of course, pre-processing (or display post-processing) client-side makes a lot of sense. Such client-side offloading doesn't require an SPA, and also it can be part of an SSR driven application (as you are doing) using vanilla JS. So the distinction here between SPA and SSR is moot.

The cycle of data retrieval -> user transformation -> data persistence to server, is where SPAs vs SSR have actual tradeoffs. And this, I believe, is what zozbot234 was alluding to. As for Hadoop, I don't personally know how that fits into modern web apps.

Re: Second-guessing the modern web (2020)

#283

Post by webmaven »

8n4vidtmkvmk wrote: post #153
webmaven wrote: post #140

Earlier quoted context omitted.

> And kids, that's the story of how I met your templating system. > ALL of them suck. ALL of them are incredibly hard to lint, test, get right. They scale badly. They're all awful. That's not really true. But fairly incredibly, it seems relatively little attention has been given to the design of HTML templating languages (certainly there are a lot of them, but most seem to have accreted rather than been designed). An…

TAL looks nasty. If you want conditionals in your HTML, just use conditionals. Don't hamfist it into the HTML syntax. Twig or Pug/Jade are the best ones I've seen. C#'s Razor seemed pretty good too in the brief time I used it.

If you have some other way of being able to view an unrendered template in a browser and have it display sanely, I'd be very interested to know about it.

Re: Second-guessing the modern web (2020)

#284

Post by webmaven »

dntrkv wrote: post #260
timw4mail wrote: post #242

Earlier quoted context omitted.

I've never had the second scenario feel faster.

Cool, well the metrics tell a different story.

There is a difference between 'feels faster' and 'gets users to stick around until the page finishes loading'.

The latter is an observation that can be corroborated by analytics.

The former is more of a plausible 'just so' story that may or may not be a valid/good/falsifiable/defensible explanation for the latter.

Re: Second-guessing the modern web (2020)

#285

Post by disjoinder »

catlifeonmars wrote: post #281
disjoinder wrote: post #278

Earlier quoted context omitted.

"prior art" Are you suggesting GraphQL is novel and non-obvious? The term "prior art" of course comes from the patent law. Are you suggesting that the term "prior art" does not imply any relation (as in "relate to")? If so, that's false.

I made no such suggestions. I was suggesting that it’s certainly plausible that QBE influenced aspects of GraphQL. The “prior art” being QBE, not GraphQL.

Were you suggesting that GraphQL is a homoiconic language?

In QBE the request resembles the response.

Re: Second-guessing the modern web (2020)

#286

Post by noisem4ker »

webmaven wrote: post #140
scrollaway wrote: post #63

Earlier quoted context omitted.

It's absolutely possible, dare I say easy, to do old school SSR wrong. You start with an honest to god html file. Your IDE lints it. You are happy, life is easy. Then you need a second page. So you copy some things over. Then you need a third page, and it becomes apparent that you need a way to share parts of your html pages across multiple files, in a generic way. And kids, that's the story of how I met your templat…

> And kids, that's the story of how I met your templating system. > ALL of them suck. ALL of them are incredibly hard to lint, test, get right. They scale badly. They're all awful. That's not really true. But fairly incredibly, it seems relatively little attention has been given to the design of HTML templating languages (certainly there are a lot of them, but most seem to have accreted rather than been designed). An…

Thymeleaf templates are also valid HTML when not rendered. Of course you still have to put some thought into them to make them believable, by e.g. providing placeholders for elements that would be rendered in cycles.

Yeah, I find Thymeleaf to be nice, especially when coupled with Spring. I'm always happy when we decide to use it instead of bloating everything up with a separate Angular application.

Re: Second-guessing the modern web (2020)

#287

Post by noisem4ker »

Raed667 wrote: post #45
cmckn wrote: post #35

Earlier quoted context omitted.

> gray boxes simulating text This is one of the worst UI trends in the last decade. Mock content gives devs permission to ship slow APIs, and they can even look janky when your API is too fast. It feels like watching a half hour of trailers before the movie starts.

You want to know why they exist? Because of Google Core Web Vitals metrics! CLS (Cumulative Layout Shift) can go to zero if you place proper skeletons. I still prefer it to content jumping around when the API response is done.

Well, they definitely don't solve the problem for the user, as the grey boxes inevitably aren't the same shape as the content that eventually appears, and the jumping around is still there. Text fields are often variable length and can reflow. Buttons are also frequently dynamic, and all sorts of widgets may not just line up. Sometimes, incomprehensive design changes cause further disalignment between the skeleton and the actual content.

It's sad and funny that the YouTube app seems to have just recently jumped on this bandwagon (either that, or the situation worsened so much that I started noticing how bad it is).

Re: Second-guessing the modern web (2020)

#288

Post by Raed667 »

noisem4ker wrote: post #287
Raed667 wrote: post #45

Earlier quoted context omitted.

You want to know why they exist? Because of Google Core Web Vitals metrics! CLS (Cumulative Layout Shift) can go to zero if you place proper skeletons. I still prefer it to content jumping around when the API response is done.

Well, they definitely don't solve the problem for the user, as the grey boxes inevitably aren't the same shape as the content that eventually appears, and the jumping around is still there. Text fields are often variable length and can reflow. Buttons are also frequently dynamic, and all sorts of widgets may not just line up. Sometimes, incomprehensive design changes cause further disalignment between the skeleton an…

I agree with you that snapping some skeletons on a UI and calling it a day won't help the user

This is why I sneaked this part in:

> if you place proper skeletons

I had to work on this recently and unless you take the design constraints seriously you will eventually end up in the situation you described.

Re: Second-guessing the modern web (2020)

#289

Post by phist_mcgee »

darkhorse13 wrote: post #251
phist_mcgee wrote: post #216

Earlier quoted context omitted.

Good you have found your niche, and it's great that you haven't overextended yourself when it comes to delivering value to customers. I would say though that your work is a subset of web dev, and while totally valid in that area, I don't think it applies as concretely to other domains, particularly those with larger audiences, or those with needs for greater reactivity.

Sorry, but this is just plain bollocks. Some of the most popular websites run on Rails/PHP/Django, and they are not "reactive" SPAs.

Are you disagreeing with my assertion that the above poster's view is a bit too narrow in its application? I know a lot of sites run rails/php/django, but that does not mean that they are the majority, or even part of a minority that are the 'most' succesful.

Re: Second-guessing the modern web (2020)

#290

Post by phist_mcgee »

rimliu wrote: post #230
dntrkv wrote: post #177

Earlier quoted context omitted.

> Here's a user, telling you that I'm sick of lag from weird multistage loads in apps that gain nothing from keeping local state in browser JavaScript variables. You do realize the alternative is the same amount (or more) of waiting with a blank screen, right? > Or compare the absolute shit-show of new Reddit in an SPA to old Reddit. You are conflating bad design / UX with SPAs. You can build a SPA that is exactly th…

> You are conflating bad design / UX with SPAs. Not really. Bad UX is what is really synonymous with SPAs.

A wildly erroneous assertion, and one that is backed up with zero facts on your part.
Post reply on HN