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.
> 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.
"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."
Cool tech, fun toy! I hope it is successful. I think Joel should focus on it's toy-like nature, and potential as a learning tool, rather than trying to build this into a production grade tool.
I spent years building tools for this market between professional devs and non-developers. (Backlift.com and then Brace.io) It's really tough. Most people learning to code are trying to gain transferrable skills that can help them land a job. For them, learning git is a fruitful tangent along the path to shipping. Those that aren't interested in building those transferrable skills probably don't self-identify as developers. Making developer tools for non-developers is tough.
> Cool tech, fun toy! I hope it is successful. I think Joel should focus on it's toy-like nature, and potential as a learning tool, rather than trying to build this into a production grade tool.
Agreed, and I think the latter part of the post (the "FAQ") indicates that Joel doesn't see this as a deployment strategy for professional developers...
"Listen, this is not the future of all software development. Professional software development teams will continue to use professional, robust tools like Git and that’s great. But it’s surprising how just having continuous merging and reliable Undo solves the “version control” problem for all kinds of simple coding problems. And it really does create an insanely addictive form of collaboration that supercharges your team productivity."
Basically it's a platform that makes a major trade-off: practically zero accountability in exchange for maximum usability. To us professionals, this doesn't seem like a worthwhile choice. However, to those non-programmers or budding programmers which I believe this product is geared towards, it's a step in the right direction. This feels like it wants to be the "Google Docs" of programming.
I could see this as a great tool for doing coding interviews. You get instant feedback to see if it works, and you can share the results with others almost as a code resume of sorts.
Hi, I'm one of the creators of Brace Forms. I am really happy with the way formspree is working on assembly.
Want to send feedback? There's a form at the bottom of formspree.io and we've got people in the community that are now responding to those customer service inquiries.
Several have asked about the 10m delays. We switched email providers so we could improve our email deliverability and spam filtering. But the new provider is throttling us while they get a sense of our email traffic. I've been told that it should be back to normal soon. These are growing pains.
Frankly I'm pleasantly surprised to see the project gaining momentum. The alternative would have been to shut it down.
The great thing about a Twitter account or using GitHub issues is that (ideally) you only have to answer a question once. You tweet out that you're aware of the issue and that you're working on it, or I browse for it in the GitHub issues and see it's already been raised and there's a pull waiting to resolve it.
The fact that Brace/Formspree allocate so many points to customer service inquiries on Assembly sounds like you're being inundated with questions that could be managed in a more open fashion?
Well for one, I'm assuming the frontend is all javascript? Am I dependent on a 3rd party service? Are there some examples of how it looks / behaves on the frontend? Is it stable? Is that form submission code adding rows to the spreadsheet? Does it depend on the spreadsheet being a certain format? What about multiple tabs? Does it need to oauth a google account? So on and so forth
Instead of "redirect the root domain to the www subdomain using a DNS CNAME record" it should say "... using domain forwarding".
Most DNS hosts offer some mechanism for forwarding traffic from your apex domain to the www subdomain using a 301 (permanent) redirect. Then the www subdomain can be configured with a CNAME record.
Cole with Brace here (http://brace.io). We recommend redirecting the apex domain to a "www" subdomain. Note that even using apex CNAME records (Alias records) are still a new idea, and depending on the implementation may reduce reliability or performance. (https://iwantmyname.com/blog/2014/01/why-alias-type-records-...)
Here are a few resources from our blog that explain the www redirect approach:
