41–50 of 89 posts
Earlier quoted context omitted.
They still use it in all those services.
Not really. Those projects now use JsLayout, Wiz, and a couple of other more modern libraries. There may be some Closure widgets on very old, barely maintained, pages, but they'll be fine. Closure library is still in the Google monorepo, it's just not going to be copied to GitHub anymore.
These days it feels a bit like boost is to modern C++. A monument to amazing engineering of the past, but something to keep in the archive.
It's a shame this is being abandoned, because if you want a rich text editor that truly is Gmail's compose editor as it has existed for the past decade - that emits the same structures that Gmail would, handles copy-pasted rich text the same way Gmail does, has the same behavior in typing inside links etc... which is especially useful if you're building an email client that Gmail users need to feel familiar on every…
Fun fact: the code name for the editor was TrogEdit, with Trogdor the Burninator as their mascot. I believe they even had a life size cardboard Trogdor by their desks. It's one of the oldest, most stable, and never rewritten parts of the Gmail codebase.
Sorry to be negative, but I guess the lack of maintenance explains why the undo/redo is so atrocious, both in speed and in correctness.
Has anyone outside of Google had any luck using the closure compiler with a modern-ish stack with the advanced optimizations? Tsickle and the like seem to be archived as well, so it's unclear to me. Google must internally have some tooling to go from ts to closureJS?
They archived the open source parts , but it's the same stack internally.
Earlier quoted context omitted.
Fun fact: the code name for the editor was TrogEdit, with Trogdor the Burninator as their mascot. I believe they even had a life size cardboard Trogdor by their desks. It's one of the oldest, most stable, and never rewritten parts of the Gmail codebase.
> It's one of the oldest, most stable, and never rewritten parts of the Gmail codebase. Sorry to be negative, but I guess the lack of maintenance explains why the undo/redo is so atrocious, both in speed and in correctness.
[flagged]
Soon people are going to start putting up every line of code deleted by a Google engineer on this site.
Has anyone outside of Google had any luck using the closure compiler with a modern-ish stack with the advanced optimizations? Tsickle and the like seem to be archived as well, so it's unclear to me. Google must internally have some tooling to go from ts to closureJS?
Lucid Software migrated their code from closure compiler JS to typescript, and continue to use the closure compiler with advanced optimizations. See https://lucid.co/techblog/2017/11/16/converting-600k-lines-t....
It would not at all surprise me if google internally has better tooling than what they have open sourced though.
Earlier quoted context omitted.
I remember disliking google’s project names of that era. Too generic and borrow-y. Closure was a concept in JavaScript. Chrome is what Firefox was calling the parts around the rendered page (UI buttons, etc)
Not to mention “Go” …