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

61–70 of 80 posts

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

#61

Post by davidcelis »

sintaxi wrote: post #53
juandazapata wrote: post #8

Nice service, but too expensive to be honest. My static websites (built with middleman) are hosted in Amazon S3 as a static website bucket and have a Cloudfront distribution in front of it. I use `middleman s3_sync` to deploy the build in one command and it takes care of everything, even Cloudfront invalidation. All for just a few pennies per month. Anyway, keep up the good work.

Hi, Brock from surge.sh here. We are still figuring out our pricing. It kind of kills me to hear someone call surge too expensive. We worked hard to give surge a very legit free offering which is serving over 35k projects. Surge gives (currently) unlimited projects with custom domains. We charge $13/mo for that extra 1% which is custom SSL, basic auth, custom redirects. Very open to suggestions if you have any. Would…

> Would you prefer we have a small membership fee and open up all the features?

Yes.

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

#62

Post by aeosynth »

jqueryin wrote: post #49
pyrophane wrote: post #39

Earlier quoted context omitted.

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.

IMO, static doesn't have to have a correlation to being simpler. HTML, CSS, JS, and media are all static assets but you're welcome to request whatever datatypes you want behind the scenes via AJAX and/or CORs. The benefits are entirely in the rendering speeds of an optimized web server and cache layer. Also, this approach plays extremely nicely with CDNs. Difficulties can arise if you have to begin dealing with versi…

Is the performance/simplicity that much better than setting up Cloudflare yourself?

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

#63

Post by elliotec »

cutler wrote: post #60
macandcheese wrote: post #27

Earlier quoted context omitted.

Agree, Middleman + Middleman s3_sync is such an easy set up and deploy... Middleman project doesn't get enough love I think...

I gave up on Middleman when I couldn't get anyone in various Ruby mailing lists and IRC channels to advise me how to stop Middleman deleting directories which aren't mirrored in the src directory. Jekyll has the keep_files: [] config option.

I had that same issue. But then I just mirrored them in the src directory and it was fine.

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

#64

Post by wilg »

sintaxi wrote: post #54
hanniabu wrote: post #18

I mean, if you're doing a static site you can also use github pages with a simple push command. Is there some difference between surge and doing this that I'm not seeing?

If you are properly preparing your assets for web distribution you really don't want those files in a git repo. it messes up your commit history and doesn't provide much value. I think gh-pages is fundamentally broken for this reason. IMHO its best to keep your source files in a git repo and publish your compiled assets to surge.

https://github.com/edgecase/middleman-gh-pages solves this problem by letting you do all your work on the master branch, then your build script compiles all your assets and commits them to the gh-pages branch, so it doesn't pollute your Git history.

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

#65

Post by JorgeGT »

wilg wrote: post #59
Santosh83 wrote: post #52

Earlier quoted context omitted.

Have you considered Gitlab, which does advertise custom domains for which you can upload your own SSL certs? Even at the free plan level. I would switch to it if not for the fact that my site isn't dealing with any kind of sensitive stuff so I figured Github Pages with Cloudflare's SSL was enough, although I'm aware its not end-to-end.

I couldn't get CloudFlare's SSL to work with GitHub Pages when I tried it because of some DNS issues. Do you have that working?

I do. I just enabled CloudFlare's SSL, added a redirect rule from unsecured http to SSL in CF (there is a template I think) and adjusted the base URL in the YAML file of the repo accordingly. I don't believe I did anything else.

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

#66

Post by wilg »

sintaxi wrote: post #48
wilg wrote: post #46

Earlier quoted context omitted.

I used to use GitHub Pages, but you can't have a custom domain that has SSL, so I switched to Surge like six months ago, and it works great. To be honest, though, if GitHub adds custom domains with SSL to pages, I'll probably switch back.

`(ノಥ,_｣ಥ)ノ彡┻━┻`

The deploy process is much easier for me to manage on GitHub Pages, because I can just do "rake publish" and middleman-gh-pages deploys the site. Neither I nor my collaborators have to deal with the details of deploying. Surge makes you remember to call the surge command with the proper arguments and have collaborators also have surge accounts set up properly.

Maybe there's a way to have a GitHub webhook automatically trigger a deploy to Surge? That would probably solve this issue for me. Though GitHub Pages is still easier.

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

#67

Post by sorenbs »

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.

Indeed this is how I have build all my projects for the last two years. Currently I am building a platform to easily deploy a graphql api called https://graph.cool

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

#68

Post by macandcheese »

cutler wrote: post #60
macandcheese wrote: post #27

Earlier quoted context omitted.

Agree, Middleman + Middleman s3_sync is such an easy set up and deploy... Middleman project doesn't get enough love I think...

I gave up on Middleman when I couldn't get anyone in various Ruby mailing lists and IRC channels to advise me how to stop Middleman deleting directories which aren't mirrored in the src directory. Jekyll has the keep_files: [] config option.

Definitely looking in the wrong places, based on Middleman's more "lightweight" front-end audience. You'd probably get faster responses on Twitter.

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

#69

Post by pbreit »

ozten wrote: post #34

Another interesting competitor is PubStorm https://www.pubstorm.com/ Their price is TBD, but they have a cool "quick and easy revert" feature.

I came to mention PubStorm which I started using recently and have been pleased so far. I got the impression that some reasonable service would remain free?

Hoe does Surge compare?

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

#70

Post by pbreit »

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

That all sounds like crazy overkill for static sites?
Post reply on HN