Squarespace Announces Local Development Server | Hacker News Reader

Squarespace Announces Local Development Server

engineering.squarespace.com

113 pointslepht39 comments

Next up an open source version that lets us host our own version without being trapped in their environment. Once that exists I'd see Squarespace as a viable option for hosting a website. Until then it's just another proprietary WYSIWYG website builder that I don't care about.

It's competing in a world where Wordpress is open source and is powering over 26% of the world's websites: https://w3techs.com/technologies/overview/content_management...

Squarespace is way too locked down. They advertise it as a great eCommerce platform and people come to us all the time already having setup a Squarespace store asking if we can pull their orders for fulfillment. It either has to be done manually or they force you to use ShipStation. Terribly inflexible for a webstore and I always steer people away as soon as possible. But hey, they got that sweet sweet exclusivity agreement so who actually cares about usability or the paying customer, right?

I don't see any benefit of having an exclusive, ShipStation wants Squarespace as much as Sqaurespace wants ShipStation

Squarespace typically integrates with best-in-class services for optimal onboarding, setup and UX. ShipStation is best in class for fulfillment, which is why I think they partnered with them.

But I agree with some of the comments. The restricted API kills all workflow-related processes. Regardless of shipping and fulfillment, there's tons of business processes that need to be done with orders and you can't do any of it with Squarespace. I've worked with dozens of clients who started on Squarespace and moved to other platforms simply because of Commerce restrictions.

I don't understand it either really. It's a one way exclusivity agreement so it's making ShipStation money by bringing them new accounts, but I don't see how it helps Squarespace to only offer one fulfillment option. I assume ShipStation is paying Squarespace. I see this type of decision and it makes me very wary of using a platform that would do such a thing to a seemingly critical component.

Hey --

Regarding the eCommerce integrations, Jason is right that early on we wanted to partner with a few companies where we felt like we could deeply integrate and provide a controlled/polished experience for consumers. There is no exclusivity agreement with ShipStation (though they're a great choice for many) and we're actively working on APIs that will allow larger merchants to integrate with our order/inventory systems more deeply.

(Disclosure: I'm the founder/CEO of Squarespace)

Thanks for commenting. It's good to know that there are options for some merchants. A lot of small to medium size merchants use third party fulfillment services or want CRM functionality and it's just not practical for them currently. I hope the bar can be lowered at some point as we and our customers have hit a brick wall any time we've tried to pull order information out of Squarespace. We'd love to be able to do it though and help those merchants who need it and like the platform.

This is insanely cool. No matter how useful/easy your web GUI is, if you have the skill set it's always easier to just do it by hand. Huge congrats to Squarespace, I've already linked this to friends I know that use them and have had customization issues in the past.

This is a great opportunity for those who have tried to teach themselves web basics before to actually add stuff to their own sites and really expand their skillset.

I've been working on my own thing similar to this for HubSpot, having to edit using a clunky CMS live in production is super scary. I really would like to live in a world where most "we make X easier to do" companies release things like this to let people who know how to do it by hand do it faster.

I'm mainly wary of Squarespace because their entire frontend compiles to YUI which stopped being maintained in August, 2014 (see https://yahooeng.tumblr.com/post/96098168666/important-annou...). You don't write YUI, but that's what the code ends up as when you visit the site. I tried out their developer platform early after they launched it, and trying to be productive with it put my brain in a pretzel.

I feel as though the SS CMS is overpriced for the features you get, and you're locked into their tech stack & templating which I find leave something to be desired. You can use Wordpress as a CMS and use the API to get the data yourself, or just compile the site to static for free with a plugin, not to mention the large number of paid pluggable CMS solutions for developers. The list goes on, but a local development server shouldn't be this big of news for a CMS developer platform.

That isn't entirely correct. You can use Squarespace on the front end 100% YUI-free if you want. I haven't used one line of YUI in years and I work exclusively with Squarespace. Some of Squarespace's internal features are powered by YUI and accessible via misc callbacks, but if you're building custom websites you don't have to use any of it.

Hi, I work on the Squarespace dev platform.

It's true that certain blocks still use YUI, but this is system functionality that's not part of our public API. In new templates, a Squarespace developer won't see or touch YUI code.

We're no longer creating new features with YUI. We write new frontend editor functionality with modern libraries like React.

Squarespace is awesome, but until they offer SSL certificates I can't recommend it to anyone. This is very unfortunate because it's a great product otherwise.

Founder/CEO Anthony Casalena mentioned on an interview with TNW (http://thenextweb.com/insider/2016/04/15/squarespace-now-let...) that free SSL would be coming soon to Squarespace customers by way of their new Domains service.

Cloudflare SSL can be used with Squarespace as an alternative. Everything Squarespace does underneath is over https already

It's coming!

I've personally wanted seamless SSL for all Squarespace customers on custom domains for forever now, and we've put a lot of work into making it a reality. Furthermore, before initiatives like Let's Encrypt, the business/logistics side of getting this in place was a mess.

(Disclosure: I'm the founder/CEO of Squarespace)

This is great! I really like Squarespace but this is one of the big features I have been waiting on. The other one is integrated A/B testing, or at least an easy way to work with A/B testing frameworks. Are there any plans to support this?

Not "seamless", but if you set up a VPS as a reverse proxy to your site with NGINX and Certbot, you can get Let's Encrypt running with Squarespace today. Doesn't require a huge amount of technical know-how; it was only the second SSL cert I'd ever installed. If anyone is interested in detailed instructions, shoot me an email.

A bit off topic, but if someone from Squarespace can comment - any plans to add an app market?

How can Squarespace even exist in a world that Wordpress supposedly had won? The answer is by winning over the average Joe, who is not a developer or webmaster.

I don't get how wordpress.com never became something more attuned to the needs of average Joe...

They need to compete with AWS Lambda / parse next I think. It would be an easy platform for junior javascript dev's to get up and going with a nice looking website that has a backend they can control.

> The first time you access a local template, it will take a while to load as the server fetches the site content. However, once the content has been cached, subsequent requests will complete more quickly until you terminate the server. If you need to invalidate the cache (because you’ve updated your website in the online editor, for example) you can use the ?nocache=true query parameter on any URL.

Why would a developer want to see a cached version of a page? A developer using this is actively developing the look and feel of the site so presumably would want to see the live version. This makes no sense and would only cause issues ("But it looked fine when I tested it locally a minute ago?!").

> The Development Server is built with Java using the Dropwizard framework. It takes advantage of our open-sourced JSON-T compiler and Less compiler. It’s packaged and distributed over NPM using a set of install scripts that detect the target platform and ensure Java is configured correctly. It’s built to be cross-platform, so Windows, Linux, and Mac developers can all take advantage of the efficiencies the Dev Server provides.

If this is really targeted for developers why not just make it a portable executable for each platform (rather than requiring a node install to just fetch the server)?

Alternatively, npm should install pip, use that to install cpan, use that to install gem, use that to install docker, and finally load the server from a container (which does the same series of npm/pip/cpan/gem installers run on Ubuntu 16.04 and then downloads a binary tarball of the app).

I'm not a 100% sure but when I've used similar tools like this before the cached data coming from the web is the _content_ of the page, where the checked out repo I'm in is dealing with the _layout_ of the page. Do you really need the contents of the newest blog posts to be pulled in each time you want to test a CSS layout change?

> I'm not a 100% sure but when I've used similar tools like this before the cached data coming from the web is the _content_ of the page, where the checked out repo I'm in is dealing with the _layout_ of the page.

Is this rendering the page remotely and fetching it? If so, it seems like the only point would be to reduce the server load on their end.

> Do you really need the contents of the newest blog posts to be pulled in each time you want to test a CSS layout change?

You would need something. At the minimum a "Lorem ipsum ..." to see how the text flows. What better than the real content for that? Especially if you already have it.

> Is this rendering the page remotely and fetching it? If so, it seems like the only point would be to reduce the server load on their end.

No. From the very line you quoted:

> ... the cached data coming from the web is the _content_ of the page, where the checked out repo I'm in is dealing with the _layout_ of the page.

> What better than the real content for that?

Nothing, which is why that's what they do. They figure that the content of the page as it exists when you first load the development server is sufficient, and so cache that content. It seems unnecessary to me to have my development server update the content if a new post goes to production in the middle of my work.

Ah misunderstanding on my part. I considered the entire page itself to be "content" and didn't realize they were referring to just fetching the copy. Makes much more sense now.

>Why would a developer want to see a cached version of a page? A developer using this is actively developing the look and feel of the site so presumably would want to see the live version. This makes no sense and would only cause issues ("But it looked fine when I tested it locally a minute ago?!").

The assumption is that developers are concerned with the look and feel, client/owners are concerned with content.

Hi, I worked on this at Squarespace.

> Why would a developer want to see a cached version of a page?

Squarespace is a CMS. There's an online content editor where users can add text and images. The content is rendered using a template which contains the HTML/CSS/Template code that defines the layout for the content. The squarespace dev server makes it easier for the developer to work on the template code using content from the live site. I don't think you'd run into a situation where it looked fine locally but broke in production, because the content will be the same.

> why not just make it a portable executable for each platform

NPM has great cross-platform support, and it's used by lots of web developers. That's why we chose NPM. It allowed us to build a cross-platform tool without having to maintain lots of separate installers for various platforms.

Also we wanted to take advantage of the same java based template and less compilers that we use in production (that are open source), which is a large part of why we used java. I'll admit it's not a natural choice for an NPM package, but it's working well for us so far.

Seems cool man! But why not give the dev the option to turn off caching?

"If you need to invalidate the cache (because you’ve updated your website in the online editor, for example) you can use the ?nocache=true query parameter on any URL."

That's a really strange choice, to distribute Java via NPM. Can you go into a bit more detail on the reasons?

Using NPM to distribute a Java application?

...interesting.

I had been using an open source variant of this the last few months, which ironically has a similar approach - https://github.com/NodeSquarespace/node-squarespace-server

This is amazing news though! Hoping the next step is to expose a content manipulation api :)

Same here. This was built by an outstanding outside dev who was using all sorts of undocumented methods to extract content and render a Squarespace template. That server has been awesome, but in order for it to continue to work the project dev had to maintain a JavaScript recreation of Squarespace's templating engine. This new dev server seems to run the same engine they use in the development environment. It works insanely well, even with some of the most complex stuff I've throw at it.

Very cool. Would love for Shopify to do something similar. These full-featured, hosted CMSs - NationBuilder, Shopify, Hubspot, SquareSpace - offer a lot of neat features, but the development experience ranges from slightly frustrating to plain old miserable.

I haven't found that to be the case for Shopify. Our theme is in git and each developer has their own development shop (hosted by Shopify for free).

Using the Shopify theme tool, changes in the local file system are automatically published to their development shop. The experience is the same as if you were running a local instance.

Production deployment is simply having a different folder mapped to master and watched by the theme tool too.

> changes in the local file system are automatically published to their development shop

in my experience this has been really annoying. changes can be pushed up nearly instantly, or sometimes they can take more than 5 seconds. this makes livereload unreliable.

HN Needs to have a way to mark a post as - Marketing.

Would save bytes to instead mark those that aren't.

holy crap. i threw my vote at this request three years ago, and then gave up on squarespace. i have no idea how they managed to be, or appeared to be, a "developer-friendly" platform without it.

Why does Squarespace insist that we code up our tables?

Reply on news.ycombinator.com