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

71–80 of 106 posts

Re: Go Static or Go Home

#71

Post by jordanlev »

normloman wrote: post #27
jordanlev wrote: post #26

Earlier quoted context omitted.

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.

ahh, I see what you mean. Yeah, if you don't have comments or other interactive functionality then generating static pages from your data + templates is great.

That being said, in my experience, most sites have at least some interactivity... even if the primary content isn't. Comments are still pretty standard on most blogs (disqus can be an option, but now you're back to the "why does this require javascript when it doesn't really need to?" problem). Surveys and polls have fallen out of fashion (fortunately), but that's another example. Also, contact forms are a big one (and yeah, there are other options like embedding wufoo or using a form-handling service like Brace Forms, but now we're talking about off-loading a lot of functionality to other services).

As a developer, there are a lot of things about wordpress that I don't like... but I cannot argue that for someone who is not a programmer but likes to tinker, it gives you a ton of functionality out-of-the-box or with plugins. It's the last thing I'd want to use personally, but I think this is the appeal of dynamic sites -- it gives you the flexibility to add all sorts of unrelated crap really easily.

Re: Go Static or Go Home

#72

Post by klibertp »

Xorlev wrote: post #39
normloman wrote: post #23

Earlier quoted context omitted.

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?

I think he means that you can cache the majority of the page (including the HTML template) and then substitute in just the data (usually coming from JSON). I don't buy that it's more efficient personally. I'd rather resend a lightweight page on every time then force the browser to download it all, load the JS, then build a page and have the browser draw that. It seems to me that single-page apps are great when you ar…

There's one technology, available everywhere including most toasters, which allows you to do this (cache HTML template and just substitute the data) and it can work on both back- and frontend with no problems, is crazy fast and even leaves you with something readable when it breaks.

It's called XML with XSLT.

Somehow it isn't very popular. But hey, we got this idea of "rendering pages on the backend or the frontend (or both)" from the same code lately!

Re: Go Static or Go Home

#73

Post by mcguire »

anth1y wrote: post #31
gizzlon wrote: post #30

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 s…

> 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. I think he might know a little bit: http://en.wikipedia.org/wiki/Paul_Vixie

Which is what makes the article so peculiar. He's either being exceptionally sloppy or...I don't know what the other options are.

Re: Go Static or Go Home

#74

Post by MaulingMonkey »

thegeomaster wrote: post #63
StefanKarpinski wrote: post #47

Earlier quoted context omitted.

I was talking about which is more secure. The real point is that this isn't a static vs. dynamic language issue: C and C++ are static and full of terrifying security traps; Haskell is static and it isn't. Since C and C++ are the most commonly used static languages, and they are much less secure than the most commonly used dynamic languages, it's questionable to claim – without additional elaboration – that static is…

C++, especially when using features provided by the newest standards (C++11 and C++14), cannot be likened to C in terms of security problems. In theory, yes, it's backward compatible with C so any security issues present in C can be reconstructed in C++, but using managed pointers, standard containers, RTTI and other features can considerably reduce the attack surface... but I'd argue that not a great amount of appli…

> using [...modern C++ features...] can considerably reduce the attack surface...

I'd argue the remaining attack surface is still wide enough to drive a shuttle crawler-transporter through. Even if your core code is perfectly tricked out with best practices, you're going to inter-operate with 3rd party APIs with C style interfaces at some point - and that means raw pointers, rolling your own containers / RAII wrappers, etc.

Re: Go Static or Go Home

#75

Post by feld »

tptacek wrote: post #42
feld wrote: post #36

Earlier quoted context omitted.

Go outside and get some fresh air.

I generally like your comments and this one is out place for you. What were you actually trying to say?

He's trying to pick on Paul Vixie for such a irrelevant detail. The fact that he had to mention it to boost his ego makes the rest of his post not worth reading.

edit: I also enjoy the reaction of HN readers. It's fun. People take this site too seriously.

Re: Go Static or Go Home

#76

Post by juliangregorian »

betenoire wrote: post #58
bnegreve wrote: post #37

Earlier quoted context omitted.

On the other hand, I don't really get your point. > Sure, but guess how those pages are returned? By running code on the server.. Yes, but by running static code. > > 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? :) Again, static code. So his point is not that we shouldn't run code at all, but…

> of course you can argue [that] no code is truly static what the hell is static code? Static has very specific meanings in different technical contexts (static pages, static allocation, static scoping, etc), but I've never heard someone refer to static code. Can you give me an example of code that is and isn't static by your definition?

My understanding was that it referred to static vs dynamic linking. Since self-updating code is an attack vector.

Re: Go Static or Go Home

#77

Post by bnegreve »

betenoire wrote: post #58
bnegreve wrote: post #37

Earlier quoted context omitted.

On the other hand, I don't really get your point. > Sure, but guess how those pages are returned? By running code on the server.. Yes, but by running static code. > > 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? :) Again, static code. So his point is not that we shouldn't run code at all, but…

> of course you can argue [that] no code is truly static what the hell is static code? Static has very specific meanings in different technical contexts (static pages, static allocation, static scoping, etc), but I've never heard someone refer to static code. Can you give me an example of code that is and isn't static by your definition?

Dynamicity usually refers to the fact that you can execute code that wasn't fully specified at runtime.

Lisp code is the stereotypical example of a dynamic programming language because it can update its own code while being executed.

On the other hand, compiled C code is static because the code is loaded into memory and cannot be changed during the execution (as a matter of fact, the memory pages holding the code don't have even have write permissions). Btw, you can make it more dynamic by enabling dynamic libraries or modules which make the whole thing less secure.

In a static program, you can only execute code that was originally provided (at least in theory), that makes it harder to accidentally execute a piece of code provided by the user as input.

Back to our problem: A dynamic website will typically take user input (e.g. the user name) and build a personalized view of the webpage for the user. To achieve this, the page will probably contain a SQL query with a 'name' field. If the inputs are not properly sanitized, the field can contain anything including SQL code. If the user is malicious, you have a SQL injection (i.e. the user can execute an arbitrary query). What happened is that you've executed code provided by the user.

Re: Go Static or Go Home

#78

Post by tptacek »

feld wrote: post #75
tptacek wrote: post #42

Earlier quoted context omitted.

I generally like your comments and this one is out place for you. What were you actually trying to say?

He's trying to pick on Paul Vixie for such a irrelevant detail. The fact that he had to mention it to boost his ego makes the rest of his post not worth reading. edit: I also enjoy the reaction of HN readers. It's fun. People take this site too seriously.

Did you think Vixie's post was insightful or useful?

Re: Go Static or Go Home

#79

Post by feld »

tptacek wrote: post #78
feld wrote: post #75

Earlier quoted context omitted.

He's trying to pick on Paul Vixie for such a irrelevant detail. The fact that he had to mention it to boost his ego makes the rest of his post not worth reading. edit: I also enjoy the reaction of HN readers. It's fun. People take this site too seriously.

Did you think Vixie's post was insightful or useful?

Absolutely; he's right. You should not mix data and code. That's the reason why my own site(s) are all static, and my website does not look like it's from 1993. (just kidding, it does intentionally, but my blog is Pelican)

You can still write a static site that talks to a database and can accept form input for users to login and do things. It's not impossible. There's no reason to require every page view to be dynamically generated. We invented countless types of caching software to make dynamic sites as static as possible! Why is it illogical to rip out the dynamic piece altogether and use a static site generator for (nearly) everything? Why does every page view have to hit a language interpreter or virtual machine? It doesn't!

It shouldn't!

Do people believe that websites can't use databases without being dynamic? That's the only explanation I have here.

edit: I have seen the other end of the spectrum -- a 10 million line PL/SQL CMS that dynamically generates the entire website -- HTML, JS, CSS -- from an Oracle database. Even the static content was in the database as blobs! Everything served through the Oracle Application Server (Apache with mod_plsql or mod_owa, which rarely got updates) and had no chance of scaling well. But people paid out the ass to license it!

Re: Go Static or Go Home

#80

Post by jerf »

yk wrote: post #48
StefanKarpinski wrote: post #33

"Little Johnny Tables". Um, yes, that was "Little Bobby Tables" [1]. Obviously not a big deal, but it seems emblematic of how sloppy this piece is. The article confuses – seemingly willfully, since Paul Vixie should know better – the concepts of dynamic language, dynamic page generation, lack of proper input hygiene, and various other orthogonal issues. The argument that dynamic languages are less secure depends an a…

Calling any Turing complete language "more secure" is probably nonsense. It is possible to write secure applications in C, and it is possible to directly pipe attacker controlled input to a shell in Haskell.

"Calling any Turing complete language "more secure" is probably nonsense."

I just wrote an article on a sensible metric by which you can do exactly that: http://www.jerf.org/iri/post/2942

A lot of people already knew that stuff on one level or another anyhow, but it's helpful to spell it out sometimes and bring subconscious feelings up to the conscious level.

Post reply on HN