[koolba]

> 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).

[colevscode]

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.

[danpalmer]

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

[smpetrey]

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

[artosispylon]

"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."

[everlost]

>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.

[jc4p]

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?

[koolba]

> 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.

[chrisrhoden]

> 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.

[koolba]

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.