Google Chrome's Top Web App Advocate Resigns (cnet.com) 52
Google is losing one of its strongest champions of the web. Alex Russell, who has led the Fugu project to make web apps as powerful as those running on Google's Android or Apple's iOS software, is leaving the company on Wednesday. From a report: Russell announced his departure on Twitter. He's not quitting in anger or being pushed out. But after 12 years at Google pushing his vision for a more powerful web, "I need some time off," he said in an interview. Russell has been an outspoken advocate for the web, using Chrome's dominant position to help test and introduce new abilities that let programmers build interactive apps on the web, not just relatively static websites. Project Fugu embodies this effort, as does the broader progressive web app, or PWA, movement that lets you install and launch web apps more like those that run natively on smartphones and PCs.
Responsible for making the web bloated (Score:3)
Re: (Score:2)
Making a fast website is easy. Render the damn thing on the server instead of sending megabytes of javascript libraries that need to load first that then load the website itself. Seriously what kind of nonsense is that? The server has to send something anyway at first and then has to send replies to all those Javascript requests. How the hell is that supposed to be faster? Which idiot thought of that messed-up way of doing things?!
Re: (Score:3)
Re: (Score:3)
You both would enjoy full page refreshes for every little action you take.
Server-side rendering does not require a full refresh with every change.
A proper protocol would only send compressed diffs.
Re:Responsible for making the web bloated (Score:5, Insightful)
You both would enjoy full page refreshes for every little action you take.
The idea is that web pages should never have been applications. The original idea was simple and elegant: a document presentation language, Text, images, some embedded metadata, and that's that. If one wanted other kinds of functionality, one could develop actual softwares to provide those, web browser and their simple hyperlinked documents being but one among many. In fact, the only "actions" that should exist are, in addition to scrolling the text up and down, clicking underlined links to open documents to read, and clicking back and, very rarely, forward, nothing more.
Instead, web pages got scripting for fun stuff when Mozilla introduced JavaScript. And then everyone decided this was an excellent means to make full fledged applications on, to the point the browser became a OS on its own, something that was, and remains, insane.
Re: (Score:3)
Re: (Score:3)
Yes, it'd be much better if every website were its own app. Hopefully proprietary, with no Linux version.
What do you mean, no Linux version? If you wanted a forum, you'd link to an open standard one, such as a NNTP server. If you wanted to add chat, you'd link to an also open standard IRC server. Anyone would use the software they preferred, showing things the way they preferred, and everything would be compliant with everything else. That was not only Linux compatible, but also Amiga compatible, BeOS compatible, OS/2 compatible, PalmOS compatible etc.
The idea that for something to "be compatible" it must run
Re: (Score:2)
Re: Responsible for making the web bloated (Score:2)
Ah! I see, you're trolling. Got it. :-)
Re: (Score:2)
If you wanted a forum, you'd link to an open standard one, such as a NNTP server.
If I wanted (say) a collaborative whiteboard-like drawing application, what open standard would be used so that I can recommend open standard servers and clients therefor? Likewise if I wanted a computerized graphical role-playing game.
If you wanted to add chat, you'd link to an also open standard IRC server.
As for chat in particular, what is the open standard for accessing message history, summarizing pages cited in URLs in messages, and uploading images, audio, and video for viewing by other people in the channel?
Re: (Score:2)
If I wanted (say) a collaborative whiteboard-like drawing application, what open standard would be used so that I can recommend open standard servers and clients therefor?
The open standard could be ITU T.126: Multipoint still image and annotation protocol [itu.int], part of ITU T.120 Standard [packetizer.com]. You can find clients, servers, and networking equipment with direct support for it, or indirectly via support for the broader H.323 standard [packetizer.com]. Here's Wikipedia partial list [wikipedia.org] if you're interested.
Likewise if I wanted a computerized graphical role-playing game.
The obvious solution would be X Window [x.org] primitives. Differently from completely backwards ideas such as remote desktop access, which transmits the entire image of the other computer's screen as a video stre
Re: (Score:2)
[Pick an open protocol for] a computerized graphical role-playing game.
The obvious solution would be X Window primitives.
I have occasionally tried displaying a video game over remote ssh -X. It didn't respond quickly to keypresses or mouse clicks, as if it were starved for network bandwidth sending the drawing instructions (and associated bitmaps) and/or blocked on round-trip latency. Should the game have been built with X Athena Widgets instead of one of the more "modern" toolkits?
Re: (Score:2)
Should the game have been built with X Athena Widgets instead of one of the more "modern" toolkits?
My guess is that the standard would have required lots of updates over the years to deal with those details. This hasn't happened, so what exists isn't up to current demands. But it's evidently nothing that couldn't have been fixed had the standard, and its implementations, received a fraction of the optimization efforts that went into optimizing browsers performance, after all, if browsers can provide the necessary performance even though anything running on them is operation upon several layers of abstrac
Re: (Score:2)
My guess is that the standard would have required lots of updates over the years to deal with those details. This hasn't happened, so what exists isn't up to current demands.
Right because who is actually going to do that work? It's not just a matter of building a thing you need, it's about then also building the specification for it, getting buy-in from all the stakeholders and addressing all the niche use cases. If you just need to develop something then all that ancilliary standardization process is just a bunch of work that takes a lot of time. It's often not worth it.
Like the speed of X over a network, I don't necessarily agree with inventing your own solution to the proble
Re: (Score:2)
I don't disagree with you, but explaining why something happened doesn't make it into the correct solution. The current situation is an enormous amount of hacks added to hacks to make something that was planned as a simple documentation display become a software platform, on top of a stateless protocol beaten into statefulness with a cudgel, with never intended privacy enveloped around it, and it's server background process, intended to generate one-off documents, twisted into somehow keeping themselves int
Re: (Score:2)
That doesn't mean it's the way it should have been done.
Yes that's what I said. But to reach a different solution you need to fix the problems that caused this to be the solution.
Back to the Future. (Score:3)
Re: (Score:2)
That's a matter of presentation, not of the underlying technology. E-mail as it existed back then was also designed by geeks for geeks etc., while nowadays e-mail clients make it a joy to work with. The same could have been true of other protocols, weren't for the encroaching of walled gardens trying to make sure everyone stay on their centralized platforms rather than using decentralized, client-agnostic protocols.
Re: (Score:2)
There's also no reason you need
You're confusing individual decisions with a widescale technological shift. Yes, "I can do" this or that. It won't change the fact technology at large went in a direction it shouldn't have gone.
Re: (Score:2)
If Discord and Slack were built existing open protocols and extended them those individual decisions would have been part of driving a change in the "right" direction. But what value would that have added for Discord and Slack?
This tracks back to a more fundamental problem with software development. Although software is widely used to the point of modern society utterly depending on it, and programmers being called "engineers" and "architects", software development is far from an engineering discipline. Engineers, real engineers, must abide by all manners of laws, regulations, professional registration, professional ethical standards, and industry standards, being personally responsible, and subject to civil and criminal liabilit
Re: (Score:1)
Pretty much this...
Replace "app" with "domain specific protocol" And you're good.
The key is inter-machine communication. Getting (structured) data from one machine to another, hopefully efficiently. Once you have a specced out protocol, you can have as many implementations as you want. The great paradox is that it might even save manpower in the big picture.
The downside is that new feature deployment takes an industry-wide collaboration. As seen on XMPP, this is hard.
This is also the reason we see a reinven
Re: (Score:2)
Agreed.
Although bloated content and excessive server/browser communication is a problem, I think you will find most of the rendering delay problems are due to an incredible number of external links that have to load on most pages. Ads, trackers, and social media links are everywhere and in stunning numbers. Even a lightweight like /. has up to a dozen on a simple page. They all have to be dealt with one way or another.
It isn't unusual to find 30 or more external links. Separate servers all with their ow
Re: (Score:2)
> Render the damn thing on the server
About every 20 years there is a cycle between Thin Clients and Fat Clients. This is no different.
The problem with rendering on the server is that you kill any sense of responsiveness or perceived performance. Ideally, you want to target 120 FPS [surma.dev] for jank-free animation or if you must downgrade to 60 FPS. Standard 24 FPS / 30 FPS looks like shit for animation
> megabytes of Javascript libraries
That's the first problem right there. Bloated library after bloated libra
I don't want animation (Score:2)
Re: (Score:3)
I want a simple user interface. Button hover/click changes is about the only animation I need.
There's a small community trying to bring that back in a way that puts severe limitations to complexification attempts. It's the Gopher-inspired Gemini protocol [wikipedia.org] with its easy-to-write servers and clients, and client-controlled presentation. The goal is to have mostly textual content over encrypted connections, with no opening to 3rd-party tracking, scripting of any kind, or privacy-violating protocol extensibility.
Re: (Score:2)
If Gemini is all we had, no web, how would an online shop's order form work?
Re: (Score:2)
If Gemini is all we had, no web, how would an online shop's order form work?
It'd probably be something built atop open protocols similar to Sprawl [sprawl.io] or Beckn [beckn.org]. After all, online shopping predates the Internet [1stwebdesigner.com].
Re: (Score:2)
A little extreme perhaps.
I feel that a good alternative to that would be a "LINT-checkable" strong convention for use of html for simple web pages.
As a controversial part of that, perhaps javascript could be banned in these pages. (discuss, lol).
An analogous thing to the Gemini Space, but within the web, protocol-wise, could then by made, by searching for some kind of certification statement ("badge") in the compliant web pages.
Re: (Score:2)
I feel that a good alternative to that would be a "LINT-checkable" strong convention for use of html for simple web pages.
The protocol itself allows other kinds of content, so in principle it's possible to serve HTML with it. Clients aren't required to interpret it though, since the goal is that clients should be easy to program, and modern HTML and CSS are very complex. A simple client would therefore either try and format the bare minimum of it, or it'd simply ask whether you want to save the file or open it in the associated application, which would usually be a browser. I suppose more complex clients would have basic HTML
Re: Responsible for making the web bloated (Score:1)
Yeah, because jira is a high performance web app that doesn't jank every single time you interact with it.
For sure, there's a balance.
However, quite how an app is supposed to work offline, when all rendering is done on a server, I don't know.
Also, iinm, Google and Alex Russel are not somehow against SSR. Not in any way.
Re: Responsible for making the web bloated (Score:1)
The Web doesn't get rid of specifications... so no.
Re: Responsible for making the web bloated (Score:1)
This is false.
In fact, the opposite is true. It is the authors of the myriad of javascript framework developers that are responsible for the bloat of libraries that are downloaded. Russel et al are responsible for figuring out WHY those library developers feel the need to do that - ie what problems they're trying to solve - and how those features can be built into the platform so they no longer need to be downloaded. Furthermore, those features can be optimised in the browser by highly competent people who
Re: (Score:2)
One less person pushing non-standard features (Score:3)
They guy even has the nerve to say "He also wishes Mozilla's Firefox would move faster." Chrome keeps pushing out non-standard features constantly, expecting everyone to just do what they want? Seriously, bunch of freaking arrogant jackasses. I'm glad he's leaving.
Re: One less person pushing non-standard features (Score:1)
That's how standards become standards... it's how new features are born, and other platforms have a part to play. Not all such experiments are adopted either, some specifically rejected by mozilla themselves (html imports).
Re: (Score:2)
We don't need new features; we need to get rid of the bad ones.
Re: One less person pushing non-standard features (Score:1)
Lol, and break the Web in the process. Good idea...NOT. What compete nonsense.
Re: (Score:2)
Getting rid of the blink tag didn't break the Web.
Re: (Score:2)
Re: One less person pushing non-standard features (Score:1)
No, I don't. The standards process is well established and involves many companies, including Microsoft.
Frankly, I wouldn't mind working for Microsoft. The company I currently work for is on its last legs, suffering due to covid. But thanks anyway.
Re: (Score:2)
Re: (Score:2)
Chrome keeps pushing out non-standard features constantly, expecting everyone to just do what they want? Seriously, bunch of freaking arrogant jackasses.
That's how standards evolve, you provide a specification proposal and an implementation so that developers can try it out and provide feedback. Like the way raytracing extensions were introduced to Vulkan: Nvidia proposed a specification for its raytracing extensions and an implementation. Khronos Group, and developers that provided feedback to the advisory board, iterated on those extensions to reach a point where they were agreeable to all the vendors that are part of the group and could become part of th
Uh (Score:2)
Google is losing one of its strongest champions of the web
No, he's not a champion of the web. He's a champion of turning web browsers into some kind of app shells. Into something they are not.
"champion of the web" my ass (Score:2)
More like "another Dunning-Kruger type who, thanks to the sociopathic company he works for, managed to shovel garbage into browsers specifically and Internet standards in general that degraded almost every aspect of them irrevocably".
Sadly, his departure won't fix any of the problems he created, as that damage has already been done. Worse still, his successor, empowered by this "success", will continue in the same vein. Hooray...
Re: "champion of the web" my ass (Score:2)