Static Website Generators Are the Next Big Thing • Hacker News Board

Re: Static Website Generators Are the Next Big Thing

#181

Post by xrayspec » Wed, Nov 04, 2015, 2:37 AM UTC

davexunit wrote: post #111

Tomte wrote: post #99

Earlier quoted context omitted.

Have you had a look at Pollen, by Matthew Butterick?

Yes. I like Butterick's "Practical Typography" a lot, and the rationale behind using Racket. That said, I don't actually like Pollen because it's just a string-based templating system. Instead, I want to use something that is based around s-expressions. My static site generator, Haunt, works with SXML trees instead of raw strings which is much nicer to work with.

> just a string-based templating system

Not sure what you mean. Pollen is derived from Racket's text-based DSL, Scribble. Like Scribble, Pollen lets you embed Racket-style S-expressions in your documents. Moreover, Pollen documents compile into X-expressions (= the Racket equivalent of SXML).

Re: Static Website Generators Are the Next Big Thing

#182

Post by duskwuff » Wed, Nov 04, 2015, 3:25 AM UTC

vinceguidry wrote: post #167

Domenic_S wrote: post #162

Earlier quoted context omitted.

Couldn't disagree more. CMSs enable non-developers to publish good-looking content, which is basically what the web is. You can have a small army of 10-20 writers and 1-2 front end devs styling templates for them. It scales, and it makes sense. Content is certainly not code; it does not get compiled, it contains no logic. At best content is a property of an object with its structure defined in/as code.

> CMSs enable non-developers to publish good-looking content, which is basically what the web is. You can have a small army of 10-20 writers and 1-2 front end devs styling templates for them. It scales, and it makes sense. Assuming that the content you're publishing is primarily writing, then yes, that makes sense. But most companies on the web are not primarily blogs or news. Hell, even the way news is going, a lot…

The article you're thinking of was "Snow Fall".

http://www.nytimes.com/projects/2012/snow-fall/

Re: Static Website Generators Are the Next Big Thing

#183

Post by halostatue » Wed, Nov 04, 2015, 4:56 AM UTC

antimagic wrote: post #66

spjwebster wrote: post #28

Every time static generation rears its head, I'm reminded of Yahoo!'s ... unique... take. Back in 2006 when I worked for Yahoo!, and they had a CMS / template management system called Jake that statically generated templates for the PHP-based frontend servers to evaluate at request time. The idea was that you put as much of your logic as possible into the template generation layer, leaving the request-time logic to h…

Yup, sounds a bit like a project I did a while back - I had a C/C++ bindings generator that took an XML file and generated the C/C++ code to expose a C/C++ class to Javascript. So of course the logical thing for me to do was write the thing in Ruby. That said, all code-generation tools - straight up generators, compilers, whatever - are a mindbending experience. Keeping track of whether a variable is available at gen…

My version of that was parsing generated C++ code headers through Doxygen (XML format) and then writing up a Ruby script that would spit out generated C++, C#, and Java to expose the SOAP APIs we needed to do. It was fun, and I think the company is still using it, four years after I left.

Re: Static Website Generators Are the Next Big Thing

#184

Post by CM30 » Wed, Nov 04, 2015, 7:42 AM UTC

SamBam wrote: post #150

CM30 wrote: post #124

It's an interesting idea, and I see the appeal if the site is fairly basic, but I think there's one thing people are forgetting here. You're outsourcing half your site to third parties, and basically letting them do whatever the hell they like with it. Disqus comments? Better hope the people behind that system don't decide to outlaw comments about the thing your website is about. Javascript embedded shop system? Good…

Personally, I generally trust a third-party's shop system significantly more than I do something homegrown for a typical small business. Credit card security is hard . Why force everyone to reinvent the wheel?

Most card details are stored by payment processors, not your own server or a third party shop provider's servers. Paypal and Stripe and various others are probably more trustworthy than anything that stores the details with the shop itself.

But that doesn't really apply to a lot of things. Comments for example, do you really trust a third party more with those? Because if your site is in a grey area, then it's very possible their terms/country/whatever might require them to ban discussion of the topic. Self hosted means your rules, not a large corporation's.

Besides, any middleman is the weakest part of the chain if someone wanted to shut down a site or significantly cripple it without going through a court case. You may like controversy, but a large company would rather see the back of anyone that might potentially hurt its public image. We already see issues where internet mobs go after hosting companies and providers based on something someone said on Twitter. Every third party service is yet another potential target for them, and one that could buckle even more easily than the hosting company (especially if you're not paying for their services).

Re: Static Website Generators Are the Next Big Thing

#185

Post by z3t4 » Wed, Nov 04, 2015, 8:04 AM UTC

ChristianBach wrote: post #176

z3t4 wrote: post #157

Earlier quoted context omitted.

I think CDN is over-kill/hype. If you do everything right, all you get is better latency. If your dynamic site loads slower then a static site, you are probably doing needless database round-trips, redirects, synchronized writes, or html rendering.

Yeah, caching HTML directly on a CDN basically only gives you better latency. ..Which in turn gives you better page rank. ..Which gives you more traffic. But that's it. ..Well besides that it also gives you lower bounce-rate. ..Which means higher conversion. ..Which means higher ROI. So there's that. :-)

That is best case scenario ... But probably a premature optimization. You also have to look at time to first byte, total time, and client rendering time.

If it takes like ten seconds to render the site on the client, then 10ms gain on connection time wont help much.

Test tool: http://www.webpagetest.org/video/

When all css, fonts etc are cached on the browser client, then there's almost no gain with CDN.

Re: Static Website Generators Are the Next Big Thing

#186

Post by jarnix » Wed, Nov 04, 2015, 5:46 PM UTC

jedberg wrote: post #108

When I was heading up reliability at Netflix, we considered, and even began evaluating, turing the whole thing into one big static site. Each user had a custom listing, but generating 60+ million static sites is a very parallelizeable problem. At the time, the recommendations only updated once a day, but an active user would have to dynamically load that content repeatedly, and at the same time, the recs were getting…

"turing the whole thing", Alan should be flattered.

Re: Static Website Generators Are the Next Big Thing

#187

Post by LinuxBender » Wed, Nov 04, 2015, 7:19 PM UTC

I have been doing this since 1998 with perl and cron for my own systems and I can say it works great. Combine that with a ram disk and I can handle the load with a couple small machines that would typically require a big farm using dynamic content for everything.