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

Go Static or Go Home

queue.acm.org

Post reply on HN
Print view View original

21–30 of 106 posts

Re: Go Static or Go Home

#21

Post by andrewstuart2 »

normloman wrote: post #18

I'm not concerned if a web app or a shopping cart is dynamic. But I see dynamic blogs all the time. Blogs with no comment system, or one that's used infrequently. What's the point of making that dynamic? While I'm on the subject, can anyone tell me the reasoning behind loading blog content with javascript? I hate when I visit a blog with no script turn on, and get greeted by a blank template. Why does it need javascr…

One word: caching.

The more resources you can cache fully (like the template) the fewer round trips you need to make and/or the shorter those round trips become. It's always the latency that slows us down (by definition), which is why even modern processors have sophisticated cache layers and branch prediction. The further from the CPU the resource is, the slower the interaction will be.

This debate is interesting and a bit funny to me because it's very similar to the old dumb terminal vs personal computer debate. We've swung back to the mainframe, except now it's distributed and we call it the cloud.

My prediction (take it or leave it) is that we'll soon be swung all the way back to dynamic client-side sites. And then eventually back to the quantum cloud (heh, "Electron Cloud"). Or something new and more powerful than whatever sits in our pocket or on our desk.

Re: Go Static or Go Home

#22

Post by Retric »

jamiesonbecker wrote: post #17
netaustin wrote: post #13

High traffic and high volume sites driven by CMSes, like newspapers, tv stations, etc., largely cannot rely on static files to deliver their content. Rather, they use caching layers for speed and security. There are two better ways to improve security for sites like these, which are highly targeted and poor candidates for static sites: 1) Use a headless CMS. WordPress on the backend that provides and API which is con…

It's simply a matter of inversion. Is the page generation and publication performed upon each change (by editors/authors/etc) or upon each access? Obviously, the former is much more efficient, even for frequent changes, and even across millions of data points. (Just ask Twitter). Just because we don't really have common, enterprise-grade authoring tools for non-technical people that publish static sites anymore doesn…

Sure we do, it's called caching.

There is a minimal difference between a webserver serving static pages and a caching server serving static content. When you get down to it caching is simply a more flexable approach to the classic (autoring tool) -> static webpage approach. In many ways the only difference is the authoring tool is a website not a stand alone program.

Re: Go Static or Go Home

#23

Post by normloman »

andrewstuart2 wrote: post #21
normloman wrote: post #18

I'm not concerned if a web app or a shopping cart is dynamic. But I see dynamic blogs all the time. Blogs with no comment system, or one that's used infrequently. What's the point of making that dynamic? While I'm on the subject, can anyone tell me the reasoning behind loading blog content with javascript? I hate when I visit a blog with no script turn on, and get greeted by a blank template. Why does it need javascr…

One word: caching. The more resources you can cache fully (like the template) the fewer round trips you need to make and/or the shorter those round trips become. It's always the latency that slows us down (by definition), which is why even modern processors have sophisticated cache layers and branch prediction. The further from the CPU the resource is, the slower the interaction will be. This debate is interesting an…

Thanks for answering my question. Would you mind clarifying it for me?

If your blog has a reusable template, wouldn't the images, fonts, and stylesheets that are part of the template get cached on the user's computer, regardless of whether it was dynamic or static?

Or are you talking about caching things serverside?

Re: Go Static or Go Home

#24

Post by icebraining »

Retric wrote: post #22
jamiesonbecker wrote: post #17

Earlier quoted context omitted.

It's simply a matter of inversion. Is the page generation and publication performed upon each change (by editors/authors/etc) or upon each access? Obviously, the former is much more efficient, even for frequent changes, and even across millions of data points. (Just ask Twitter). Just because we don't really have common, enterprise-grade authoring tools for non-technical people that publish static sites anymore doesn…

Sure we do, it's called caching. There is a minimal difference between a webserver serving static pages and a caching server serving static content. When you get down to it caching is simply a more flexable approach to the classic (autoring tool) -> static webpage approach. In many ways the only difference is the authoring tool is a website not a stand alone program.

Caching is usually done on demand, though, not ahead of time. That means the dynamic portion is still launched by the request, which increases the probability of security flaws being exploited.

Re: Go Static or Go Home

#25

Post by Diederich »

jkot wrote: post #20
andrewstuart2 wrote: post #14

A castle with no gate is also more secure. And kind of useless for its inhabitants. Like being under siege all the time. My point being, sure you can get a more secure `something` by making it more and more static, but you'll probably cripple it somehow. It's simply a balance you have to find for your use case.

There are castles with no gates. I think problem is that current dynamic websites are sort of crippled already. Right now even simple shopping app requires UI based on HTML + web. Not a chance to use command line, some automated devices etc... In future we might see radically simplified protocols/webservices for more universal access.

I hear what you're saying, but it doesn't have to be so.

All of the web apps I make at work are all javascript in a page apps. But before I start doing any of that, I make a REST API. 100% of the interaction between javascript and the web server is REST.

There are many reasons for this, but a key one is that it allows easy command-line or programatic interaction. Much easier than with traditional, server generated web apps.

Re: Go Static or Go Home

#26

Post by jordanlev »

normloman wrote: post #18

I'm not concerned if a web app or a shopping cart is dynamic. But I see dynamic blogs all the time. Blogs with no comment system, or one that's used infrequently. What's the point of making that dynamic? While I'm on the subject, can anyone tell me the reasoning behind loading blog content with javascript? I hate when I visit a blog with no script turn on, and get greeted by a blank template. Why does it need javascr…

The point of making a blog dynamic is so a non-technical user can easily manage the content via a dashboard. I'm a big fan of static site generators (which is what I presume you're inferring people should use for blogs instead of wordpress et al), but it is silly to think that uploading markdown files to a server is a reasonable workflow for most non-programmers.

As for loading content with javascript -- I totally agree, this bugs the shit out of me. Also, I browse with cookies disabled by default and it is always frustrating when a site that is only serving content doesn't load properly without cookies. wtf?!

Re: Go Static or Go Home

#27

Post by normloman »

jordanlev wrote: post #26
normloman wrote: post #18

I'm not concerned if a web app or a shopping cart is dynamic. But I see dynamic blogs all the time. Blogs with no comment system, or one that's used infrequently. What's the point of making that dynamic? While I'm on the subject, can anyone tell me the reasoning behind loading blog content with javascript? I hate when I visit a blog with no script turn on, and get greeted by a blank template. Why does it need javascr…

The point of making a blog dynamic is so a non-technical user can easily manage the content via a dashboard. I'm a big fan of static site generators (which is what I presume you're inferring people should use for blogs instead of wordpress et al), but it is silly to think that uploading markdown files to a server is a reasonable workflow for most non-programmers. As for loading content with javascript -- I totally ag…

I'm not advocating static page generators that use markdown. Far from it. I used to use a blog platform called Movable Type. It was just as easy to use as WordPress but it generated static pages. You'd make changes in the back end, click publish, and Movable Type would generate a new static page to serve up.

You can make WordPress generate static pages too. They have plugins for that.

Re: Go Static or Go Home

#28

Post by jamiesonbecker »

icebraining wrote: post #24
Retric wrote: post #22

Earlier quoted context omitted.

Sure we do, it's called caching. There is a minimal difference between a webserver serving static pages and a caching server serving static content. When you get down to it caching is simply a more flexable approach to the classic (autoring tool) -> static webpage approach. In many ways the only difference is the authoring tool is a website not a stand alone program.

Caching is usually done on demand, though, not ahead of time. That means the dynamic portion is still launched by the request, which increases the probability of security flaws being exploited.

Exactly.

In other words, some fraction of the requests are responded to dynamically and then the result is cached. That dynamic nature can be exploited. Site search engines, etc, are also often (but not always) dynamic, server-generated results that have a greater likelihood of exploits via XSS, CSRF, SQL Injection, etc. Login forms almost always require server interaction and are great targets.

(I say "almost" because REST interactions might be stateless and thus login forms really just serve to generate an access token and verify that it's working; this is how Userify works, for instance. It's still theoretically more exploitable than pure static files, but it raises the bar quite a bit.)

Re: Go Static or Go Home

#29

Post by k__ »

Also, in times of SPAs, LocalStorage, WebRTC, Parse and FireBase you can sprinkle your static web-sites with some dynamic functionality, when needed...

Re: Go Static or Go Home

#30

Post by gizzlon »

Ok, I understand that there's reasons for using static pages, but I don't get the feeling this guy really understands what he's talking about.

> Even if [..] and there's nothing like bash installed on the same computer as the web server

Bash installed? Huh? Why Bash exactly? I feel mentioning jails or containers here would be more on point..

> This is because every DCMS page view involves running a few tiny bits of software on your web server, rather than just returning the contents of some files that were generated earlier.

Sure, but guess how those pages are returned? By running code on the server..

It seems like hes real beef is with "dynamic" (vs staic) sites, but he keeps mentioning CMS's for some reasons (ike you can't can have "dynamic" sites witjout a cms)

> The web server executes no code on behalf of a viewer until that viewer has logged in..

1) Of course it does, 2) How do the site check your info without executing code? :)

etc etc..

There's a case for static sites, but this post just confuses things.

Post reply on HN