[HN Gopher] Google Docs in a clean-room browser
___________________________________________________________________
Google Docs in a clean-room browser
Author : sohkamyung
Score : 350 points
Date : 2021-09-20 12:28 UTC (10 hours ago)
(HTM) web link (www.ekioh.com)
(TXT) w3m dump (www.ekioh.com)
| evmar wrote:
| > seems to compare the Firefox version number with 65 ... I've no
| idea what the purpose of this is
|
| I previously worked on JS infra at Google. Google uses a lot of
| shared JS libraries that date back over a decade, and those
| libraries have accumulated lots of workarounds for browsers that
| nobody cares about anymore. (One especially crazy seeming one
| from today's perspective is that there's a separate
| implementation of event propagation, I believe because because it
| dates back to browsers that only implemented one half of event
| bubbling/capture!)
|
| It's very difficult to remove an old workaround because
|
| 1. it's hard to be completely sure nobody actually depends on the
| workaround (especially given the wide variety of apps and
| environments Google supports -- Firefox aside, Google JS runs on
| a lot of abandonware TVs), and
|
| 2. it's hard to prioritize doing such work, because it's low
| value (a few less bytes of JS) and nonzero risk (see point 1)
| without meaningfully moving any metrics you care about.
|
| In all, how to eliminate accumulated cruft like is a fascinating
| problem to me in that I can't see how it ever gets done. And it's
| not a Google thing. Even the newer cooler startup I now work at
| has similar "work around old Safari bug, not sure if it's safe to
| remove" codepaths that I can imagine will stick around forever,
| for similar reasons.
| brundolf wrote:
| 1) Write it from the beginning in such a way that it can be
| removed easily. Ideally a single chunk of code, an entire file,
| etc.
|
| 2) Put a big comment on it that says "HACK: Remove when X is no
| longer the case"
|
| 3) Periodically check X when you think about it or come across
| that code
|
| If X is "users' browsers have collectively reached a certain
| milestone", that should be easy to measure for via logs
| brabel wrote:
| > Put a big comment on it that says "HACK: Remove when X is
| no longer the case"
|
| You know, every now and then I come across some comment like
| that from 6 years ago that is clearly no longer applicable
| and I go and remove the hack... feels really good, but I
| don't think anyone will just go around looking for these
| trying to get rid of hacks as there's ALWAYS more important
| things to do... the hack will probably remain mostly harmless
| there for decades to come :D so why would we spend time on
| that other than by happenstance, like I've just mentioned?!
| brundolf wrote:
| I mean it's really satisfying to do, and if the originator
| did make the thing easy to remove, then it doesn't take
| away much time from other priorities
| munchbunny wrote:
| > In all, how to eliminate accumulated cruft like is a
| fascinating problem to me in that I can't see how it ever gets
| done. And it's not a Google thing. Even the newer cooler
| startup I now work at has similar "work around old Safari bug,
| not sure if it's safe to remove" codepaths that I can imagine
| will stick around forever, for similar reasons.
|
| I think this is because it's not purely a technology problem.
| Especially if you have enterprise customers, the real question
| you are asking is: by removing support for these specific
| browsers, are you breaking someone's important workflow in a
| way that lacks viable IT workarounds? Because if you are, the
| backpressure via business channels will be what forces you to
| keep the old cruft in the code.
|
| In a previous job, I had to explicitly keep tabs on certain
| customers' IT policies w.r.t. browsers because that would
| ultimately inform our browser support matrix, and because it's
| enterprise, the actual browser versions could lag by 5 years or
| more. And when a single enterprise user is stuck on IE9 but the
| account is worth tens of thousands of dollars to your nascent
| startup, starting a fight with their IT department is one of
| the last things you want to risk customer goodwill on.
|
| That's why I was goddamn ecstatic about Microsoft's move to
| Edge, because it meant historically stuck-on-Trident businesses
| now had a path to supporting more up-to-date browser tech on a
| much faster cadence.
| sroussey wrote:
| Exactly--it's a business issue. There are likely SLAs for
| support Roku or Samsung devices as well as the enterprise
| fleet you mentioned.
| joe-collins wrote:
| For letters "p" and "z", this strikes me as likely related to
| print and undo functions.
| jrochkind1 wrote:
| all the letters between p and z. pqrstuvxwyz
| inetknght wrote:
| > _not sure if it 's safe to remove_
|
| That's a symptom of companies spending all their money on
| building new features without also spending money on regression
| testing.
|
| If you build a feature to work around a third party then surely
| you have that third party on-hand to build automated tests
| against and ensure that something didn't break and/or is still
| needed? If not then you're not writing new features; you're
| writing hacks. And you are perpetuating the same problem on
| other people.
| jokethrowaway wrote:
| While I agree in theory, for a long time there was no easy
| way to test frontend code across multiple browser. That
| effort was simply too high for anyone.
|
| Nowadays front-end testing is doable but still far from being
| a pleasant experience. I did it at some jobs, in others we
| just didn't think the benefits were worth the hassle.
|
| Now that I'm building a small business my backend is very
| well tested while the front-end doesn't have tests. This is
| partly because of the setup cost and partly because the
| development experience is so bad that I see our small company
| just throwing everything out of the window, keeping the html
| structure and rebuilding the thin UI with some better
| technology along the way (current stack is react + next +
| tailwind, we've been doing react for 5+ years)
| wpietri wrote:
| Interesting! Could you say a bit about what you think might
| come next? Or from a different angle, the pain points you
| have that make you think a rewrite in a new stack is
| preferable?
| jokethrowaway wrote:
| I don't think we're waiting for some new concept that is
| missing. I've been hoping for someone to maintain some
| popular js library implementing real functional reactive
| programming and arrows (like
| https://hackage.haskell.org/package/auto), but I can live
| without it.
|
| I'm just waiting for something polished, with a small,
| simple, codebase (not React with fibers, yes to something
| like solidjs, preact) with widespread types support (not
| Typescript and the quest for implementing types for every
| dependency), ideally not creating huge bundles (I like
| solidjs / svelte), with a core solution to manage state
| (I like Elm), ideally supporting CSS encapsulation and
| semantic css (I like CSS modules, MaintainableCSS),
| mainstream enough that I can hire people to work with
| without having to become a teacher.
|
| I think Elm got 90% there, but it failed hard on the
| community side. I'm thinking of moving to a Rust
| framework (eg. seed-rs) next as soon as they get popular
| enough and after checking whether the wasm bundle size
| make sense.
| jefftk wrote:
| The most likely case is that Firefox <65 still doesn't work
| (browsers almost always only fix bugs in new versions), and
| the question is whether or not it's still worth supporting
| the portion of traffic on pre-2019 Firefox.
| xxpor wrote:
| Not always true. Especially for something running on client
| devices. You can't expect an app maker to own every possible
| device their code is going to run on.
|
| Now maybe Google could do something like that, but 99% of
| people couldn't.
|
| There's also, in this case, a question of _if_ anyone is
| still using the device /browser/whatever. It sounds like they
| know removing the workaround will in fact break that use
| case, they just don't know if they should care or not.
|
| The third party in this case might be Grandpa Joe. You can't
| exactly ask him to use the beta version of X and see if it's
| broken. Or if he's still on Firefox vOld.ancent.
| z3t4 wrote:
| It used to be that when someone got a fancy new device,
| like an iPhone you just said: - If you want me to fix the
| issues, send me an device.
|
| Now alot can be emulated. I can for example start Xcode
| simulator and pick the device someone have issues with. Or
| I can run Windows Xp in VirtualBox. Or emulate the Samsung
| smart-watch, or run Android emulator. So a lot of devices
| can be simulated or emulated, and you can try removing a
| line of code and re-run the test suit on all the virtual
| devices.
|
| Lots of old code for obsolete devices is only one end of
| the problem! The other end is to make sure all those old
| devices still works when you make changes and add new
| features! There's no idea keeping and old fix if the app
| will crash on that device anyway.
| haliskerbas wrote:
| Plus how many people even get promoted for painstakingly
| removing JavaScript that wasn't needed in the first place?
| evmar wrote:
| As a person who enjoys doing this kind of cleanups, it is
| disappointing. But when I think of the larger business
| perspective, these kinds of cleanups are difficult to
| justify, in that the value of them is hard to quantify.
|
| Overall the net effect is a kind of death by a million cuts,
| but each of these cuts individually is a decent amount of
| work to clean up and fix that doesn't itself move any
| needles.
|
| My latest perspective on this is that the only renewing force
| is the also the one found in nature, which is that you
| occasionally need to burn the whole forest down or have the
| organism die, so that you can start again afresh. In a
| business setting this means using a new stack in a new app.
| yarone wrote:
| Like the Lotus 1-2-3 date workaround for Excel:
| https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
| d4mi3n wrote:
| > One especially crazy seeming one from today's perspective is
| that there's a separate implementation of event propagation, I
| believe because because it dates back to browsers that only
| implemented one half of event bubbling/capture!
|
| My oh my, that takes me back to the days of quirks mode and
| early versions of Internet Explorer. I made a good living
| through college helping design and ad agencies backport stuff
| to IE5/6/7 and became intimately familiar with the lack of
| event bubbling support and fan favorites like:
|
| 1. IE displaying a blank page with no errors whenever a CSS
| file of more than 4kb was loaded
|
| 2. Resolving CSS rendering issues between IE5/6/7 due to
| differing rendering strategies for the CSS box model
|
| 3. Debugging javascript in IE back when dev tools didn't exist.
|
| For all people harp on the current state of the web, we have
| come a long, long way.
| dmitriid wrote:
| > and nonzero risk (see point 1) without meaningfully moving
| any metrics you care about. In all, how to eliminate
| accumulated cruft
|
| Ironically, the other side which is Chrome can be quite blase
| about this. See the recent alert/confirm/prompt kerfuffle
| https://dev.to/richharris/stay-alert-d
| masklinn wrote:
| > One especially crazy seeming one from today's perspective is
| that there's a separate implementation of event propagation, I
| believe because because it dates back to browsers that only
| implemented one half of event bubbling/capture!
|
| MSIE only supported bubbling, Netscape 4 only supported
| capturing. The DOM Level 2 model (which combined both) started
| getting supported around IE5 / NS6 / Mozilla, though support
| would remain spotty for a while especially on the IE side.
|
| Microsoft's event model also worked off of a global
| (`window.event`) for the event information rather than a
| callback parameter which was fun.
|
| And there was no "current target" passed to the callback (or
| available on `window.event`), which meant you had to keep a
| handle on the event target from your callback, which caused a
| cycle between the DOM and Javascript, which created a memory
| leak by default: IE's DOM was a COM API, while JScript was its
| own separate non-com runtime. By creating a cycle between the
| two, the JS handle would keep a COM refcount > 1 on the page's
| DOM, and the event target would (through the event handler)
| keep a foreign JScript handle, and then neither could be
| collected.
|
| And because IE's COM instance was per-process the leak would
| live until you closed IE itself, every reload of the page would
| create a new document in COM, an event handler in JScript, and
| leak the entire thing. You had to explicitly break the cycle by
| hand by detaching your events during e.g. onunload.
|
| In fact there was a tool called "drip" whose sole purpose was
| to open a page in an HTML control, then loop reloading the page
| and counting COM objects. If the number increased, you had a
| leak (almost certainly due to an undetached handler), and
| now... you had to find where it was.
|
| edit: and the state of tooling at the time was... dismal is too
| kind a word. This was before Firebug and console APIs, so your
| tools were either popping `alert` for debugging (this was also
| before JSON support in browser so serializing objects for
| printing was neat) or installing a debugger, which were
| universally shit and only handled *javascript debugging:
|
| Mozilla had Venkman, which was dog-slow and had a weirdly busy
| UI.
|
| Microsoft had either the Script Debugger or Visual Studio's
| debugger. SD was extremely brittle and would crash if you
| looked at it funny while VS was heavyweight and expensive. SD
| was also completely unable to debug scripts at the toplevel (of
| JS files or <script> tags), it only worked inside functions. I
| don't think VS supported that either but I don't remember as
| clearly so it might have. The best part of that was that you
| could set breakpoints at the toplevel, they just wouldn't ever
| trigger.
| Joeri wrote:
| I totally forgot all the time I used to invest back in the
| day in working around those IE quirks. At one point I drew
| stats and figured out we spent a quarter of our frontend
| development budget on IE compatibility. Thanks for the
| memories.
| pmarreck wrote:
| Just a quarter?
| sroussey wrote:
| I got a shudder when you mentioned drip. Oy!
| IggleSniggle wrote:
| The longer I work in software, the more I see parallels to DNA.
| Yeah, sure this parasitic chunk of blueprint seems like it
| doesn't do anything, but it's not harming survival of the
| species, and hey, maybe it will serve some important purpose to
| the propagation of the larger supporting organism somewhere in
| the long long tail of probability.
|
| I've also adopted this truism, to help me away from pre-mature
| refactorings that I am prone to do: Clean code will either be
| discarded, or it will live long enough to get accidentally
| mutated into a mess that nobody wants to touch.
| quantum_mcts wrote:
| https://xkcd.com/1605/
| japanuspus wrote:
| My biologists friends on twitter were all up in the air about
| a "Vault Organelle"[0] the other day. Knocking out this
| organelle doesn't seem to do anything, but everyone seems to
| agree it must have some corner case function to still be
| around.
|
| The vault is not a new discovery, but since it doesn't exist
| in yeast or fruit flies it has somehow not gotten a lot of
| attention...
|
| [0]: https://en.wikipedia.org/wiki/Vault_(organelle)
| rapnie wrote:
| It works the same with bureaucracy in governments too. Stuff
| is too complex, so rather extend than refactor.
| wpietri wrote:
| Hah! I had the same thought. I proposed that after Y2K we
| shift all the old COBOL programmers to decoding the human
| genome, as 30-year-old code bases are the closest thing we
| have.
|
| In a few years I should make the same proposal but for all
| the Enterprise Java developers.
| wenc wrote:
| Python 3 was an attempt to remove cruft but it was drawn out
| and somewhat painful.
|
| Apple on the other hand has managed to reinvent itself
| successfully several times by controlling its vertical
| tightly, and each time it does it there's a natural shedding
| of cruft. I remember every single architectural move -- 68k
| to PPC to Intel and now to ARM, executed impeccably each
| time. Moving a developer ecosystem with the times is truly
| one of the harder things but Apple seems to have managed to
| pull it off each time.
| dtech wrote:
| That is not really the same. I wouldn't be surprised if Mac
| OS is still full of PowerPC specific code that just isn't
| easily identifiable as such.
| tambourine_man wrote:
| It's not. NeXT was already multiplatform in the 90s.
| dmurray wrote:
| This isn't really a "state of the web these days" complaint,
| it's what happens any time you ship cross-platform code. Look
| at any reasonably mature C/C++ codebase and you'll see plenty
| of '#ifdef _linux...#ifdef _OpenBSD...'.
|
| Having complete control over the environment your code runs in
| is the exception, not the rule, though the modern trend for
| SaaS might make you think that backend code looks cleaner than
| the frontend.
| vxNsr wrote:
| I'm curious as this is a closed source project, who does it
| exist? what market are they trying to serve?
| jitl wrote:
| Anyone who wants to run a high performance browser on minimal
| hardware. Eg browser on TV set top box, embedded point of sale
| device, etc.
| ybot2 wrote:
| I used to develop Set Top Box user interfaces that used the
| Ekioh browser. We'd use SVG, JavaScript and CSS to get native
| UI performance in a browser that was running in 256MB ram.
| Their later versions enabled us to use HTML5 and CSS3. I
| enjoyed the challenges of balancing UI animation against
| capturing keypresses and other events as well as executing
| JavaScript fetched via AJAX. Due to the memory constraints we
| couldn't use any JavaScript frameworks and wrote everything in
| vanilla JS.
|
| Our C and C++ developers would expose the native hardware
| functionality up into the JavaScript Ekioh engine so that we
| could access and control features like scanning cable TV
| frequencies and recording to disk.
|
| The cable and satellite TV networks would end up paying a
| licence per instance of the browser running on each of their
| customers set top boxes.
| devwastaken wrote:
| *Closed source browser.
|
| Flow is yet another project pulling on open source resources, and
| the browser market created from open browsers, and trying to
| privatize it. Imagine if google could just make whatever internal
| changes to chromium and nobody knew about it.
| [deleted]
| kiryin wrote:
| Imagine the irony of fate if they not only did that, but also
| had the audacity to call the resultant browser "Chrome." Makes
| me shudder.
| cxr wrote:
| One side effect, intentional or not, that came from Google
| naming their browser "Chrome" was that Gecko development
| become more difficult. It became too hard to get search
| engines (you know the one) to understand that you weren't
| looking for Google blog posts and press releases, but instead
| developer documentation for Mozilla internals, which you
| could have pretty reliably found previously by including
| "chrome" as a useful search term.
| breakfastduck wrote:
| > "yet another project pulling on open source resources"
|
| Erm, yeah. Isn't that the point of making something open source
| with a permissive license? So that other people are able to use
| it in their own projects?
| ronsor wrote:
| I feel like a lot of people choose permissive licenses due to
| inertia while not really understanding them.
| wpietri wrote:
| Legally for sure. But from an ecosystem perspective, it's
| reasonable to be concerned about people whose relationships
| to a commons is essentially extractive. When I use open
| source in commercial offerings, I see it as both morally
| appropriate and good business to contribute back in one way
| or another.
| maccolgan wrote:
| Why not use GPL/AGPL/LGPL as it's clearly more appropriate
| in this case?
| wpietri wrote:
| From my perspective as an open-source consumer, that
| doesn't matter much. The license tells me what I can
| legally get away with. But what I care about
| pragmatically is whether that project will keep existing
| and improving such that it will meet my needs down the
| road. And what I care about morally is maintaining
| positive-sum relationships with my community and society.
| [deleted]
| formerly_proven wrote:
| > Imagine if google could just make whatever internal changes
| to chromium and nobody knew about it.
|
| Chromium is BSD licensed so Google absolutely can just make it
| closed source.
| chubot wrote:
| Just to clarify the relevant thing is whether Google owns the
| copyright to Chromium source, and it does for a huge part. It
| can license that code however it wants, including open
| source, or no license at all.
|
| Chrome/Chromium also uses a ton of open source libraries for
| which Google does NOT hold the copyright, but all of them,
| per their license, can be linked with closed source code and
| distributed (i.e. they are not GPL/copyleft).
| est31 wrote:
| The BSD license only applies to some code from what I can
| tell. Other code is still under LGPL. At least this is what
| this file tells me:
|
| https://chromium.googlesource.com/chromium/src/+/refs/heads/.
| ..
| empyrical wrote:
| Yes, there's code in Chromium going back to the KDE/
| Konqueror and WebKit days that's LGPL licensed. Mostly in
| the Blink rendering engine like you linked.
| [deleted]
| JumpCrisscross wrote:
| > _yet another project pulling on open source resources_
|
| And? It's a product people find useful enough to pay for.
|
| Open source is by default provided to the world freely. If
| someone is opposed to it being use freely, in any way the
| person on the other side chooses, including commercially, there
| are licenses that can proscribe that.
| SahAssar wrote:
| > Imagine if google could just make whatever internal changes
| to chromium and nobody knew about it.
|
| If you use chrome, they do. Chrome has a lot of changes and
| additions that are not in the open-source chromium codebase.
| timw4mail wrote:
| I would be a lot more impressed with this browser engine if I
| could actually see it working.
| timw4mail wrote:
| Apparently there's a preview for Raspbian:
| https://support.ekioh.com/download/
| youngtaff wrote:
| It's been available for a while...
|
| I download and try it every couple of months to see what
| their progress is like
| sysadm1n wrote:
| Yes but what's a 'clean-room browser'? The article doesn't
| explain what that term means.
| kilovoltaire wrote:
| https://en.wikipedia.org/wiki/Clean_room_design
| blagie wrote:
| Technically, color me impressed.
|
| Business-wise, I'm skeptical:
|
| - Alternative browser engines have always fallen behind,
| eventually.
|
| - Open-source is a huge win for most embedded applications.
|
| - Having a big company backing something is a huge win too, since
| something like Webkit ain't going away.
|
| I think one possible outcome here might be an acquisition.
| Microsoft was forced to eat crow with Edge adopting Google's
| engine. This would be an opportunity for Apple, Microsoft, or
| Amazon to leapfrog Google. A GPU or multicore-accelerated browser
| could make the iPhone/Macbook/etc. much more responsive than
| Chrome.
|
| Another might be some open-source strategy, but I don't quite
| know what it might be.
| Y_Y wrote:
| Maybe someone benevolent could buy it. Probably not Mozilla,
| but what about a big FOSS outfit like GNU or Apache or
| Raspberry Pi. I think I'd even be willing to break my embargo
| on crowdfunding to promote such a crucial bit of the web.
|
| Firefox is great, but I don't want to put all my chickens in
| that basket. WebKit is alright but has many drawbacks
| documented elsewhere. Any other engines are too broken on the
| "modern web" that society demands we use. A healthier ecosystem
| will less dependence on Google would be good for just about
| everyone.
| pas wrote:
| None of those (GNU, Apache, rPi) ever bought anything, they
| get projects donated to them, but even then they lack any
| real resources to invest into such huge projects.
| dmitriid wrote:
| And for a while Apache was where projects went to die.
|
| Thankfully, there are more active and growing projects now.
| rahimnathwani wrote:
| There are bunch of use cases listed here:
| https://www.ekioh.com/solutions/
| javajosh wrote:
| Acquisition seems natural, because this would be a great
| component in a Pi-focused set-top box experience, competing
| with RokuOS.
| ajb wrote:
| They aren't huge, but there is a market for these embedded
| browsers. Ekioh has been around for 15 years.
| gsnedders wrote:
| And they haven't undergone huge growth to make Flow possible,
| so I don't think there's any reason to believe they'll be
| less viable now than they have historically been.
| ReactiveJelly wrote:
| Doesn't WebKit already have a lot of GPU and multi-thread /
| multi-process acceleration?
|
| Even Gecko does now.
| sroussey wrote:
| Blink and V8 also use GPU and multiple threads.
| derefr wrote:
| "Adopting Google's engine" is an interesting turn of phrase.
| There's still more Apple-contributed code at the core of Blink
| than Google code. It's not like Google did a full rewrite when
| they forked Webkit to create Blink.
|
| When you think about it, at this point the Chromium project
| (including the Blink engine) has "contributions" in some sense
| or another from Microsoft, Google, Apple, and KDE. Certainly,
| it's a project mostly _run and stewarded_ by Google employees
| in their off-hours; but there are actually a lot of interests
| involved! (Especially now; I expect Microsoft has likely
| switched their Edge browser engineering team to to writing PRs
| for Chromium.)
| tonyedgecombe wrote:
| >in their off-hours
|
| Is that really the case, I always imagined they had a full
| time team on it.
| crakenzak wrote:
| That's not true, there's plenty of people working full time
| on Blink.
|
| Source: I work at Google on the Chrome team.
| gsnedders wrote:
| They've the largest browser team, by a decent margin.
| zaphar wrote:
| They do. Google employs a lot of engineers on fully open
| source work including but not limited to Chromium.
| derefr wrote:
| To be clear, what I meant is that projects with open
| _stewardship_ (which I believe the Chromium Project is?
| unclear from the project website) don 't tend to want
| _employees of companies, in their capacity as employees-of-
| companies_ to be directors /core maintainers for the
| project. Which is different from being regular developers
| on those projects.
|
| Open-stewardship projects tend to be happy to accept
| _contributions_ from companies; and they tend to be happy
| to accept the stewardship of _individuals who happen to
| work at companies_ ; but they don't want to be _beholden_
| to the interests of those companies in their direction, so
| projects with community /foundation stewardship don't
| usually allow companies to pay their employees for their
| time spent sitting on that foundation's board. (I.e. they
| let companies pay employees to _write code_ , but they
| won't allow companies to pay employees to do the work of
| _deciding whether that code belongs upstream_.)
|
| Instead, the software foundations that manage FOSS projects
| usually legally restrict corporations or their
| representatives from participating in their capacity _as_
| representatives of corporations in directorship /steering
| committees/etc. for the foundation. Instead, they
| expect/require each person with decision-making authority
| in the foundation to have their own individual voice--to
| not be just a sock-puppet of a company, saying whatever the
| company wants you to say. When you vote for things in the
| foundation, you have to be able to vote _for_ the interests
| of the project itself, even if those interests are
| _against_ the interests of the company you work for--
| without that endangering your job.
|
| Which usually means that employees of such companies must
| do their foundation maintainership "off the books" of the
| company they work for, e.g. at non-work hours using non-
| work equipment. Just as if they were trying to avoid IP
| cross-pollution.
|
| Source: worked at a company with an "open core" product,
| where the core was an Apache Software Foundation project,
| and most of the ASF project's maintainers _happened_ to be
| employees of the company. Those people could push a PR to
| the ASF upstream for consideration from their work account,
| as a representative of the company; but they then had to
| don their personal-gmail-account, separate-profile, no-
| corporate-affiliation hat to handle the PR and discuss it
| with the other maintainers.
| mda wrote:
| I don't think your claim is entirely accurate. Google's blink
| and Webkit are probably very different after all these years.
| And even at the very beginning of Chrome, Google had to make
| quite a bit of changes because of Chrome's process /
| sandboxing model , which was the main reason for the fork
| later (also related adaptations for skia graphics engine and
| v8) See [1].
|
| Besides html rendering is only a portion of what makes a
| browser. considering today's Chromium codebase as a whole, I
| would guess probably >80% of it was written by Google
| engineers (and certainly not in their off hours). Still I
| would consider it a successful open source project as now it
| has quite diverse contributors, (Non Google contributors now
| amount to ~30% [2], biggest are Microsoft, Igalia, Intel
| etc.).
|
| [1] Slides from 2013 https://events.static.linuxfound.org/sit
| es/events/files/slid...
|
| [2] BlinkOn 14 keynote: https://youtu.be/VrEP7SPfQVM?t=408
| derefr wrote:
| > and certainly not in their off hours
|
| To clarify: I implied that Chromium is _run and stewarded_
| in Google employees ' off-hours, which is different from
| the project being _developed_ in Google employees ' off-
| hours.
|
| Of course Google pays people to work on Chromium. But do
| they pay people to decide what makes it into Chromium?
|
| If so, that's a very bad look for a FOSS project. One of
| the central points of having a separate standalone
| community-driven FOSS project in the first place (rather
| than a corporate "source-available and we accept PRs if you
| assign us the IP" project), is taking steering of the
| project away from the corporation that created the code,
| and placing it instead in the hands of the community. If
| Google employees serve _in their capacity as Google
| employees_ as directors for the Chromium Project -- and so
| Google can tell its employee-maintainers to reject a PR
| from Chromium because it 's not good for Chrome -- then how
| could a browser vendor producing a competitor to Chrome
| based on Chromium, trust the direction of Chromium to do
| what's best for _all_ Chromium-based projects, rather than
| just Chrome?
|
| I assume this _is not_ the case; that Google employees not
| only don 't direct the Chromium Project with backroom
| Google-internal decision-making, but _are restricted
| legally_ from so doing. Though I can 't find anything on
| the Chromium Project site to support that assumption...
| jenny91 wrote:
| I don't think Chromium is that kind of open source
| project. It doesn't seem that having the FOSS community
| leading the direction of dev is something they do. If you
| read some of the docs it seems that Googlers have special
| privileges and it's quite intertwined.
| nightpool wrote:
| I'm not sure I understand why you think Chromium is
| supposed to be community driven. Chromium is an open-
| source project that has a lot of Google and non-Google
| contributors (for example, Microsoft), but all of the
| main decision-makers are working on Chromium on behalf of
| their companies, and the majority of decision-makers are
| employed by Google.
| Jyaif wrote:
| > There's still more Apple-contributed code at the core of
| Blink than Google code.
|
| Not sure about that. Even before the Blink fork, Google was
| the main contributor to WebKit. See the first two graphs at
| https://hypercritical.co/2013/04/12/code-hard-or-go-home
| throwaway744678 wrote:
| Also, a large part of the browser is the javascript engine,
| which I believe they do not share.
| ronsor wrote:
| V8, the JavaScript engine used in Chrome, is fully open
| source. Many projects (including node.js) use it.
| pas wrote:
| Maybe the parent comment meant that Chrome and Safari
| don't share the same JS engine. (As Safari uses
| JavaScriptCore aka. Nitro.)
| eitland wrote:
| The code will probably be available.
|
| As far as I can see the bigger problem isn't the code but a
| viable ecosystem, somewhere customers can go if Google
| doesn't behave. Let me explain:
|
| As long as Firefox is alive and kicking Google cannot kill ad
| blockers on Chrome as they realize that will create an
| enormous backlash, massive PR and users flocking to Firefox.
|
| Once Firefox is gone the network effects will be strong
| enough that they can eventually kill adblocking and people
| will be stuck with Chrome anyway.
|
| Blame it on regulations or big media or whatever but I am
| certain they will do it if they get a chance.
|
| Chromium source code might still be available but will not
| work on Gmail or Google Docs or Netflix, only on enthusiast
| websites :-/
| Joeri wrote:
| You really think google would walk away from all those
| safari users, especially on mobile, by forcing chrome? This
| seems ... unlikely.
| eitland wrote:
| Sorry, I forgot, at the moment Safari might - more or
| less voluntarily - be a more important defender of the
| free web than Mozilla.
|
| It just so happens that Mozilla and Firefox is still on
| top of my mind because of how good they were back before
| they changed management.
| bbarnett wrote:
| I wonder.
|
| For phones/tablets, Apple doesn't want anyone using the
| web for apps, insisting on app store (and fees) for all
| transactions.
|
| If Google came along with a deal to switch to Chrome,
| would modern, post-Jobs Apple go along?
|
| Unless something had changed, they already accept cash to
| funnel Safari users to Google by default. And Google apps
| somewhat compete with Apple products.
|
| So... why not more cash, and make Chrome Safari's guts?
| nyanpasu64 wrote:
| Ad blockers are already dead on Android Chrome. I wish more
| people would use ad-blocking browsers, perhaps Firefox, but
| Fenix is somewhat slower than Chrome, and is a software
| train wreck of bugs.
| trulyme wrote:
| What bugs? Ff had an upgrade not long ago where they made
| it difficult to use extensions, and the UI has been made
| worse (or I'm just old and set in my ways), but bugs? It
| just works. If it is slow, I never noticed.
| nyanpasu64 wrote:
| I'm using Firefox Nightly, but many of the issues are
| present on release too:
|
| - Saving images doesn't send the cookies, so you can't
| save images gated behind a login. (over 1 year old, not
| fixed, #17716)
|
| - Switching tabs (by swiping the address bar) sometimes
| shows the old tab's contents/interaction, with the new
| tab's address bar. (unsure if reported, I should report
| it.)
|
| - The menu shows a "sign in to sync" or similar prompt.
| When I click it, the settings screen shows me as logged
| in. When I close the settings screen, the menu shows me
| as logged in. (#19657, possibly #19036 too)
|
| - Reopening a tab moves it to the very top of the list,
| before your _oldest_ open tab. (fixed in nightly, #10986)
|
| - Opening the tab menu scrolls you to a random place,
| rather than the currently open tab. (got fixed a few days
| ago. #20637, possibly #20960 too.)
|
| - Reader mode randomly switches to default theme (fixed a
| few months ago, #17865)
|
| The tracker is at https://github.com/mozilla-
| mobile/fenix/issues.
|
| The impression I get is that Firefox Mobile is shipping
| broken code and unwanted redesigns, and testing in
| production. Perhaps it's from a lack of engineering
| culture and management. Looking at issues like
| https://github.com/mozilla-mobile/fenix/pull/21038, I
| feel Mozilla is more interested in marketing, design, and
| analytics, than solid engineering. It's nauseating and
| depressing to see Mozilla fall so far.
| mdoms wrote:
| Ok I'll ask seeing as it's never defined in the article: what is
| Flow and why should I care?
| banana_giraffe wrote:
| As I understand the sales pitch for Flow, it's a browser that
| can run on low power devices and remain responsive and useful.
|
| Never used it myself, it was one of the possibilities we looked
| into recently for a set-top-box thing that would render most UI
| with a browser.
| kiryin wrote:
| Words can not express the relief it is to see a completely new
| web browser rendering engine being developed. It's heartbreaking
| that it's proprietary, my initial wish was that they'd open up
| after it matured a bit. Still hopeful though, the browser
| landscape needs diversity and preferably in the form of something
| that isn't carrying 3 decades worth of baggage.
| freediver wrote:
| It is quite reasonable for it to be proprietary as developed by
| a small team that still needs to see return on its investment.
| Last thing they need is someone with a pile of cash and/or
| reach taking their engine and launching a new browser with it,
| stealing their thunder.
|
| Monetizing a browser is not easy if you are not in the data-
| monetization game.
| nerdponx wrote:
| > Monetizing a browser is not easy if you are not in the
| data-monetization game.
|
| How do we know that they aren't?
|
| It's like free money for a tech company. There's little or no
| disincentive, and they don't have to do a lot of extra work -
| the data is already sitting around waiting to be collected.
| z3t4 wrote:
| How can I test this browser to make sure my web sites works on it
| !?
| sharmin123 wrote:
| Let's Secure WiFi Network and Prevent WiFi Hacking:
| https://www.hackerslist.co/lets-secure-wifi-network-and-prev...
| gadders wrote:
| Very offtopic, but the name of the author - Piers Wombwell -
| would make a great name for an Ob/Gyn.
| EamonnMR wrote:
| I'm refreshed that Flow does not have its implementation language
| on the front page.
| [deleted]
| Y_Y wrote:
| As much as I'm irked by language partisanism, that's typically
| justified on the basis of ease of installation or attracting
| developers. Since this otherwise great looking product is a
| closed source binary then it would be hard to justify.
|
| (Although I bet it's not in Rust, because then they'd surely
| say it anyway.)
| gsnedders wrote:
| (It's C++)
| marcodiego wrote:
| Web does not want another closed browser.
___________________________________________________________________
(page generated 2021-09-20 23:00 UTC)