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

131–140 of 309 posts

Re: Second-guessing the modern web (2020)

#131

Post by tshaddox »

hmsimha wrote: post #127
tshaddox wrote: post #108

Earlier quoted context omitted.

If you click on an tag before the JavaScript has loaded and React has hydrated, the browser will do a full page load of the URL that you clicked on. Assuming that new page is also rendered on the server, it should work fine and feel just as good as if it was a traditional server-rendered HTML web site or if you had JavaScript turned off. (Of course, things that do require JavaScript for interactivity, like custom too…

Just to add to the above, this is specifically when your pages are server-side rendered. Hydration is a concept of taking a server-rendered page and making it interactive with Javascript. You can have your NextJS/React app server-rendered, and then users visiting a page will get the page. Clicking links within the application will use Javascript routing to load the part of the application that needs to be displayed (…

> Is it common to use non-next React for SSR?

I believe so. I've encountered it used in several projects longer before Next.js (or at least before Next.js was so popular). The basic idea is really simple, on the server you just ReactDOMServer.renderToString() in Node and respond with the HTML string.

Of course, the devil is in the details. You probably need some conventions for statically determining what data needs to be loaded based on the URL (before you renderToString), some way of passing that global data to the client for React hydration, perhaps some API client that can handle making requests from both the client and the server, some system for handling HTML-specific concerns like meta tags and cache-control headers, etc. Frameworks like Next.js presumably make all these decisions for you!

Re: Second-guessing the modern web (2020)

#132

Post by madelyn »

tshaddox wrote: post #117
nemothekid wrote: post #24

One thing I've seen happen again and again in a lot of technologies is a "framework gravity". A lot of people see this as engineers just wanting to work on "hype" technology but I think what is actually happening is a reflection of global engineering time. React is great for SPAs. Most large companies are working on honest-to-god SPAs. By extension most engineers are working on SPAs. So most tooling is created for SP…

Another big issue is the ability to seamless transition parts of your software between different programming models. We just don't have good solutions to this that I know of. The thing with SPAs is that you are probably worse off starting with a traditional server-rendered HTML web site and slowly introducing more and more interactivity, unless you know you won't eventually be better off with an SPA at the foundation…

React can work really nicely with different parts of the DOM via Portals however!!

Portals are awesome for use cases where you're sprinkling dynamic bits into an SSR'd shell. And for all parts of your app that don't need that level of interactivity, you've got plain old templates in your server side language of choice.

There's some limits to this but it's a neat trick.

Re: Second-guessing the modern web (2020)

#133

Post by habibur »

h0l0cube wrote: post #120
scrollaway wrote: post #109

Earlier quoted context omitted.

This is only sometimes true. Other times, cutting the server rendering makes things a million times easier because maybe you're not contacting your database, or you're offloading large per-user objects to the client instead of keeping them in ram for thousands of uniques per minute, or, or ... Some calculations are less heavy on the client side. It's not building the html itself once you know what you need that is he…

> because maybe you're not contacting your database Except you will anyway, to do all those API queries you need to fill the page. That involves multiple handshakes back the server, and yet more server-side resources tied up. > or you're offloading large per-user objects to the client This access happens either way, and will be discarded in short order by any cache, even using the most naive LRU policy.

Basically it boils down to storing state per client. Would you rest the bulk part of it on the server, or on the client?

In the initial days of the web, it was stored on server. But before that, in desktop application era it was stored on client.

Re: Second-guessing the modern web (2020)

#134

Post by arsome »

7thaccount wrote: post #128
arsome wrote: post #50

Earlier quoted context omitted.

Yep. We recently did an assessment of available UI libraries and pretty much concluded the best maintained libraries with a modern look and feel are all web-focused and we're likely to have to settle for building an electron app if we want to be able to take advantage of the best selection of 3rd party libraries without building as much ourselves. As much as I don't like the ecosystem or Javascript as a language, the…

If you're building a desktop app, just plain C# in visual studio has an extremely powerful GUI (WinForms) that is fairly easy to use. Lots of widgets abs very good charts and graphs that you can zoom-in on and annotate in a million ways. It's miles ahead of Python (saying this as a Python guy). Click Once means installs are fairly simple (assuming a Windows deployment).

That's true, but it seems like WinForms is basically a dead end at this point, not much maintenance work is put into it and you have to jump through some serious hoops to make basic stuff like DPI scaling work even last I checked. Completely agree though, the 3rd party component story is very good on .NET, but the applications you're producing don't exactly have a modern look and feel unless you're investing serious UI design effort in them on top of things.

WPF (and whatever they've taken to calling the UWP version of it now) is a little more modern, and it's what I was initially leaning towards, but also doesn't seem to be moving much and it feels like the future is very unclear, while even MS themselves have started putting out Electron apps. It really doesn't breed confidence.

Re: Second-guessing the modern web (2020)

#135

Post by cknoxrun »

FailMore wrote: post #46

How is Ruby on Rails viewed in this context? With some of the new magic ?

Even outside of SPA apps and new magic, Rails is still faster to develop a prototype or website in than React or dare I say any modern SPA tools.

We tested this for fun with some very experienced React and Rails devs at our company, each starting from a freshly formatted laptop to include the time it takes to get an environment up. Requirement was to create a simple blogging site with comments, authors, and tags (with some upfront design). Rails hands-down took the cake, by a large margin, each time.

It was for fun obviously, not exactly scientific, but was pretty eye opening seeing how much further ahead the Rails devs were at each step.

Re: Second-guessing the modern web (2020)

#136

Post by TrispusAttucks »

Spot on. There are cases for SPAs but there are also a lot of bad cases.

Just the other day there was a news article (don't remember which) here on HN. The entire page "shell" loaded but the content of the article did not.

Quick inspection and it appeared that the SSR page was loading fast but some SPA call that loads the data was underperforming terribly so it was blank.

Let that sink in... we're in the web, it's 2021, everything BUT the article content loaded. Talk about optimizing the wrong thing. We've all went crazy.

The gains are rarely worth the costs.

Re: Second-guessing the modern web (2020)

#137

Post by tekstar »

mathgladiator wrote: post #124
tekstar wrote: post #61

Earlier quoted context omitted.

Looks like you're trying to reinvent some wheels there. No harm in doing so but just so you know, React (or my preference, a tinier version called Preact) would let you update new chat contents without blowing away all the other InnerHTML content. The way you're doing it now will result in a flicker, and mess with things like highlighted text will unhighlighted when replaced. And that's just with the basic dumping of…

Wait til I tell you about the custom UI system I'm building with canvas. http://www.adama-lang.org/blog/ui-flow-with-adama

Nice blog post! I read the whole thing. I'm working on something with multiplayer using an unbounded queue of command events, so I learnt a few things about that situation. If you have any posts that elaborate on the typical infrastructure events from running that in production, I'd love to read it as you obviously put a lot of effort into your blog posts.

Re: Second-guessing the modern web (2020)

#138

Post by least »

> Sure: traditional non-SPA websites are not immune to this pitfall. Someone might load your website, have a form open for many weeks, and then submit it after their session expired or the API changed. But that’s a much more limited exposure to failure than in the SPA case.

I don't really understand why this is a much more limited exposure to failure and he doesn't really elaborate why this is the case. It seems like the cause for failure in both cases are identical and the only reason that the SPA one would be a more likely scenario is simply due to the prevalence of SPAs, rather than any technical reason.

Overall I broadly agree with the article; that React is often wasted on webpages that simply don't need it. That a lot of technology that is plenty serviceable today is overlooked because it's not 'cool.' I actually think php is great (even though writing it isn't very fun to me) and it was one of my first introductions in creating dynamic webpages when I was a kid outside of some cgi scripts like NewsPro.

Vanilla javascript today is very robust but it's not exactly someone will end up writing a lot of unless they're going out of their way to do so. Web components might very well fit the needs someone might have for their website... but that doesn't really matter if you already know how to use components in React and you have to learn web components. There's a lot of momentum towards the known, especially when that known technology is valuable to employers.

Ultimately I think that while it's generally excessive, people gravitate towards what they're comfortable with and what makes their development life easier. Sure, this website may not require a React app, but it's something that I'm very familiar with and it's easy for me to create a website with it. It's easy for me to create interactive and dynamic elements in a system that is designed for that purpose. And the reward for having this knowledge is market value. This will always be a problem, regardless of what web technology is popular at any given moment.

Re: Second-guessing the modern web (2020)

#139

Post by nxc18 »

arsome wrote: post #134
7thaccount wrote: post #128

Earlier quoted context omitted.

If you're building a desktop app, just plain C# in visual studio has an extremely powerful GUI (WinForms) that is fairly easy to use. Lots of widgets abs very good charts and graphs that you can zoom-in on and annotate in a million ways. It's miles ahead of Python (saying this as a Python guy). Click Once means installs are fairly simple (assuming a Windows deployment).

That's true, but it seems like WinForms is basically a dead end at this point, not much maintenance work is put into it and you have to jump through some serious hoops to make basic stuff like DPI scaling work even last I checked. Completely agree though, the 3rd party component story is very good on .NET, but the applications you're producing don't exactly have a modern look and feel unless you're investing serious…

Coming off of an extremely disappointing Build - I don’t think any news even made it to HN this year, and not a peep about desktop - I agree that the future is unclear.

WinUI is the future, but they’ve admitted it will be years before it reaches the maturity of UWP, which is embarrassingly bad even 5 years on.

WPF, in my opinion, is the best choice for “native” windows apps. The actual best choice is Electron, as most teams doing new work at MS have noticed.

WPF, for native, hits the sweet spot of supporting newer technology (high DPI), having decent performance, and being well implemented; it has been solid for at least 10 years now. Also easy to style and theme, similar in concept to web, but just more annoying.

Re: Second-guessing the modern web (2020)

#140

Post by webmaven »

scrollaway wrote: post #63
ian1321 wrote: post #40

The amazing part to me is that SPAs are so much harder to do right compared to old-school server-side rendered HTML. One could be forgiven if they think a "simple" SPA is a good starter project, but they'd be very wrong. Async programming (Javascript Promises and/or async/await) is difficult, error-prone, and should be avoided whenever possible. On top of this, understanding how data flows through these SPAs is no sm…

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).

Anyway, the least weird templating language that was designed that I am aware of is the TAL[0] syntax, which has as it's main constraint that unrendered templates must still be valid HTML. The original motivation for this was to eliminate the terrible workflow problems of round-tripping templates between a web designer and a (backend) developer, but there turned out to be other benefits, like taking care of linting difficulties. It is also rather deliberately not Turing-complete, as that has proved an 'attractive nuisance' that causes more problems than it solves.

The TAL syntax is most strongly associated with Python frameworks (I would guess that Chameleon[1] is the most popular implementation), but there are implementations for most prominent languages[2].

> You know what's a robust API for building HTML that you already know, that is already supported by virtually everything? The DOM.

How popular is SSR in JS using the DOM directly, rather than a template language of some sort (eg. Handlebars, Jade, Nunjucks)?

[0] https://en.m.wikipedia.org/wiki/Template_Attribute_Language

[1] https://chameleon.readthedocs.io/en/latest/index.html

[2] implementations (sometimes several) exist for JS, Java, C#, Perl, Raku, PHP, Python, XSL, Go, and Common Lisp.

Post reply on HN