Live data from Hacker News

Go Static or Go Home

queue.acm.org

31–40 of 106 posts

Re: Go Static or Go Home

#31
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

Re: Go Static or Go Home

#32
post #31
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

None of the things on that wikipedia page makes me think he actually knows anything about web servers. Sure, he obviously should know about some of the things that make the internet work (BIND, cron, etc) but nothing on there has anything to do with making web sites. All of it is about the infrastructure.

Either this article is filled with intentional hyperbole, or this guy doesn't know what he's talking about when it comes to serving web pages.

Re: Go Static or Go Home

#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 awful lot on the language – I don't think anyone is going to buy that C is more secure than Python. Haskell vs Python? Now that's a debate to be had. Certainly, websites that do no dynamic content generation are probably more secure – but then you're stuck with the Internet circa 1993. And of course, nobody is in favor not sanitizing inputs properly.

[1] http://xkcd.com/327/

Re: Go Static or Go Home

#34

I've been an evangelist of static sites for a while. With over 15 yrs of experience doing sites I started in static and saw the "dynamic movement" born and grow (at some point I even programmed my own DCMS!); in most cases the motivation to install a DCMS was that the client wanted to update content in-house instead of paying a webmaster (a sound business idea?) but the reality is that even when using a dead simple D…

The best mix may be a (hosted) dynamic editor that generates and deploys the static site. Have you considered this solution? It probably won't eliminate the need for a webmaster, but it should help reduce the requests for small changes while keeping the benefits of the static site.

I agree, this way seems the best. The reason people like WordPress so much is because it abstracts away everything except writing content. Users don't care how the site is served (and most nontechnical users won't even know).

Re: Go Static or Go Home

#35
post #20

Earlier quoted context omitted.

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

Same here. Increasingly products I work on do almost no server side templating; frontend templates call REST services that I can test with curl, postman, or other tools.

Re: Go Static or Go Home

#36

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

Go outside and get some fresh air.

Re: Go Static or Go Home

#37
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…

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 that we shouldn't run code that heavily processes user inputs, or worse, evaluate generated code as DCMSs sometimes do.

Of course you can argue the no code is truly static, because it depends on the user input, but I don't think this is what you're arguing here.

Re: Go Static or Go Home

#38

Earlier quoted context omitted.

The idea is not that everything need to be static - some contents are by nature updated too fast, or too often, to be static. Still, there's lot of page that could be pre generated since the content of the datastore itself is not evolving a lot. Most blog could use a static blog generator for example, with the comment being the only dynamic part - and a lot of cms page too ! Pre baking stuff is so much easier, faster…

True. My personal site is static (generated with Hakyll), and uses Disqus for comments (only because I haven't yet seen a simple, self-hosted alternative which has been battle-tested).

I work on a statically generated site in which the comment form simply feeds back into the generation workflow. It's certainly not 'battle tested', but it has the advantage that a) we get to own the comments rather than giving them to someone else b) everyone can partake in the discussion c) much less demand on the client when rendering

Re: Go Static or Go Home

#39

Earlier quoted context omitted.

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?

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 aren't leaving the page and have a lot of navigation, but overkill for a blog.

I am rather interested in react+react-router though. That seems like the best of both worlds -- render serverside, then render deltas clientside.

Re: Go Static or Go Home

#40

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.

Six Apart's MovableType is still around.

https://movabletype.org

Post reply on HN