Live data from Hacker News

Go Static or Go Home

queue.acm.org

81–90 of 106 posts

Re: Go Static or Go Home

#81

Earlier quoted context omitted.

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.

Are there any downsides to this design?

Re: Go Static or Go Home

#82
post #79
post #78

Earlier quoted context omitted.

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

My site is static too. I had... uh... a bad experience with Wordpress about 7 years ago.

I think most competent professionals know that you should use static sites when you can get away with them. Look how many static site generators there are:

https://staticsitegenerators.net/

(You can also go look and find all the tools that will render a static site from a hidden Wordpress install).

To me, Vixie's take here is not very interesting, nor is it very useful. If you're the type of person to learn something from an ACM post, and you have a dynamic site, chances are it's dynamic because it needs to be.

But then I'm a little biased towards reading this article as a "get off my lawn" piece, and that's not very fair either.

Re: Go Static or Go Home

#83
post #57

Startup idea, free for the taking: create a service that "ossifies" dynamic websites into static HTML. (By ossify, I mean to take something dynamic and make it static). For example, that WordPress site you commissioned for a movie 3 years ago? Its a huge liability, but you don't have to take it offline - just ossify it. No one is updating that blog anymore! Under the hood, it would basically be a crawler, and the del…

This is already a product that exists many times over. Besides the aforementioned wget, I've recommended less technical users to SiteSucker, a Mac/iOS app.

I'd be happy to bill your clients to do it for them though!

Re: Go Static or Go Home

#84

Noob qn:how does custom search work on static sites? May not be the best approach, but a simple SQL query would do the trick for dynamic sites.

A simple SQL query is not a great solution even for dynamic sites that pull content from SQL databases. You have to protect against SQL injection and you usually will want fulltext indices for all the text fields to be searched. It's also going to be slow in the naive implementation for databases of any significant size.

The better solution for both dynamic and static sites is to set up a search appliance like elasticsearch, solr, or algolia. You can use JS to query it and still be static on the server.

If you do set up your own, remember to use a reverse proxy like nginx to avoid exposing elasticsearch directly to the internet.

Re: Go Static or Go Home

#85
post #57

Startup idea, free for the taking: create a service that "ossifies" dynamic websites into static HTML. (By ossify, I mean to take something dynamic and make it static). For example, that WordPress site you commissioned for a movie 3 years ago? Its a huge liability, but you don't have to take it offline - just ossify it. No one is updating that blog anymore! Under the hood, it would basically be a crawler, and the del…

This is already a product that exists many times over. Besides the aforementioned wget, I've recommended less technical users to SiteSucker, a Mac/iOS app. I'd be happy to bill your clients to do it for them though!

Here's the thing: they don't want to run SiteSucker. That's only slightly more helpful than telling them to just run wget!

They want to write a check and get back to business, not become a web developer!

(I think that tool is awesome though, and I appreciate the tip!)

Re: Go Static or Go Home

#86

Noob qn:how does custom search work on static sites? May not be the best approach, but a simple SQL query would do the trick for dynamic sites.

I used Google Site Search (https://www.google.com/work/search/products/gss.html), which starts at $100 per year. Outsource all that infrastructure to a company who's good at it, park your static HTML on a CDN, and enjoy fast worldwide access with searchable content.

That's not the only option, but it's a boss-friendly company to name drop. Most organizations wouldn't blink at the price, especially if it means you can move off dynamic hosting to far cheaper static hosting.

Re: Go Static or Go Home

#87
post #81

Earlier quoted context omitted.

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.

Are there any downsides to this design?

Not really, you can achieve this using a Rails (or rails-like thing like Play) very easily and use in their built CSRF, SSL, etc. but this type of design also makes it easy to build from scratch (which may lead you down the path of reinventing things).

SPA + restful endpoints makes it easy to pick a library centric approach vs. a framework approach but it certainly does not preclude you from using a framework.

I guess people who disable javascript don't get to use your site...but I don't really care about that segment of the population.

Re: Go Static or Go Home

#88
post #68
post #64

Earlier quoted context omitted.

Sorry, if you get the third argument of strncpy wrong, you are right back in the area of trouble.

Even when you don't get it wrong (i.e., no out-of-bounds writes), you can still get out-of-bounds reads because strncpy does not always null-terminate strings. C strings suck.

To be fair, the real issue here is 'strncpy', whose destination argument does _not_ operate on C strings, despite that it's name starts with 'str'.

Re: Go Static or Go Home

#89
I'm going to say that the bigger problem in dynamic languages isn't that they are dynamic. It's that they have weak, nonexistant, or very undeveloped mechanisms for creating strong communication protocols that you can depend on as safe or reliable.

Take the classic case of SQL injection. You have string input into your system that turns into string input into a SQL query that turns into string input to a database. That is dangerous because if you don't check on what the input string contains, it might contain nothing, or a semicolon, or it might not be a string at all!

We understand that putting a string direct into a SQL statement is dangerous at this point, but we have yet to fix its root cause - nonexistant protocols or boundaries in most code we write.

What a static language changes in that regard is compiler checked type signatures on your code. That generally stops you from say passing an Integer into something that needs a String. That solves a certain class of problems for sure, and the complier does it for you every time you change your code, so there is a convenience there.

What static typing doesn't give you is actual data correctness. Things like buffer overflows or SQL injection can still happen with static typing. You could use a language like Scala or Haskell to have stronger/more complex types that would have more distinct notion of value correctness and at that point the complier would be doing most of the work to ensure your program is correct.

Leaning on a type system in that regard is basically turning your types into the protocols that determine correctness in your system.

It is also possible to lean on stronger protocols that check messages in a dynamic languages to achieve largely the same thing.

In the end, to write safe, high quality software, you need to define the communication protocols between methods/functions/routines/services and enforce them much as you would with an externally facing REST api.

The difference between a dynamic system with dynamic protocol checking vs a static system with compiler type checking is the mechanism you are using to enforce the protocol and how easy it is to interact with it.

Dynamic systems might be easier to interface with externally because you don't have to understand a complex type, just pass a Hash/Dictionary sort of like a JSON API, vs a static system where you need to use the right types and so on, similar to a SOAP/WSDL API.

Performance is also a consideration, but really when you compare static vs dynamic, it is important to understand that at the end of the day you can write Ruby/Python/PHP that is functionally equivalent to C/C++/Java. They are all ultimately going to be able to do the same kinds of things.

The tradeoff is in how they solve the problem and how well that fits with the team writing the software.

Re: Go Static or Go Home

#90
post #88
post #68

Earlier quoted context omitted.

Even when you don't get it wrong (i.e., no out-of-bounds writes), you can still get out-of-bounds reads because strncpy does not always null-terminate strings. C strings suck.

To be fair, the real issue here is 'strncpy', whose destination argument does _not_ operate on C strings, despite that it's name starts with 'str'.

We can repeat this subthread with examples of UAF bugs, which are equally common, if anyone really wants to get the full flavor of how wrong it is to suggest that C is comparably as safe as Haskell.
Post reply on HN