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...
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)
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 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.
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.
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)
Cloudflare SSL can be used with Squarespace as an alternative. Everything Squarespace does underneath is over https already
I don't get how wordpress.com never became something more attuned to the needs of average Joe...
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).
> 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.
The assumption is that developers are concerned with the look and feel, client/owners are concerned with content.
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.
...interesting.
This is amazing news though! Hoping the next step is to expose a content manipulation api :)
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.
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.
