Hi Matt,
What was the rationale for this project? The joy of destruction?
We first announced this gradual plan in 2017, with an update in 2019, and now we're providing the detailed plan. The goal was to provide adequate notice for people to figure out whether migration, export, or deletion of their classic sites makes the most sense.
EDIT: to the multiple people that are highlighting that 12 years is not a long time, I should clarify. I agree that 12 years in Internet time is not a long time, but it is a very long time in "how websites work" time.
One of the big challenges in the website builder space, something that Google. Wix, Squarespace, have all dealt with - is that when a user publishes a website, there's an expectation around the fidelity and look-and-feel of that website. The data model and architecture for how you represent a rendered page, how you render embedded content, all are very dependent on how browsers work at that time, and the maintenance of those things can become very challenging.
There was a big shift about ~7 years ago, moving away from a "pixel perfect" layout/raw html approach (Wix, Old wordpress, SQSP 5, Classic Sites), to one where there's some sort of grid-and-box approach where the render is responsive, there's reflow, there's padding and spacing and styling relative to the browser experience. It separates out content from layout to a certain degree in a way that is much more future-proofed and modern. This is how Wix ADI, Squarespace 6+, Wordpress Gutenberg, and new Sites work.
For all of those transitions, there was a platform shift, that required a complete rework of how the system works. My point about "12 years" was that the model of how classic Sites works is 12 years old, and new Sites was intended to match the modern way of how websites are built and delivered.
What should have happened is to turn Classic Sites (and new Sites) itself into Squarespace competitor.
I just see this as a massive failure of vision and execution.
Why didn’t they improve classic sites and added yet another product called Sites? May be I am seeing some internal politics surface as fragmentation of product line.
To your Squarespace comparison, Squarespace went through a similar transition - Squarespace 5 worked very similar to Classic Sites, and was replaced with Squarespace 6, which was a complete end-to-end rewrite.
Could have called it Classic Sites 2.
Huh? Did that 10 years ago. Perhaps we have a different definition of a "classic site".
To me a "classic site" is another name for a static site, that is, a website where the HTML to be served is pregenerated. Static sites are now coming back, not going away. But I always assumed that a website should reflow.
Perhaps when you say "classic site" you mean "site that assumes that all users have the same display size". I agree that such classic sites are nonsense today. But they were always nonsense. At no time was there a guarantee of any particular screen size for HTML, and it's always been easy to write HTML that just reflows. If you do that, your site works just fine.
GP didn't say “classic site” they said “classic sites website”. You seem to be interpreting that as intended to be a somewhat redundant and mispunctuated rendering of “classic site’s website”, but given that the context is a discussion for the shutdown of Google’s classic Sites in favor of only supporting Google’s new Sites mode, I think that it's just a capitalization-omitted rendering of “classic Sites website”, that is, a website using classic Google Sites as opposed to new Google Sites.
Also, people have technical knowledge here, even if they've never been hired by someone as "the best of the best," or having graduated from a top 10 CS school, so handwaving "fundamentally works differently" is not actually likely to be the enlightening description you might hope it would be.
Anything I can say would only detract from this.
This is modern Google.
Also RHEL support lifecycles are 11+ years, so for RHEL 8 released in 2019, that's a commitment to ~2030 right here and there & with doing this for many years for the past releases proving the point.
No wonder the most critical stuff (Bank, Stock exchnages, etc.) run on RHEL and not on some half baked Google stuff that will get deprecated from under them at a moments notice.
In this particular case, with Google Sites, maybe the decision was totally justified, I don't know. But, as a general trend across the technology industry, this type of explanation really bothers me, and I think it speaks to a serious mindset problem.
The fact that X is old and Y is new is not a reason to replace X with Y. Hammers are old, but they're also exceedingly useful tools. Users are familiar with how hammers work, and companies have become good at manufacturing them.
The question should be whether the new tool is better than the old one, and if it is, whether it's so much better that forcing every user to re-learn the new tool will be worth their while. And even then, it's worth asking why some of the largest companies in the world can't let both tools coexist, perhaps with the older one kept semi-hidden to avoid confusing new users.
Anyway, sorry for picking on you, I appreciate your willingness to pop into a somewhat-hostile thread. :)
This mobilification is a fad, and like many fads it will, too, disappear and have to be replaced (requiring many work hours) because ultimately it’s less usable especially for largely static content. There’s no option to keep a similar look and feel. “Mobile first” has been forced upon us and is now, with reflow, “mobile only.” Imagine if Arxiv required PDFs to be replaced by mobilified versions? So annoying and impractical.
Really disappointed. Google made a bunch of work for themselves just to reduce the usability of older web pages.
A website maintained with raw HTML still works just fine on modern web browsers. In fact, it works much better. Web pages built with some CMS systems often take 5-20 seconds to load, while the "raw HTML" sites load in fractions of a second. In fact, the speedups continue; JavaScript parsing is slow, while HTML parsing is fast, and HTML compresses like magic. So a "big" HTML file is transferred and displayed in remarkably fast time.
I wouldn't use raw HTML in all cases, but I also wouldn't use a fancy CMS in all cases.
It's okay to use different platforms for different purposes.
Google's misson is "to organize the world’s information and make it universally accessible and useful". Dropping sites on the cutting room floor because information in them isn't in a convenient format does not make that information accessible or useful.
My belief has always been "no". Google could kill off the entirety of GMail tomorrow, and I'd be disappointed, but totally understanding.