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

Surge – Static Web Publishing for Front-End Developers

surge.sh

Post reply on HN
Print view View original

31–40 of 80 posts

Re: Surge – Static Web Publishing for Front-End Developers

#31

Post by savanaly »

pyrophane wrote: post #28

One of the testimonials: "From now on, I think I'm going to strive to build all my apps as fully static sites." What? I can understand the idea of not overcomplicating an app when you don't need to, but how does this goal make sense for anyone who wants to build anything non-trivial?

Did he perhaps mean build all his apps as single page apps? A react or angular site that uses ajax to load all data is, in some sense, fully static. This only applies if you consider the term "app" as applying only to the frontend part of your app. But that might make sense if your backend is all firebase or some other api.

Re: Surge – Static Web Publishing for Front-End Developers

#32

Post by ccallebs »

pyrophane wrote: post #28

One of the testimonials: "From now on, I think I'm going to strive to build all my apps as fully static sites." What? I can understand the idea of not overcomplicating an app when you don't need to, but how does this goal make sense for anyone who wants to build anything non-trivial?

Fully static sites don't necessarily mean static content in a user interaction sense. A lot of blogging platforms are database driven, but generate static documents instead of rendering the pages on the fly.

I agree it's a hyperbolic claim but it can work depending on the domain.

Re: Surge – Static Web Publishing for Front-End Developers

#33

Post by igorgue »

pyrophane wrote: post #28

One of the testimonials: "From now on, I think I'm going to strive to build all my apps as fully static sites." What? I can understand the idea of not overcomplicating an app when you don't need to, but how does this goal make sense for anyone who wants to build anything non-trivial?

Done this many times, in fact currently I deploy to S3 (look for "static website") and the static site interacts with an API.

This is the whole point of JavaScript frameworks to me. And definitely not trivial stuff.

Re: Surge – Static Web Publishing for Front-End Developers

#35

Post by cyberpanther »

I don't work directly with Surge but the other developers where I'm at have found Surge to have too much downtime and we're moving off of it now. Maybe in the future they will have a more reliable service, but right now you'll definitely experience the growing pains of a new tool.

Re: Surge – Static Web Publishing for Front-End Developers

#36

Post by kannonboy »

Rabidgremlin wrote: post #29

Along similar lines I have been playing with Bitbucket Pipelines and Hugo to build static websites on commit and deploy them to S3 buckets. Really like the way they use docker containers as build agents, it's very tidy: https://github.com/rabidgremlin/hugo-s3

Nice one! I'm a developer from Atlassian, it's cool to see the different CI/CD applications that Pipelines is being used for.

Regarding static site deployment specifically, Aerobatic (https://www.aerobatic.com/) have a similar static site publishing offering via a Bitbucket add-on, though it uses Lambda rather than Pipelines. They've got a couple of other nifty features like auto-renewing SSL certificates, too.

Re: Surge – Static Web Publishing for Front-End Developers

#37

Post by mikey_p »

jordanlev wrote: post #24

Is there a difference between what Surge offers versus ngrok? (Genuinely curious, not trying to imply that "this has been done before" or shouldn't exist!)

I was under the impression that ngrok only provided tunnels, while surge only provides hosting/CDN.

Re: Surge – Static Web Publishing for Front-End Developers

#38

Post by debaserab2 »

igorgue wrote: post #33
pyrophane wrote: post #28

One of the testimonials: "From now on, I think I'm going to strive to build all my apps as fully static sites." What? I can understand the idea of not overcomplicating an app when you don't need to, but how does this goal make sense for anyone who wants to build anything non-trivial?

Done this many times, in fact currently I deploy to S3 (look for "static website") and the static site interacts with an API. This is the whole point of JavaScript frameworks to me. And definitely not trivial stuff.

> This is the whole point of JavaScript frameworks to me.

What does it matter if your front endpoint is on S3 or being served by your own web server? Delivering static assets isn't that hard and you don't solve a lot by hosting the front end point of your app on S3.

Your bottleneck is way more likely to be your API long before static asset serving is a problem.

Re: Surge – Static Web Publishing for Front-End Developers

#39

Post by pyrophane »

igorgue wrote: post #33
pyrophane wrote: post #28

One of the testimonials: "From now on, I think I'm going to strive to build all my apps as fully static sites." What? I can understand the idea of not overcomplicating an app when you don't need to, but how does this goal make sense for anyone who wants to build anything non-trivial?

Done this many times, in fact currently I deploy to S3 (look for "static website") and the static site interacts with an API. This is the whole point of JavaScript frameworks to me. And definitely not trivial stuff.

I understand the architecture you are describing, and I don't think that it is trivial. My confusion is over what really constitutes a "fully static" app.

Re: Surge – Static Web Publishing for Front-End Developers

#40

Post by gumby »

grumble: they mention git hooks (and if you click on the description they are RCS agnostic) but they use the octocat logo.

Just yesterday I mentioned that I was using git and my gf assumed I meant github. She (not a developer) thought that git was a product sold by github.

Post reply on HN