Verbosity is not Java's fault - <AUTHOR> http://schneide.wordpress.com/2010/02/08/verbosity-is-not-javas-fault/ <comment><USER2> The call to action is worth pondering. Can Java's verbosity be eliminated? Maybe not. Can Java programs be made to be less verbose through better design? Yes!

It isn't the author's fault, but reading articles like this make me feel like Java supporters want it both ways. They point to Java's tooling and vast herds of libraries as benefits, but when you point out flaws in some implementation they say the language isn't the fault, it's that particular library.

On the other side, when criticizing languages like Ruby they are quick to point to practices like monkey-patching as examples of how Ruby permits abuse in practice.

Well, which is it? Do we compare languages on the basis of the actual libraries and programs people write? Or do we compare them on the basis of the libraries and programs they could write if they took advantage of the language's features and also had a keen sense of design?

<comment><USER3> _Well, which is it?_

It's both. A Language-with-a-capital-L _is_ the libraries it includes, the libraries it allows, and the libraries it makes unnecessary.

</comment></comment><comment><USER4> Clojure code uses the same APIs all the time, but manages to be much shorter.

Java's verbose APIs _are_ Java's fault, because Java doesn't provide metaprogramming tools to make the boilerplate go away.

<comment><USER5> It may just be me, but interfacing with Java in Clojure is still pretty verbose when compared to regular clojure code. I think you at least have to grant the author that API verbosity is a factor.

</comment></comment><comment><USER6> It is, to some extent, Java's 'fault' although it's fuel for endless flamage how much that is a fault.

Some stuff is just plain verbose, in part due to lack of type inference -

      EndlessParametrizedType foo = new EndlessParametrizedType()

As to the APIs, some of it is due to excessively baroque APIs. But even with a well-designed API, in order to provide a reasonable amount of flexible functionality, a lot of the internal structure of the implementation is often exposed so it can be accessed. This is a consequence of static typing - in a dynamic language, you're more likely to just reach into the bowels of an object and pull out, change or replace bits you want. This isn't an option in Java and a flexible API ends up being a composition of a lot of smaller APIs. In the standard library, it's often left to others to provide a simple layer on top that covers the base cases - for instance, Apache Commons mail for Java Mail.

</comment><comment><USER5> This post has quite possibly the _worst_ name ever. I mean really: who cares whose _fault_ Java's verbosity is? I think it obscures the author's true intent: to show that Java could be made much less verbose given a less verbose standard library.

Note: I'm not necessarily saying that I agree with the author.

</comment><comment><USER7> Lies. Java is intrinsically verbose. Say I want to make a class with a read- only attribute "Foo".

CLOS:

       (defclass class () ((foo :reader get-foo :initarg :foo)))

Moose:

       class Class {
           has 'foo' => ( is => 'ro' );
       }

Java:

       class Class {
           private String foo;

           public Class(String foo) { // named initargs are clearly for losers
               this.foo = foo;
           }
       };

Notice how a common high-level task requires a manual error-prone implementation, every single time. Java provides only the concepts of "class", "field" and "constructor", while the other languages provide the high-level concept of an "attribute", which is what the programmer actually wants. (The first concept is easy for the language implementor, the second concept is easy for the practicing programmer.)

I should also point out how the verbosity exists only for the sake of being verbose, not for creating more reliable software. Perl and CLOS assume I want named initargs, making use of my class self-documenting:

       (make-instance 'class :foo 42 :bar 123)

       Class->new( foo => 42, bar => 123)

That's verbose, but it makes the code very easy to read and write. No guessing about what slot is being set to what value.

With Java, though, it's anyone's guess as to what's going on:

       new Class(42, 123);

The only way to know which field gets set to which value is to Read The Fine Source:

       public Class(int bar, int foo){
          this.foo = bar;
          this.bar = foo;
          System.Utils.delete_users_pr0n_stash();
       }

foo does get set to 42, but only by accident... and there are unexpected side effects.

So much less typing though! _cough_.

Another common programming pattern is reusing code. (I hear people like doing that.) Say you have classes representing numbers, and you want to add a "not equals" method to each type. That's easy, you can just write a generic role like:

        role Eq {
            requires 'equal';
            method not_equal($a: $b){
                return !$a->equal($b);
            }
        }

Then I can easily reuse that extremely-complex "not_equal" method:

        class Int with Eq {
            has value => ( is => 'ro', required => 1 );
            method equals($a: $b){
                return $a->value == $b->value;
            }
        }

       Int->new( value => 42 )->not_equals( Int->new( value => 123 ) ); # True

In Java, I can still maintain a similar interface:

       interface Eq {
           public bool equal(Eq that);  // Eq is not really the type I want, but whatever.
           public bool not_equal(Eq that);
       }

But the implementation can't be shared:

       class Int implements Eq {
           private int value;
           public Int(int value){ // didn't we just say "int value" like one line ago?
               this.value = value;
           }

           public bool equal(Int that){
               return this.value == that.value;
           }

           public bool not_equal(Int that){
               return !this.equal(that);
           }
       }

This is both verbose and error-prone. (I will also point out that Java calls Eq "Comparable" and uses the "implements" keyword instead of "with". But this is petty. I'm surprised they were happy with "implements" and didn't choose the clearer expression "implementsTheInterfaceThatIAmAboutToTypeRightAfterIAmDoneTypingThis". Your editor can type that for you, after all...)

But wait, we can use the strategy pattern to save us!

       class NotEqualStrategy {
           public bool not_equal(Eq a, Eq b){
               return !a.equal(b);
           }
       }

       class Int {
           private NotEqualStrategy not_equal_strategy;
           private value;

           public Int(NotEqualStrategy nes, int value){
               this.not_equal_strategy = new;
               this.value = value;
           }

           public bool equal(Int that){
               return this.value == that.value;
           }

           public bool not_equal(Int that){
               return not_equal_strategy.not_equal(this, that);
           }
       }

At least I don't have to cut-n-paste the logic anymore, but it's still very verbose. Imagine you had to delegate more than one method -- you can do it, but it involves a ton of meaningless code.

In Perl, I can just say:

       class NotEqualsStrategy {
           method not_equal(Eq $a, Eq $b){
               return !$a->equal($b);
           }
       }

       class Int {
          has 'not_equals_strategy' => (
              is       => 'ro',
              isa      => 'NotEqualStrategy',
              required => 1,
              handles  => ['not_equal'],
          );

          has 'value' => ( is => 'ro' );

          method equal(Int $a: Int $b){
              $a->value == $b->value;
          }
       }

Notice how I didn't have to type the cut-n-paste delegation; the language did it for me. I didn't have to type it, I don't have to look at it, and I can't accidentally fuck it up. That's what programming languages are supposed to do for you, and that's what Java doesn't do.

In conclusion, Java is verbose, and verbosity is harmful.

<comment><USER8> Lets just take your first example.

I read those exactly the same. There's no difference to me apart from taste, and potential for errors.

The potential for errors however, is far higher with the Moose and CLOS versions. Which is why I wouldn't like to use either of those syntax in a large project.

The java version, you can only really typo on the variable name. And even if you do that it likely won't compile unless your variables are similarly named. But with the moose example, you're starting to have silly things like '=>' which can easily be typoed and which can still compile, but completely change the meaning of the code.

Obviously at the extreme of this is regexp. Hugely compact, but a complete bitch if you typo anything. Personally I'd hate to write complete programs in regexp type syntax.

So you can keep your non-verbosity at the expense of sanity.

>> "In conclusion, Java is verbose, and verbosity is harmful."

I'd say Java has longer tokens than some other languages. By my definition that doesn't make it any more verbose. It makes it harder to go wrong with typos etc.

If you look at the underlying programming constructs in your first 3 examples, they're the same... thus for me, those code fragments are the same. No more or less verbose.

I think some of it just comes from having experience of reading code. Once you learn to read code in terms of programming concepts, rather than actual lines of code, you see no real difference.

<comment><USER7> The big issue is having to manually feed data from the constructor into the fields. There is no high-level concept of "attribute" in Java, which is what programmers actually want.

In Perl, you say "has foo => ( init_arg => 'foo', isa => Whatever, reader => 'get_foo', writer => 'set_foo' )" and the correct code is generated. In Java, there is no concept of "attribute", so you have to build it every time by manually declaring the field, manually writing the constructor, and manually writing the getters and setters. Anything you do manually more than once has the potential to introduce a subtle bug, and more importantly, is tedious and degrading.

<comment><USER8> It'd take you 2 minutes to write a java preprocessor to build your constructors if you really care about such things. (I don't particularly. I don't spend much time at all writing constructors, and often want to do nonstandard things, validation etc rather than just passing over variables as they are given).

With due respect, surely that's what being a good programmer is about? There's no law against preprocessing java if you really dislike the defaults.

How many constructors do you write? Sounds like perhaps too many.

<comment><USER9> But almost everything in Java is more verbose, and so you'd end up writing "preprocessors" for everything (and the strong, static, explicit typing means that a lot of this preprocessing would have to be rewritten for even slightly different cases).

So why not just cut-out the middle man and work in a higher level language directly?

<comment><USER8> >> "But almost everything in Java is more verbose"

Sure, that's the common misconception. You're correct. However, if you actually look at the language and write stuff in it, you'll find it's not actually true.

The issue is when people look at some existing insane Java code and cite it as proof Java is verbose.

I'd absolutely agree - most open source / freely available Java code is verbose. Several of the libraries (enterprise etc) are verbose and insane. But that's not Java.

Higher level languages are not always better. Use what is suited to the job at hand. I'm far more comfortable working at lower level than high level.

Which is better.... talking high level and relying on a compiler/runtime to figure out what you want? or just talking a bit lower level in the first place.

</comment></comment></comment></comment></comment></comment><comment><USER10> Conveniently ignoring the fact that Java, by default, includes lots and lots of unnecessarily verbose APIs, and in many cases you're stuck using them - then yes, verbosity is not Java's fault.

<comment><USER11> Yeah, a more accurate title could have been: Java's verbosity is due to its API, not the underlying language. It's still somewhat interesting to me to decouple the two, though. There are some things that are verbose and cumbersome in Java due to the way the language fundamentally works: for example, no anonymous functions means that if you want to pass a simple one- time-use function to _sort_ , you have to _create a whole new file_ with your sort functor. But the examples in this blog post could've been fixed by just having designed the API differently, or even had the same underlying API but added a set of convenience wrappers for the common cases.

<comment><USER6> _you have to create a whole new file with your sort functor._

You don't. You can use an inner class. An anonymous one, if you like. It's more verbose than your typical lambda expression but it's not 'a whole new file' by any stretch.

<comment><USER11> Ah right, I'm not sure why that skipped my mind; I've even done that before. I suppose that adds to the general view of the linked post that Java-the- language isn't actually inherently that verbose, but the JVM APIs are.

</comment></comment></comment></comment><comment><USER12> Response myResponse = new Response();

ResponseType myResponseType = responseTypeFactory.CreateNewDisagreementResponseType();

responseManger.SetResponseType(myResponse, myResponseType);

return myResponse;

<comment><USER13> You're just agreeing with him though - the only bits of Java, as opposed to API, in there are [()=;.], 'new' and 'return'.

<comment><USER7> But of course, you can't actually put just that in a file and expect it to compile. You have to wrap it with class whatever public static void main ....

</comment></comment></comment><comment><USER14> True. Most of the time I end up making a very thing wrapper over the original API, just for the sake of brevity. I honestly thought that's what I was meant to do: the API should be optimized for power, and the local wrapper for usability in the local context.

But it's also a matter of style. I just wrote a function the other day to do the equivalent of:

        Map m = makeMap( "key1",  "value1",
                         "key2",  "value2",
                         "key3",  "value3" );

It's perfectly ok to write something like this in java using varargs, but because of ... I don't really know, habituation I guess, it took me learning Clojure to actually think of writing it.

</comment><comment><USER15> These attempts to deny the obvious are so futile. The lack of object literals, list comprehensions, parameter default values, keyword parameters, generators (yield), first class functions, property syntax, type inference, macros, etc clearly make Java exceptionally verbose.

The author's argument seems to be that Java the language cannot possibly be criticised for being verbose as the verboseness of the language clearly pales in comparison to its outrageously verbose APIs. Not a good line of defense in my view.

</comment><comment><USER16> Of course it's Java's fault ... sure, you can design clean and easy-to-use APIs but it takes a considerable amount of effort and Java doesn't help you.

I simply don't get some of its design choices ... operator overloading is not harmful if implemented right, checked exceptions were a bad idea, and why can't it have local type inference or proper closures and why can't developers define their own stack-allocated primitives? Where these really that hard or dangerous to blend in?

<comment><USER17> Yes, it would help a lot if Java at least had a type inference system like scala does.

A lot of the time and effort that goes into programming is used to make code more compact and readable. That's hard to accomplish in java.

</comment></comment><comment><USER18> Interesting points on library design to do the heavy lifting (especially the HTML document regular expression example). Still, the main point of the article is not right: Scala is much more concise than Java (as is Clojure). Article was worth reading however.

</comment><comment><USER19> Isn't it the case, that most places will require an application in java and with most people knowing only the official API, noone will write code for some custom one that is company-specific? IMO yes - it is Java's official API, it is Java's fault.

</comment><comment><USER8> Bad programmers create real verbosity. Language choice is largely irrelevant to that.

And by verbosity I mean real verbosity. Not the ill advised measure of 'lines of code' or 'tokens'.

A good programmer can write _extremely_ concise well written Java.

Don't waste too much time on this sort of fluff, or chasing the next 'hot' language. Spend it learning how to become a better programmer.

I'd say the main reason Java is wrongly associated with verbosity is two things - It's widely used in corporate environments, where people are taught to do things inefficiently and in the most number of lines possible, and secondly, the use of IDEs, leading to lots of verbose automatically generated crappy code.

<comment><USER7> I would like to read some of this "concise" Java.

 _Don't waste too much time on this sort of fluff, or chasing the next 'hot' language. Spend it learning how to become a better programmer._

Bad languages get in the way of becoming a better programmer -- they make you program the language rather than program your program. I contend that Java is one of these bad languages. It is too low-level to really let you focus on programming.

<comment><USER8> I've never 'programmed the language'. In any language I've used.

I don't understand how people get this mindset. Languages are a moot point. They're all basically the same give or take a few matters of taste (And as I mentioned the probability of typoing and not being caught by compiler/runtime).

>> "It is too low-level to really let you focus on programming."

Sad you feel that there is no place for low-level programming, I personally find it the most rewarding and enjoyable. I certainly come from the Assembly world though, so perhaps why I don't see much wrong with Java. But you can't say enough times "Choose the tool that best fits the task at hand".

>> "I would like to read some of this "concise" Java."

Can't really help you there, I haven't seen much well written Java out there in open source projects etc. A lot of it absolutely stinks.

Just one data point though, The webserver I use for Mibbit (http,https,async,comet,websocket,sessions,etc) comes in at 6289 LOC. Functionally it's quite a bit ahead of tornado (5803 LOC). So concise Java certainly exists and can be written by competent programmers.

<comment><USER7> So basically, all Java is bad except yours, and I can't see yours.

<comment><USER8> You're confusing languages with programmers.

 _programmers_ make good code. Not languages.

Would shakespeare be worse had he written it in French? Do we spend ages moaning about how needlessly verbose it is in English?

<comment><USER7> So... if there is no good Java, then there are no good Java programmers. Why is that?

<comment><USER8> Or maybe Java programmers are just not the type of programmers who dump their code on the internet for free?</comment></comment></comment></comment></comment></comment></comment>


BOINC – Berkeley Open Infrastructure for Network Computing - <AUTHOR> http://boinc.berkeley.edu/ <comment><USER2> This project is 14 years old, and was originally created for finding extra- terrestrial signals with SETI@home

</comment><comment><USER3> I've been using BOINC for years now on my Android Phone, it's App is amazingly well written, but it's missing one feature: Finish on AWS.

The idea came to me recently when I had a Task that was 70% in completion but only hours away from its overdue date. At that moment some part of me would have paid 5$ to see the task finished on an AWS instance so the work of my trusty little phone wasnt for nothing.

It's wasteful and stupid from a personal point of view... But it triggers the same feeling some mobile games trigger + I wouldnt buy virtual crystals but actual scientific data.

</comment><comment><USER4> I've played with this, once upon a time it used to be a screensaver - you can run this headless now.

The idea to pair up worthy projects (think scientists folding proteins or doing something computationally intensive) with spare cycles is an old one.

I'm not sure how efficient this approach is. I got the impression when I tried to donate some cycles recently (spare servers) that its not widely used. Anybody has any experiences they would like to share? I'd love to hear.

<comment><USER5> BOINC itself is the white-label open-source[1] tech that other projects use, including SETI@home. I participate in IBM's World Community Grid[2] project, which uses the BOINC client. (it's running on my home machines, including some old/spare Android devices)

The IBM project is definitely active — their homepage currently says there are 721k volunteers participating, and there's a monthly email newsletter that covers their sub-projects' progress.

For an example of a current project, see OpenZika[3].

I see projects like BOINC and Jason Scott's ArchiveTeam Warrior[4] as a sort of "botnet for good" — if you have some bandwidth + margin in your monthly electricity budget, why not? I'm essentially spending a bit of electricity each month to help contribute to (and be a participant in) these projects. Their marketing must be working, because it "feels good" to be a part of them. :)

I don't know enough about CPU use + electrical costs to truly gauge the impact of my devices, e.g. vs. spending the same amount of $ on a fast, modern server running on clean power in an Icelandic datacenter. But having an old laptop or two + a few old Android devices running 24x7 hasn't noticeably appeared on my monthly PG&E bill.

[1] [https://github.com/BOINC/boinc](https://github.com/BOINC/boinc)

[2] [https://www.worldcommunitygrid.org/discover.action](https://www.worldcommunitygrid.org/discover.action)

[3] [https://www.worldcommunitygrid.org/research/zika/overview.do](https://www.worldcommunitygrid.org/research/zika/overview.do)

[4] [http://www.archiveteam.org/index.php?title=ArchiveTeam_Warri...](http://www.archiveteam.org/index.php?title=ArchiveTeam_Warrior)

<comment><USER6> I am wondering if it's more efficient to spend CPU cycles of PCs and mobile phones at home at the cost of increasing the electricity bill or to donate the same amount directly to the project so that they can use it for optimised (GPU?) servers that have better computational power per dollar.

</comment></comment></comment><comment><USER7> There is now a crypto currency that works with BOINC. Here is the website: [http://www.gridcoin.us/](http://www.gridcoin.us/) Annual inflation is 4% at the moment.

</comment><comment><USER8> BURP uses this for networked render farms (specifically for Blender, I believe). Not sure how active it all is though. [https://burp.renderfarming.net/](https://burp.renderfarming.net/)

</comment><comment><USER9> I love BOINC! My first serious research project was to try and parallelize some experiments using BOINC installed on all our library computers.

The resulting throughput wasn't much faster than our servers at the time, but was a fantastic learning experience.

</comment><comment><USER10> "Locating stolen computers"

[http://boinc.berkeley.edu/wiki/Locating_stolen_computers](http://boinc.berkeley.edu/wiki/Locating_stolen_computers)

An unexpected useful feature!

<comment><USER11> If memory serves me right, this was added after someone traced down their stolen laptop because the SETI@home screen saver was running on the stolen machine.

Edit: I think this was the story: [https://www.engadget.com/2007/02/22/seti- home-claims-its-fir...](https://www.engadget.com/2007/02/22/seti-home-claims- its-first-major-discovery-a-stolen-laptop/)

Edit2: Here is an interesting thread related to the link above: [https://setiathome.berkeley.edu/forum_thread.php?id=36985](https://setiathome.berkeley.edu/forum_thread.php?id=36985)

</comment></comment><comment><USER12> Wow, I didn't know BOINC had GPU support. I hate running an AWS GPU instance due to the cost, so I wonder if BOINC is an eventual solution.

</comment><comment><USER13> Personally I think grid coin is worth mentioning when bringing up bionic. Seems like mining that is actually useful

</comment><comment><USER14> I think my 17+ year old SETI@Home account may be the oldest non-email account I have. Great to see BOINC still going.

</comment><comment><USER15> The "Choosing BOINC projects" [1] page gives a good overview of what projects are using BOINC and which clients are available on which platforms or can use GPUs.

\- [1] [https://boinc.berkeley.edu/projects.php](https://boinc.berkeley.edu/projects.php)

</comment><comment><USER16> Pretty sure this is used by LIGO to find evidence of gravitational waves.

<comment><USER15> Yes it is. That's Einstein@Home [1]: "Einstein@Home is a program that uses your computer's idle time to search for gravitational waves from spinning isolated compact objects (among which are pulsars) using data from the LIGO gravitational wave detector."

\- [1] [https://einsteinathome.org/](https://einsteinathome.org/)

</comment></comment><comment><USER17> I have to wonder, as this has been around for quite some time now, is there any particular reason this was posted today? New developments?

<comment><USER7> I was wondering if its coincidence. Recently there's been an increase in activity on the BOINC crypto currency called gridcoin. You can see here: [https://www.poloniex.com/exchange#btc_grc](https://www.poloniex.com/exchange#btc_grc)

</comment></comment><comment><USER18> I reinstalled BOINC after 4 yrs, after watching SETI on cosmos series</comment>


The Art of PNG Glitch - <AUTHOR> https://ucnv.github.io/pnglitch/ <comment><USER2> Recommending

[https://www.reddit.com/r/glitch_art/](https://www.reddit.com/r/glitch_art/)

[https://www.reddit.com/r/pixelsorting/](https://www.reddit.com/r/pixelsorting/)

</comment><comment><USER3> Fuzzers can also create glitchy images: [https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of- th...](https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin- air.html)

</comment><comment><USER4> I have seen that image of the woman wearing the round hat and looking in to the camera in several image processing articles or tutorials now. Is there a story there? Ie is it a/the standard image people use to demonstrate something in image processing (similar to writing "Hello World" for programming languages, or printing Benchy for 3D printing)?

<comment><USER5> It's a photo of Lena.

"Lenna or Lena is the name given to a standard test image widely used in the field of image processing since 1973. It is a picture of the Swedish model Lena Forsén, shot by photographer Dwight Hooker, cropped from the centerfold of the November 1972 issue of Playboy magazine."

[https://en.wikipedia.org/wiki/Lenna](https://en.wikipedia.org/wiki/Lenna)

See also

[https://news.ycombinator.com/item?id=8707093](https://news.ycombinator.com/item?id=8707093)

[https://news.ycombinator.com/item?id=19181257](https://news.ycombinator.com/item?id=19181257)

[https://news.ycombinator.com/item?id=15670650](https://news.ycombinator.com/item?id=15670650)

<comment><USER4> Very interesting, thank you. This is exactly what I was looking for.

<comment><USER6> Also look up the history of china dolls in photography/film/video.

</comment></comment></comment></comment><comment><USER7> There are also physical prints of glitch art, and video renders, and they are even shown in art museums. [https://yle.fi/uutiset/3-10427458](https://yle.fi/uutiset/3-10427458)

</comment><comment><USER8> Is there a short description of how it works?

<comment><USER6> It screws up your image in a way that allows it to still be decoded by image viewers</comment></comment>


OpenLate Meetup Runbook [pdf] - <AUTHOR> https://opendns.app.box.com/OpenLateMeetupRunbook <comment><AUTHOR> OpenLate is a company meetup I started that ruend into a speaker series with over 2700 members. So far in 2015, about 10% of technical OpenDNS hires have been sourced through OpenLate.

I had to leave OpenDNS and OpenLate as I transitioned to working on our company full-time because it was accepted to a cool little fellowship program.

This runbook includes everything we used to run the event, including how to setup and what emails to send members.

If you have any questions about running a meetup, I'm happy to answer them!</comment>


China's Plan to Sideline Bitcoin - <AUTHOR> https://www.bloomberg.com/news/articles/2018-12-13/china-s-plan-to-sideline-bitcoin <comment><USER2> According to one report 74% of bitcoin mining is linked to China. [https://bitcoinmagazine.com/articles/report- links-74-bitcoin...](https://bitcoinmagazine.com/articles/report- links-74-bitcoin-mining-china-sees-threat-network/)

If that's true. Chinese government can do 51% attack at any time. They just contact different miners either operating in China or having family there and tell them what to do.</comment>


Trello Taco Out game - <AUTHOR> https://trello.com/taco-out <comment><USER2> Similar to the arcade game "Breakout". Awesome!

What's a good score? I got 177,870.

</comment><comment><USER3> This made my day.</comment>


Put out the UDP's on pasture [illustrated] - <AUTHOR> http://www.brainart.se/blog/2017/02/10/put-out-the-upds-on-pasture-illustrated/ <comment><USER2> I hate to be a negative nancy but ... this makes no sense is this article about security in the sense that no packets are lost or in whether they can be read or not? There's nothing about UDP that states whether the payload is encrypted or not?</comment>


Chrome is Not the Standard - <AUTHOR> http://www.chriskrycho.com/2017/chrome-is-not-the-standard.html <comment><USER2> _developers grouse about the other browser makers who are "holding the web back."_

Indeed, perhaps "holding the web back" is a _good_ thing if it means websites will be more accessible overall, to even less common browsers like NetSurf, Dillo, and all the other text-based ones. IMHO the "feature war/race" between the major browser vendors has had an overall _negative_ effect, as if all sites somehow need to turn into ridiculously bloated web apps instead of the simple and far more accessible hyperlinked collection of pages they once were. Keeping the browser choices diverse is a good thing, even if it means they will all display things slightly differently --- just find the lowest-common- denominator and emphasise the _content_ , the stuff that people visiting sites really care about.

There's been some other related discussion on this topic recently:

[https://news.ycombinator.com/item?id=15836027](https://news.ycombinator.com/item?id=15836027)

[https://news.ycombinator.com/item?id=15943689](https://news.ycombinator.com/item?id=15943689)

<comment><USER3> I think there may even be a chicken and egg situation going on - for some reason, media websites such as CNN are pushing giant rich media content objects at us like videos, which obviously are meaningless to a text browser. Even webdev blogs are being posted with big GIFs every paragraph or two.

I'm not sure why content creators are feeling the need to go multi-media - perhaps it's getting harder and harder to tell who your audience is, or segment your audience, or maybe the "smearing" of society is causing an audience for a given topic (ES6 development, say) to have so many different desires it's impossible to create content on the subject without annoying some portion of them (either by having plain HTML and CSS for your blog post with no helpful GIFs, or a bunch of GIFs that piss off people in text browsers or slow connections).

<comment><USER4> Even on my iPhone I can't browse CNN while simultaneously listening to music or the radio (iPlayer). Even though the videos are silent until clicked, they still take over the audio. Gets me every time!

<comment><USER5> What would a better experience be on iOS? I personally wouldn't find mixing the audio and having to pause one or open a per-app volume mixer control panel to be a better implementation.

<comment><USER4> Not sure, but to have this happen even for silent videos seems particularly annoying

<comment><USER2> From what I know, even "silent" videos can have an audio stream, which just happens to have all its samples decode to 0 (or nearly 0.)

<comment><USER6> Videos embedded into a webpage have a "muted" boolean attribute, so the nice behavior would be to not pause the music player when muted video starts playing.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> "Safari ships new features on a much slower cadence, but they're usually solid and always perform incredibly well"

Well, clearly this person doesn't have much experience with web development... The webengine in iOS is the biggest pile of crap I've ever worked with since IE6.

"Oh? You want to click this? OK, let's wait for 300 ms just in case you want to double tap to scroll!"

"We finally fixed it, no more delay on clicks! Yo Apple, the delay is still there if it runs as standalone, good job..!"

"OK, you've added the page to the home screen, now, if you click another URL on the same domain you definitely want it opened in the browser, right? Good guess Apple, that's why I added it.."

"Wait, are you saying that if you switch to another app and back again to the standalone site you don't want us to reload the URL that's added to the home screen? You would prefer us to let you continue where you left off, what!?!?"

"Oh, so you think momentum scrolling is a good idea? Too bad, we don't support it on elements that overflow, but we do have it elsewhere, have fun! PS we do have an experimental flag to enable it, but then I sure hope you're not using animations with gpu acceleration, cause then we have som nice race condition bugs in store for you, so who knows if scroll will work or not.."

Seriously, iOS is the worst of them. Sure Firefox and Chrome often has experimental features with bugs, but both of them are much more "solid" when it comes to features you'll actually use in production.

Safari on iOS is the IE6 of today.

<comment><USER8> Given this it's really a shame that Apple does not allow other browser engines on iOS. Would be a prime opportunity for competition to raise the overall quality level.

<comment><USER9> Looks like a case for anti trust, just like microsoft had with IE.

<comment><USER10> 1) iOS is not a monopoly.

2) Apple has legitimate technical reasons for not allowing other browser engines (well specifically the JS part). Intent matters.

<comment><USER11> > Apple has legitimate technical reasons for not allowing other browser > engines (well specifically the JS part). Intent matters.

Oh please... source?

<comment><USER12> Efficient javascript needs to be JIT'ed, but that means your app needs to be granted API access to map writeable memory as executable, which is a security risk they are not willing to grant third party developers. So a third party browser/js engine will likely be quite slow. I guess this would give users of a bad impression of iOS perfomance as a whole then, if other browser engines were allowed and became popular?

<comment><USER13> If other browser engines became very popular it says something about how bad/limited the default offering is. It usually takes a lot of work before people switch away from defaults. People continued to use IE for years for example

<comment><USER14> Chrome as the sole advertisement on the most valuable piece of web real estate in the universe might have been a factor too.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> I switched to Firefox, and I was blown away to find that Google Meet (the new Hangouts) does not work. You just get the message "Meet doesn't work on your browser".

I'm also impressed at how many of my job's internal websites don't work. This doesn't bug me as much, but it's obvious the devs who created them didn't even do a sanity check in Firefox.

<comment><USER16> Yeah the old Hangouts doesn't either.

<comment><USER17> There's been some recent movement on this [https://twitter.com/tsahil/status/943471207692763136](https://twitter.com/tsahil/status/943471207692763136)

</comment></comment></comment><comment><USER18> I wish the author discussed the fact that Apple doesn't allow any other browsers to target the iOS platform. Chrome / Firefox are forced to be thin wrappers against the webkit engine instead of bringing their own technology.

No other platform has policies like this and it greatly impacts the web platform and changes the dynamic of web standards in a way no other browser developer could.

<comment><USER19> >No other platform has policies like this

MS has a similar restriction on their App Store. Browsers are only allowed to use the MS rendering engine.

Also plenty of feature phones only allow use of the integrated browser. You might think that's an unrelated issue, but it's not. From a regulatory perspective, how do you differentiate between those, feature phones that allow a limited range of installable apps, games consoles with game offerings controlled by the console vendor, and the App Stores? There are even children's educational toys with downloadable apps.

Vendor control of software access on their platform is actualy everywhere and some platforms like games consoles are defined by the concept so completely we often don't even notice it. Dont like the games offered by Sony? Buy a Switch or an XBox. Don't like the software offered by Apple? Buy an Android. But you don't get to tell people which of these platforms they can or can't choose.

<comment><USER20> Just like Google has on ChromeOS.

What do I change the browser being managed by ChromeOS?

<comment><USER21> On a Chromebook, open the play store and download an alternative browser. It is that easy. Or sideload an apk if you've decided to opt-out of the play store.

When it comes to an alternative engine, Firefox on Android is Gecko-based rather than being based on Chromium. You can install this on a Chromebook. If you need any more help understanding, please let me know.

</comment></comment></comment></comment><comment><USER22> I'm definitely seeing several sites lately that require me to use a particular browser, lest I see blank elements or "buttons" that infuriatingly do _nothing_ when I click them except in certain browsers.

It's not consistent though. Usually switching to Safari is what works but sometimes I must use Firefox. On one government site it seemed the _only_ working combo was to _use an iPad_ , as no desktop browser worked on my Mac.

My latest gripe has to be log-in screens though (Google is guilty): forms are as old as the web and I resent that I can't even log in anymore because your Unnecessarily Fancy Form just doesn't work on all browsers!?

<comment><USER23> > On one government site it seemed the only working combo was to use an iPad, > as no desktop browser worked on my Mac.

Did you try using IE? I find some state government sites still work best on IE10/IE11

<comment><USER24> They had a Mac, so probably not.

</comment></comment></comment><comment><USER25> "Safari ships new features on a much slower cadence, but they're usually solid and always perform incredibly well."

I really don't agree at all with this, Safari is the new Internet explorer ...

[https://www.safari-is-the-new-ie.com/](https://www.safari-is-the-new-ie.com/)

<comment><USER26> No and I think your opinion is harmful.

IE literally refused to implement standards, rendered broken dom elements, allowed for proprietary native extensions and had many different apis for them. They had 90% of the market share and no other viable platforms. This meant developers built things which exploited these broken features causing huge compatibility issues when they aren't (every other browser).

A simple lack of features didn't make IE... IE. Safari is a pain in the ass but it sure as fuck ain't no internet explorer.

I think Chrome is propagating lazy developers who think everyone uses their browser. Which means things only work in Chrome and no where else. It's not as bad as the IE situation yet and hopefully it won't be with Firefox kicking ass again.

<comment><USER27> Apple is doing similar stuff by refusing to implement the payment request API and instead implementing their proprietary Apple Pay API. So you can use one API to target Chrome and Firefox and another for Safari. This is starting to sound a bit like IE. They were invited to join the working group for Payment Request and decided not to take part.

<comment><USER28> You can argue that they're not implementing $thing-you-like but lets be real; you can't compare IE to anything if you don't include the market share.

IE was harmful because it had such incredible market share and could do what it wanted with that.

<comment><USER29> And Apple has a major mobile market share, that HAS to use safari. If I could get away with not supporting safari, I definitely would.

<comment><USER30> Then you are not a proponent of an Open web, you are a lazy developer.

</comment></comment></comment></comment></comment></comment><comment><USER31> Standards are irrelevant to pragmatism. _De facto_ standards are what is important.

By virture of sheer popularity, Chrome is the de facto standard. And if they have provided anything that becomes useful or popular, then by virtue of popularity of that feature in what is already the post popular browser, makes that feature part of the de facto standard.

The post is just pedantic whining about how something isn't according to the written word in some document written some years ago by a bunch of people that the average _user_ of the standard does not even know.

I understand the value of standardization. Everything should be standardized. But what the standard should be is completely another question. I would say that all enhancements/popular features should be standard. At least that way, we'll have more people happier, rather than follow the least common denominator approach where there is a compromise that leaves no one happy.

<comment><AUTHOR> Not only did I not whine about something in a written document, I never once mentioned WHATWG or anything other standards body. (That was intentional.) I explicitly call out _the vendors_ and _their mutual implementations_. The "standard" I care about is the truly living standard of what every browser implements. The point here is that the _de facto_ standard is _not_ Chrome, and if it were that'd be a _bad_ thing. (We've been there before; it _was_ a bad thing.)

<comment><USER32> Every browser has never implemented exactly the same things in exactly the same ways, and never will. There will always, at least, be bugs.

A "de facto standard" of "what browsers implement" is no standard at all. This is why standards matter. "What the actually existing software implements" is what you have when you _don't have standards_.

The vendor-dominated, standard-changes-every-day WHATWG "living standard" is relevant to the situation here, I think, even if you'd rather it not be. If it's a living standard that's always changing, and it's specifically changing based on _what software does_... then Chrome doing something seems like as much of a standard as anything. It may or may not be added to the standard the next day, but the standard seems to encourage people to use things that aren't in it yet.

The WHATWG process, if I understand it right, specifically requires (at least) two browser vendors to implement a thing _before_ it's added to the standard. Yes, two is more than one. But not a lot more. :)

<comment><USER33> _Every browser has never implemented exactly the same things in exactly the same ways, and never will._

Igalia implemented CSS Grid for both Blink and WebKit: [https://blogs.igalia.com/mrego/2017/03/16/css-grid-layout- is...](https://blogs.igalia.com/mrego/2017/03/16/css-grid-layout-is-here-to- stay/)

And remember, Blink is a fork of WebKit, so they're not very different. So it can be done and we need more of this.

They're also working on some other stuff for Apple and Google. Never say never.

</comment></comment></comment></comment><comment><USER34> It's interesting that the author chose PWA's as their example.

The "Progressive" in Progressive Web Application means that web sites progressively become more app-like as they use certain APIs like Service Workers, but it also means that PWAs progressively become more app-like on browsers that support those APIs.

A site can go all-in on the PWA-related APIs and cause absolutely no degradation in experience on browsers like Safari. Safari doesn't support Service Workers, ignores parts of the manifest, doesn't allow PWA installation? It's fine, your app is just a normal website on Safari.

<comment><AUTHOR> Yep, and this is one reason I like the PWA design a _lot_. It's very web-y in the best ways.

Which is part of why the "Safari is holding back the web b/c no PWA!" response perplexes me. Even independent of the fact that they were in fact getting there – just not as fast as people wanted! – progressive enhancement is still a thing.

<comment><USER34> Safari has definitely been holding back PWAs though, because they're the gatekeeper of feature on iOS.

I've personally had meetings with teams would would love to adopt PWAs over their existing native apps, but can't due to Safari. I'm excited that it looks like that will change very soon!

</comment></comment></comment><comment><USER35> I like Chrome but lately I've spent almost all my time in Firefox Developer Edition. When I use Chrome it's to verify that it behaves the same way on more than one Javascript engine.

<comment><USER36> I switched to FF Developer Edition a little over a year ago, and I have caught several bugs that went unnoticed by my Chrome using colleagues.

<comment><USER37> How were they unnoticed in Chrome?

<comment><USER38> Chrome seems to have a tenancy to paper over some bugs and not report them back to the user (even in the console). It's the main reason none of our devs use Chrome for primary development anymore (it's not worth the extra dev time when QA fails on all other browsers) and it's just used during QA.

</comment></comment></comment></comment><comment><USER39> At what point does the dominant market leader become the standard, though? Chrome currently has roughly 60% market share in both desktop and mobile. No other browsers are forced to comply, but web developers will prioritize targeting the platform where their users are. We see this today where tons of things are broken on the long tail of older versions of IE, and developers largely ignore them.

I'm not saying that I like one company controlling the web, but when you're a small company developing software for the web, Chrome IS the standard.

<comment><AUTHOR> If web developers refuse to treat it that way, the web stays healthier overall. Consider this post an argument for why we _shouldn 't_ let any single browser have that kind of dominance. (I'd say the same it if were Firefox, Safari, or Edge in this spot.)

<comment><USER40> When you have dominance, and most of your users want to use Chrome, as developers you will tend to use Chrome to compare to other browsers. "I wish Firefox has this feature" kind of statement.

This is natural. Whether it is urban architecture to medical practice, someone's idea dominated the rest, and we use the dominant one as reference and as a tool for comparison.

This is called competition.

</comment></comment></comment><comment><USER41> This isn't new, though.

I think people forgive Google for more because they like them. IE did exactly the same thing before Chrome and was roundly (and rightly) admonished for it.

In fairness, Chrome's proposals do seem to be designed with the open web in mind - at least insofar as being items that other projects could reasonably be expected to implement in their engines if they chose to do so.

There's nothing so egregious as IE's DirectX-filters-embedded-in-CSS nonsense - or _shudder_ ActiveX - but it's still not great for the open web as a whole.

<comment> dao- NaCl was as bad as ActiveX but less successful, thank God.

<comment><USER41> Was it though?

I wasn't a fan of NaCl, and WebAssembly (for example) is a _much_ better fit for an open web, but it was at least platform agnostic (if support was provided by the vendor) and ran in a reasonably strict sandbox. ActiveX was neither of these things.

All that said, having any one browser be the standard is as terrible for the open web now as it was in IE's heyday. Just because Chrome is less awful doesn't solve the single-vendor problem.

<comment> dao- "If support was provided by the vendor" is a big if... Google was well aware of this inherent flaw but pushed NaCl regardless while at the same time promising for years that PNaCl would eventually solve all problems. PNaCl never really materialized, I think, and it feels like Google was throwing a smokescreen there to boost support and mindshare for NaCl.

</comment></comment></comment></comment><comment><USER42> Man, this is 2002 all over again with everyone treating IE6 as if it were _the_ standard.

</comment><comment><USER43> I know they screwed up recently with the Mr. Robot malware, but I think it's really important for developers to get behind Firefox again. As the American government fails to provide any sort of check on its behemoth corporations (Apple, Google, and Microsoft) and to protect consumer privacy, Firefox is basically the last contender for real consumer protection standing.

<comment><USER23> They didn't just screw up once . They've screwed up many times over the years with many projects and attempts that run counter to the core values that Mozilla claims to uphold. Bryan Lunduke articulated this very well: [https://www.youtube.com/watch?v=qMALm1VthGY](https://www.youtube.com/watch?v=qMALm1VthGY)

At this point Mozilla has to prove to us that they are worthy of our usage

<comment><USER44> I don't really understand this attitude. Mozilla doesn't need to be everything I ever wanted from a browser in order to get my support. It only needs to be better than Google.

Are all these people sticking with Chrome because Mozilla is not holding up to its values really think Google is better at taking care of our freedom?!

<comment><USER23> Chrome doesn't magically revert privacy or search engine settings in updates, but Firefox apparently does. To quote from [https://drewdevault.com/2017/12/16/Firefox-is-on-a- slippery-...](https://drewdevault.com/2017/12/16/Firefox-is-on-a-slippery- slope.html) :

> Not only are these experiments enabled by default, but updates have been > known to re-enable it if you turn it off.

Chrome has some troubling defaults but Google never decided to flip the default search engine or turn on any phone-home feature once it has been turned off. Even though they had/have the power to do so, they know people won't trust Chrome if they ever tried to do that. In my book that's more trustworthy than a vendor that decides to use updates to surreptitiously enable features that users disabled.

<comment><USER45> Prove it or show code! This statements sounds like a conspiracy theory.

<comment><USER46> Exactly. I ran the beta and when it became the release version, I changed my update channel to "release." It has not reverted any settings I've made.

I also had the Shield stuff turned off (my choice), and it hasn't been reverted, nor did the Mr. Robot extension ever show up. I agree, though, that that was a Bad Idea.

</comment></comment></comment></comment></comment></comment><comment><USER47> Safari is the new IE. Chrome is the new IE. And then all these comment claiming IE6 was actually very good?

May be I am old. Old, at least by Silicon Valley standard. After all Webkit is the new IE was coined by someone who hasn't started programming in the IE 6 era and thought IE era meant IE7 onwards.

Do any of you remember what those days were? IE? Active X? Different code for different Browser? DHTML? That was before even the word Ajax was coined. Before we had Jquery?

The problem we had with IE6, for me at least wasn't really about its monopoly. It was about so many low hanging fruit that they could have improve, but decided not to, and it was at the start of the first Internet boom, we could have had a future much brighter, but Microsoft was using all sort of propriety tech and not working with standards, leading to Netscape and Mozilla having to engineering its "Quirk" mode. Developing for IE was simple enough, Developing for Netscape and IE was hell.

That was long time ago.

I guess Microsoft thought IE was good enough. Good for simple Documents with tables and little animation sprinkled on top. Given their very low quality of standards at the time, may be they really thought the Web was good enough.

Fast forward to today, I guess Apple thought the web, as basic web pages is good enough. At least we cant do better without breaking lots of compatibility. But then there are those who saw Internet as an App Platform, much like Java, write once run anywhere. And they see Apple as something that is stopping them to achieve that goal, much like how IE was stopping the Internet from becoming better.

It really is two different Goal, Web Pages or Web Apps. Some people thinks web pages is even done yet, CSS Grid is hardly the answer we were all looking for. Some think forget about Web pages, it is good for what it is, Web Apps. It is all we need.

For me? I just wanted simple and beautiful Web Pages, Stripe and Apple's Website is two example I like. So i do ignore people who think it is their right for Webassembly, WhateverDB, ServerWorker, PWA or what ever that NEEDS to be included in every Browser.

May be the younger ones thinks I am just old fart stopping them from reaching their goal. Just like I was thinking IE was stopping the Web becomes the Web. I guess, is just a matter of prospective, old vs the New, the age old question.

</comment><comment><USER37> Consider QUIC.

QUIC is a UDP-based transport-layer alternative to TCP/IP (which, to a rough approximation, has some advantages over TCP/IP for multiplexing multiple logical data channels between the same two physical machines). While it is being standardized by the IETF, it is not yet a standard.

Google implements it server-side and it's enabled by default in Chrome. It is, as a result, already around 7% of Internet traffic.

<comment><AUTHOR> Experiments are _great_ in my opinion, and this is a fabulous example. We just shouldn't mistake "<Vendor> is trying something" for "Ergo it is now _standard_ and everyone should support it." The beauty of the web is that everybody _can_ try these kinds of experiments, and if they have high value, the others _will_ adopt them. I'm not sour on Chrome for trying stuff, by a long shot. I'm sour on people thinking "Chrome tried something" means any other browser which hasn't yet gone along with it is doing something wrong.

<comment><USER37> Agreed.

... but it's interesting that when Google "tries something" that crosses their server and web browser boundaries, that "something" can quickly become 7% of network traffic.

</comment></comment></comment><comment><USER48> Everybody favours the underdog.

Mr. Robot was stupid because - why do I want marketing in a product I use as an eveyday utility? Chrome is the standard because of the majority market share and also because they do a great job of delivering a good developer AND user experience.

</comment><comment><USER49> The author laments about _performance_ without once considering security. There are good reasons why that concurrent JavaScript extension hasn't been adopted by Google: it enables very powerful timing attacks against many aspects of your computer.

<comment><AUTHOR> This is literally the _exact_ point I'm making in the article. This kind of pushback from other vendors (including Google against Apple) is part of what makes the web platform _strong_.

</comment></comment><comment><USER50> I'm beginning to think that the best thing you can do as a user is to distribute your information footprint as much as possible.

Personally, I'll keep on using Firefox specifically because Mozilla does not own any of the other technologies I use.

</comment><comment><USER51> The thing is that Google owns WHATWG (who write and edit HTML specs) so the difference between Web "standards" and "what Chrome does" is moot. Other browser vendors have no choice other than to follow suit. I'm putting "standards" in scare quotes since what WHATWG publishes - the "living standard" thing - doesn't qualify as standard in my book.

It's a tragedy to see so much well-intentioned work being weaponized. Actually I appreciate the hard work of Domenic et al, and also the work being done on CSS specs. But we're way past the point where Web specs serve a purpose other than to keep people busy and brittle and monopolize the Web beyond recognition.

<comment><USER52> "The WHATWG was founded by individuals from Apple, the Mozilla Foundation and Opera Software in 2004."

\- [https://en.wikipedia.org/wiki/WHATWG](https://en.wikipedia.org/wiki/WHATWG)

<comment><USER53> Yes, but it's been pretty much taken over by Google now. All but one of the WHATWG spec editors are from Google. No editor is there which is from a non- browser vendor.

IMO it makes a strong case for the still existence of the w3c html spec.

</comment></comment></comment><comment><USER54> The author misses the point entirely. People don't complain about Safari holding back the web simply because it didn't implement service workers, WebM, WebRTC, and payment request while Chrome did. People complain about Safari because both Firefox and Chrome implemented those things. Nobody is complaining about Safari not implementing APIs that only Chrome has implemented.

</comment><comment><USER55> On the web, momentum is the standard. I've been a web developer since the 90's and I've seen technologies and standards come and go. One constant amongst them is the ones with the most momentum become the standard (whether de facto or de jure).

Flash was a standard, say what you want about it but browsing the web without a flash plugin, for a time, would have been a diminished experience. Even if it wasn't an IETF W3C standard

DHTML from Microsoft was really incredible at the time. It should have been a standard. There was no momentum behind it so it died.

RSS was a standard, now how many of us still use RSS readers?

JavaScript, need I say more?

PNG was a standard but took forever for browsers to implement because JPG's were "fine".

You want something to be a standard? Build awesome things quickly and get people to adopt them.

You want something to not be a standard? Build something better, but do so quickly.

The Chrome team has great momentum, so sometimes when they sneeze the web catches a cold.

</comment><comment><USER56> Standards don't matter, interoperability and openness are what matter. Standards are a means to that, but it's perfectly ok for one vendor to add features and do experiments, that is how progress is made, deviation/extension, adoption, analysis, and finally after all of that standardization. A standard without vendors pushing the limits is the hallmark of a dead technology.

</comment><comment><USER57> Yeah. Yet, sites like Seamless glitch horribly in Firefox, and their tech support answers "try it in Chrome". Very annoying.

<comment><USER58> Actually, it is the opposite for me. Works fine in both, but in Chrome - if I open developer tools - I get 19 warnings and 1 error. None in FF.

<comment><USER57> For example, their integration with Paypal is completely broken in Firefox.

<comment><USER58> That's bad...

</comment></comment></comment></comment><comment><USER59> Unpopular opinion: valuing compatibility and standards compliance as engineering/design principles is orthogonal to making your website play with obscure (e.g. Dillo, old Opera) or pointless (e.g. old IE when you're making a website whose money is overwhelmingly likely to come from technically savvy, younger, first-world users) browsers.

</comment><comment><USER60> Glad the author is cheering for a browser that is only available on the platform sold by only one vendor. And is dissing developers that are complaining that features that could make their job easier are not available on the author favorite platform.

I would honestly be more thankful for a lynx friendlier internet.

</comment><comment><USER61> Opera, Firefox, Safari, etc are OK.

But in the case of Microsoft, they made 2 horrible mistakes:

\- Piss off the user (slow, frustrating performance, popups, leaving people vulnerable to malware)

\- Piss off the developer (incompatible behavior)

I think Microsoft saw web applications as a competitor for desktop development (e.g: Visual Studio), and they felt the urge to cripple it.

Your average user had IE with 100 toolbars installed and horrible performance, you could not do anything.

As a result, IE and all successors are dead to me. Never going to use it again.

[https://i.stack.imgur.com/82hWm.jpg](https://i.stack.imgur.com/82hWm.jpg)

^ That's why we hate you Microsoft.

Each time I delete the Edge icon, I restore it only to delete it again, and again, and again, each time bringing more satisfaction.

That satisfaction is only surpassed by the one I get when I delete a Windows partition.

</comment><comment><USER62> I've always hated IE, and I've never been an MS fan, but I tried Edge and I was surprised how fast it was. I just use it to test website and app I work on, so I don't have a good idea on how good it is as a browser (bookmark, privacy, plugins...).

</comment><comment><USER32> > Many times, when this latter tack happens, developers grouse about the other > browser makers who are "holding the web back." But there is a fundamental > problem in this way of looking at things: Chrome isn't the standard. The > fact that Chrome proposes something, and even the fact that a bunch of > developers like it, does not a standard make.

WHATWG taking over the "standard" certainly muddies the waters. It's theoretically not just what a single browser vendor proposes or implements... but it is whatever the browser-dominated WHATWG says it is... on any given day... and effectively is whatever the most powerful browser vendors implement or propose (ie, Chrome).

<comment><USER63> What WHATWG says does not matter either. The only thing that matters is what is implemented in browsers.

<comment><USER32> That's a pretty different argument than the OP's about standards. Chrome is obviously a browser.

</comment></comment></comment><comment><USER28> I can't agree with the title more.

I use a rather obscure browser full time (qutebrowser) and they use Qt native bindings.

Due to compatibility issues Qt has _two_ backends for rendering HTML content.

One is based on webkit (qt-webkit), the other (unintuitively called qt- webengine) is actually chrome underneath.

Why chrome? because the web is now owned by chrome.

Before qutebrowser I was a heavy firefox user, but I always had chrome installed for those sites which rendered bizarrely and were obviously only tested in chrome. Too much market share is toxic in this industry I feel.

<comment> The-Compiler Note that Qt officially only has one backend, QtWebEngine, which is QtWebKit's successor.

However, it's more or less one guy (annulen) keeping QtWebKit alive as a hobby. So far that's worked surprisingly well, though.

<comment><USER28> That is incredibly notable, since qtwebengine is not supported -at-all- on my chosen platform (FreeBSD)

OT: heard you were going to CCC, I'd appreciate it if you swung by the DarkScience Assembly if you get a chance. :D

And great work on qutebrowser!

<comment> The-Compiler Is it? [https://www.freshports.org/www/qt5-webengine/](https://www.freshports.org/www/qt5-webengine/)

I'll try, but as usual I'll probably have a lot of things I want to do :D I'm usually at the Swiss Chaos assembly FWIW, and there might be a qutebrowser meetup as self-organized session some day.

Thanks! :)

<comment><USER28> Yeah i have that port installed. Getting the python bindings seems impossible.

Also. That port is quite the hack. :(

<comment> The-Compiler Looks like there's some work-in-progress here: [https://reviews.freebsd.org/D12964](https://reviews.freebsd.org/D12964)

And yeah, QtWebEngine is quite a beast to package, I can imagine that it's even worse on BSD...

</comment></comment></comment></comment></comment></comment><comment><USER64> What really annoyed me recently is WEBP; Yes, I know the format is GREAT AND GOOGLE, but none of my pic view tools on PC be able to print them on screen, nor my None chrome browser.

That feel IE anyway.

<comment><USER65> Well, that's the problem for _every_ new (image) format.

</comment></comment><comment><USER66> "Safari ships new features on a much slower cadence, but they're usually solid and always perform incredibly well" \- Also came with a torch and pitchfork to say that this is the most wrong statement ever. Flex is still barely supported. Transforms that are mixed together still cause the pages to flicker and screw up.

Safari is a joke. The development experience is a joke. I wish it would just disappear.

</comment><comment><USER67> Hurray for firefox quantum!

</comment><comment><USER68> I was under the impression that Chrome for IOS was a shell on Safari relying on calls to Safari code. Am I wrong?

<comment><AUTHOR> Nope you're exactly right. That's why I compared iOS Safari and Android Chrome.

</comment></comment><comment><USER69> Chrome has the best dev tools bar none. Firefox: make better dev tools please. Safari: No comment.

</comment><comment><USER70> Firefox's webGL support is abhorrent. Microsoft is undoing some aspects of their browser/OS decoupling. Google is no longer Don't Be Evil. Honestly without that getting better, I think the browser wars are pretty much moot.

</comment><comment><USER71> Chrome sux, their rendering is the worst among all browsers. If you try to use CSS transitions, or scaling, or any other GPU-accelerated effects in most of the times Chrome will render artifacts and have weird rendering bugs that don't occur in Firefox or Edge. PS: I still use Chrome for both personal use and as a developer, but I'm starting to realize more and more that Chrome is starting to be clearly the worse modern browser. I only use Chrome now for the Google account integration.

</comment><comment><USER72> Oh, I wish Chrome was the standard. Safari is such a crap browser with dev team unable to comprehend basic security models.

</comment><comment><USER73> Yup agree. Something that was in back of my head but couldn't quite come up with a way to say/write about it.

</comment><comment><USER74> I use chromium because firefox and chrome remain memory hogs that are slower. Other than that, I'd go firefox.

</comment><comment><USER75> Designing progressive web apps with fallbacks for unsupported features is PWA101. It's in the name.

</comment><comment><USER76> Dev tools are huge in getting devs onboard. Chrome has a huge lead in that regard.

</comment><comment><USER77> You have at least three viable browsers available on popular platforms. This is a great thing.

Developers who give a hoot about new features will be attracted to Chrome, it's just the nature of the game. If Firefox wants to attract those users, introduce more features.

</comment><comment><USER78> When Firefox is gone from browser charts it may be too late.

</comment><comment><USER79> i am certain the ppl who write these articles have also read the other 427 articles saying the same thing

</comment><comment><USER80> Prefer Firefox

</comment><comment><USER81> I remember the recent Groupon debacle on this, where the CTO was formerly of Mozilla.

</comment><comment><USER82> The problem as I see it is that the public data that users want to access is packaged in such a way as to maximize its exposure through Googles channels, be it a search engine with a proprietary ranking algorithm, a browser with certain unique features/quirks[1], a new HTTP version that allows stuffing more tracking information into HTTP headers, etc. While a mere three examples does not do justice to their achievements, there are honestly so many examples to list at this point it would be a disturbing exercise to be comprehensive.

It is not worth debating whether this impressive work is part of a plan by a corporation or a conspiracy among multiple corporations to steer/takeover "open" standards. (From past experience, it can be assumed that corporations will try.) The important point is the _effect_ that this work is having, irrespective of intent.

The author uses Microsoft or Apple as an analogy. Question: If something goes wrong at the corporation -- e.g., as we see today MS is not what it used to be, at least not in the browser market -- then what happens to the corporate- driven "standard"? Will Chrome always be the #1 browser?

It should not matter.

If people believe it does matter, then we know people are not aiming at complying with a open, immortal standard, they are aiming at being compatible with a present-day successful corporation, hoping to ride on their coattails.

I submit to the reader that whatever "standards" the corporation creates may well die out if the success of the corporation ever begins to fade. Keep in mind also that these "features" that the corporation has introduced as "standards" may have been introduced primarily to benefit that corporations business (and business model). They are the largest/primary implementer. Maybe their software is the only software that ever used the feature. If the software "disappears" from use because the corporations business falters they stop developing it, then what good is the standard (e.g. if it is too difficult, not well-enough understood or for whatever reason that other software authors did not implement it)?

I leave it to the reader to draw some examples of where this may have happened in the past from the internet and web archives. It could be exhausting if one were to try to be comprehensive.

1\. This is only personal opinion but when it takes a minimum of _two hours_ to compile a "browser" (as suggested by one corporation that sponsors one of these monstrosities), then clearly that is a problem. It should cause people to question. Instead it effectively stops people from compiling -- they give up and just accept the binary distribution. By comparison, IME (please do not assume I am referring to Linux) it only takes a fraction of an hour even on modest hardware to compile a complex kernel. Kernel development may not be for everyone, but there is no reason I can imagine why every users "web browser" needs to be a single program of that size and complexity. Personal opinion. Others may disagree. I respect everyones opinion but am entitled to have one that differs.

</comment><comment><USER83> Chrome _is_ the de facto standard at this time and all of the irrelevant, hyperbolic nitpicking and dubious conjecture isn't going to change that.

But here's a thought: WebKit and Chromium (and Blink) are open source, so maybe don't worry about it?

Furthermore, if all browsers don't work the same then that's a problem for developers. If we can't have that - I'd rather see just one browser engine in use by the majority like what we have now with WebKit. It makes my life easier.

Don't we have more important things to worry about than competition between web browser apps?

<comment><USER84> Chrome is not Chromium, however. Just because there is a nougaty open source center doesn't mean that Chrome is entirely free from proprietary software worries and worries about Google's commercial interests infringing upon user interests/greater web interests.

Additionally, Chromium isn't WebKit either. Blink forked from WebKit some time back and the fork continues to diverge, with WebKit and Blink disagreeing on some implementations.

<comment><USER83> Yes thank you, I understand all of that - it's very well known among web developers. None of it changes my argument:

 _The majority of the functionality that we care about in our web browsers comes from an open source library._

<comment><USER84> Except it does change your argument: you are clearly missing a _for now_ , so long as it pleases Google.

You can imply that if Google did something to upset consumers they may flock to an alternative Blink-based browser or Chromium, but Google and Chrome are the brands they know, they don't know or care about Blink or Chromium.

You may believe that Google are entirely generous and would never upset the open source balance from which they benefit, but they've done it before. The hard fork of Blink from WebKit is one obvious sign that if Google isn't happy, they can and will take their ball and move on. You can also consider in this equation the increasing disparity between open source AOSP and consumer Google Android. The number of closed, proprietary "Google Play" APIs that applications increasingly rely on still seems to be growing at a strong pace. The number of APKs that you can, for instance, sideload to AOSP-based Amazon FireOS continues to only dwindle and at this point a software developer very much has to develop two apps, one for Amazon's APIs and one for Google's, despite all the shared open source between the platforms.

So of course we should worry that Chrome has such a huge marketshare and that so many web developers are essentially building "Chrome-only" websites.

<comment><USER83> Incorrect. We have the source, we can do whatever we want with it. Nothing that you said changes that.

<comment><USER85> Do "we" have the budget to do that?

<comment><USER83> Emphatically, yes.

</comment></comment></comment></comment></comment></comment></comment><comment><USER86> Of course everyone knows it is Emacs EWW.

</comment><comment><USER87> Google should start an independent Chrome Foundation because honestly I would far rather see COLLABORATION than COMPETITION.

</comment><comment><USER73> The scary thing is some may hold up Google/Facebook/Twitter as the standard of the internet (without even being conscious of it).

Guess I'm not that young now, knowing what the internet was supposed to be in the beginning.

</comment><comment><USER88> Chrome just screwed the pooch, at least for me... blocking .dev domains ended my use. I'm not going to setup ssl on all my development environments for all the sites I have. I'll just dev in firefox, and move to firefox completely.

<comment><USER89> Any particular reason you think Firefox won't also implement Google's HSTS preloads for .dev?

Google owns that TLD, so I don't see why any browser which supports HSTS preloads would choose to ignore that particular pin, especially given that a move towards universal deployment of HTTPS is generally regarded as a good thing by browser developers and security experts.

<comment><USER90> > Google owns that TLD

That's the issue, and the part that should never have happened.

</comment></comment></comment><comment><USER91> I believe in free markets. If Chrome is winning, so be it. I for one am on the wagon.

<comment><USER92> When you will end up with monopoly it will become a problem. No one says chrome should be regulated, but for one I would like developers to test their applications in other browsers, at least Firefox and Edge.

</comment></comment><comment><USER93> The _only_ relevant Web standard in every era is "does it work in the browser most people are using". So Netscape in 1995, IE in 2000, Chrome today. That's just the reality, unless you'd rather lose money doing Web development.

<comment><USER94> That really depends on the values of the business in question. Some would look at that differently, and argue that developing to wider standards and testing on other platforms is an investment in quality and longevity.

</comment></comment><comment><USER95> Is there a possibility of an alternative to Mozilla with the kind of backing that Mozilla enjoys now? GNU project? Apache web browser? Linux Foundation? Heck, I'm sure privacy conscious people will happily pay for a quality browser that they can trust. I don't have the technical prowess to build a browser. If I did, I would.

<comment><USER96> Mozilla has ~$500M revenue/year.

I don't think you'll find a alternate non-Apple/Google/Microsoft player with similar backing.

<comment><USER33> Former Mozilla CEO raises $35M in under 30 seconds for his browser startup Brave: [https://techcrunch.com/2017/06/01/brave- ico-35-million-30-se...](https://techcrunch.com/2017/06/01/brave- ico-35-million-30-seconds-brendan-eich/amp/)

</comment></comment></comment><comment><USER97> There was a competition, Chrome won, I don't like the result, but it's the fact. I won't tell people to save the web by suggesting using something less competitive, that would reduce the I-wanna-save-the-web group's productivity, making their choices/opinions less competitive, which probably leads them to extinction. Web devs are just a small amount of browser users, general users couldn't care less about the standard. I wish someone could bring up some viable solution to that. Roar within the community won't change the situation, it's not even a start, such roar has been around for years, and yet here we are, still roaring. Sad indeed, downvotes are welcome.

<comment><USER98> Like it's over? You forget that one of the things that happens a lot before losing, is winning. Internet Explorer won too.

<comment><USER63> The problem was not IE winning, the problem was it sleeping on the laurels after that. So when demands for what could be done on the web, for standards compliance increased IE become troublesome. If there is a winning browser but it is still constantly developed and improved that would be less of a problem (though still not desirable).</comment></comment></comment>


Maintaining the Kernel's Web of Trust - <AUTHOR> https://lwn.net/SubscriberLink/798230/7f1ea6a77c0c1201/ <comment><USER2> From the comment thread in that article:

 _" I have considered running a non-connected SKS instance, but at this point in time everyone seems to consider SKS as pretty much dead -- it's not maintained and nobody is willing to step up or so much as touch it due to any number of reasons (largely, because OCaml is just too esoteric)."_

I wonder if they've tried reaching out to the OCaml community. I'd be surprised if there weren't people in it that would be happy to step up to help, were they aware of the need and its importance to Linux kernel development.

They could also try actually paying someone to maintain it. As the article notes, the Linux kernel development ecosystem is no longer staffed fully by volunteers. There's a lot of corporate money in it now, including big contributions from the likes of IBM and Redhat. They could certainly afford to hire someone to take on this responsibility, if it was deemed necessary.

<comment><USER3> Here's discussion from the time it was mentioned previously: [https://news.ycombinator.com/item?id=20312826](https://news.ycombinator.com/item?id=20312826)

</comment></comment><comment><USER4> > _But, to avoid signature attacks, only signatures made with other keys > stored in the repository are retained; that is sufficient to build the web > of trust while eliminating the results of any signature spamming that might > have taken place._

I didn't understand how this _alone_ is sufficient to prevent signature spamming, once a single compromised or bad-actor signature is in the repo.

"[https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/...](https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/README.rst") suggests a bit different process, which currently seems to require manual importing of individual signatures into one's keyring.

And the automated updating of user's keyring is only of such manually-imported signatures. (And the commit from which the updates are taken must be signed by a key that was signed directly by the key of Torvalds or the user.)

</comment><comment><USER5> It sounds like the web of trust is an incredibly difficult problem to solve, and also not a problem that the kernel needs to solve. Why do the kernel developers need a decentralized way to verify signing keys?

<comment><USER6> They don't, that's why they're just putting the keys in a git repo.

</comment></comment><comment><USER7> Just a friendly reminder: this is all moot due to ME and ilk.

[https://en.wikipedia.org/wiki/Intel_Management_Engine](https://en.wikipedia.org/wiki/Intel_Management_Engine)

[https://en.wikipedia.org/wiki/AMD_Secure_Technology](https://en.wikipedia.org/wiki/AMD_Secure_Technology)

<comment><USER8> This is not relevant to this discussion: it's like someone announced that they were buying better locks for their house and you're going "this is all moot because someone could just pull the roof off".

<comment><USER7> More like the discussion isn't relevant to reality.

The house is constantly being renovated and repaired, including the locks, doors, hinges, and every knob and button, by a lot of people, some of whom are even actual contractors, and now a few of those have ID badges.

Meanwhile, in Ecuador... (massive database leak ~20M people's data). That's just this morning.</comment></comment></comment>


Startup idea: Travel website predicting flight upgrade availability.  - <AUTHOR> http://mhalligan.com/startup-idea-travel-website-predicting-availa

<comment><USER2> Nah, I want to have a prediction how full a plane would be. THAT would be a service worth paying for..

<comment><AUTHOR> The two are not mutually exclusive. The higher the general vacancy within a given plane the higher the likelihood of there being cheap upgrades available immediately before take-off. I generally plan my travel around less desirable times because of the increased likelihood of a $50 first class upgrade on Virgin. Out of my last 40 or so flights, I've upgraded on 36 of them.</comment></comment>


Ask HN: How do you quote? - <AUTHOR>

In contexts where it doesn't matter what kind of quotes (' vs ") you use, which do you use for strings? Singles seem "cleaner" in some cases but I tend to carry over doubles from use in other languages. <comment><USER2> Single quotes as much as possible, unless it's a MySQL call or HTML.

I hack in PHP mostly.

</comment><comment><USER3> I always use single quotes if I can, one less keypress. I'm a Pythonist.

</comment><comment><USER4> I personally prefer single quotes. There are some advantages of double quotes like you don't have to close quotes every time you use variable. But I prefer singles because its cleaner and it helps me read my own code better.</comment>


Scale as a Design Input, Not an Output - <AUTHOR> https://medium.com/@stevemoffatt/scale-as-an-input-not-an-output-897fb81ea3f4 <comment><AUTHOR> It's a common in the ambiguity of startups that engineering-led organizations will default to build and "push" a feature, hoping that it changes the market context. Last week I talked about integrating lightweight-market pull in the development process, building on well-established leanstartup principles. This week I shift focus to starting with scale in mind to eliminate the need for half-measures and keep the team focused on user growth instead of unit economic challenges with scale.</comment>


An Introduction to Hashing in the Era of Machine Learning - <AUTHOR> https://blog.bradfieldcs.com/an-introduction-to-hashing-in-the-era-of-machine-learning-6039394549b0 <comment><USER2> Another interesting thing that was not mentioned was that the index can place semantically similar items close together.

For example, look at Word2Vec. It "indexes" / "hashes" words that are semantically similar to the same "bucket". This means that you can search for semantically similar data just by inspecting what is near by. This has all kinds of applications.

<comment><USER3> Locality sensitive hashing (what you describe) is really useful for clustering and doing nearest-neighbor searches. Its used in digital fingerprinting, genome sequencing, and other interesting areas.

</comment></comment><comment><USER4> Completely leaving out cache-conscious hashing. And before I would improve the hash function by some extremely costly ML, I would rather find a perfect hash. Which is cheap.

But he linked to my SMHasher.

<comment> tebba-lebba Are you talking about cache utilization in the context of collision handling, or hash functions themselves? I'd love to learn more about cache-conscious hashing, could you suggest a paper to read, or algorithm to search for?

I Googled "Cache-Conscious Hashing" but didn't quickly find anything promising :(.

Thanks!

<comment><USER4> The hash function itself is mostly cache independent, unless you count those variants which skip long strings.

You can cache the hash in the entry itself or not. You can compress the entries, but mostly using linear collision structures.

Best paper "Cache-Conscious Collision Resolution in String Hash Tables", Askitis 2005.

</comment></comment></comment><comment><USER5> Tons of stuff about hashing (that we already know) and not much on ML hashing.

<comment><USER6> I can't see how your statement can be true:

 _" In response to the findings of the Google/MIT collaboration, Peter Bailis and a team of Stanford researchers went back to the basics and warned us not to throw out our algorithms book just yet. Bailis' and his team at Stanford recreated the learned index strategy, and were able to achieve similar results without any machine learning by using a classic hash table strategy called Cuckoo Hashing"_

"We can do your ml hashing with ordinary hashing" is a statement about both ordinary hashing and ml hashing, indeed a fairly strong statement about each.

Whether it's true is a different matter but to say "nothing about ml hashing" seems unsupportable.

</comment></comment><comment><USER7> Sort of reminds me of Factor Tables: [https://github.com/RowColz/AI/blob/master/Factor_Tables.pdf](https://github.com/RowColz/AI/blob/master/Factor_Tables.pdf)

One can "compress" the Factor Tables using statistical "stereotyping" as a kind of a lossy learning technique. You have systemic control over the size- versus-accuracy tuning of the hashing (indexing).

Similarly, we learn to recognize or respond to patterns without remembering each specific instance of the pattern we encounter, which can be seen as a lossy form of hashing also.

</comment><comment><USER8> One of favorite papers is the paper from Jeff Dean

[https://arxiv.org/abs/1712.01208](https://arxiv.org/abs/1712.01208) The Case for Learned Index Structures

<comment><USER9> Some extra experimental evaluation of learned-indices: [https://dawn.cs.stanford.edu/2018/01/11/index- baselines/](https://dawn.cs.stanford.edu/2018/01/11/index-baselines/)

</comment></comment><comment><USER10> Really well written article. Sadly looks like the research is all on read- only, in-memory datasets because the training step is expensive.

</comment><comment><USER11> An Introduction to Hashing, more like it

</comment><comment><USER12> Cool that he used the photo of the Stuttgart (Germany) library.</comment>


Making a Ponyo boat - <AUTHOR> http://blog.jgc.org/2011/06/making-ponyo-or-putt-putt-boat.html <comment><USER2> We watch Ponyo at least twice a week in my house (4 year old loves it) and I have always wondered about the boat. The first thing I wondered if a.) it was real and worked - based on jgc's post seems that it does and might be more common than I thought and b.) if the heat would allow Ponyo to actually sit on the top of the boat as she does while it is moving.

<comment><USER3> Pop pop boats are real and have been around for a long time, I had a couple when I was a kid and it was fun to play with. You can see some more examples of pop pop boats and read some history here: <http://www.nmia.com/~vrbass/pop- pop/>

</comment></comment><comment><USER4> When I made my first pop pop boat, I simply coiled a piece of small hobby tubing for the boiler, with the ends poking through the bottom of the boat.

</comment><comment><USER5> I don't get how it works. Can anyone explain?

<comment><USER6> The heat from the candle flash-boils the water that's in the "boiler". This is ejected out of the tubing, and once the diaphragm relaxes, it creates a vacuum which pulls more water into the boiler to be boiled again.

The reason it doesn't just jerk back and forth in this exchange is because it sends pressure out in one direction, but draws water in from all directions.

</comment></comment><comment><USER7> I wonder if the efficiency would be improved if the whole engine construction would be under the surface level.

<comment><USER8> To a degree, but anything powered by a candle is going to have a pretty low hot-end temperature, and thus miserable thermodynamic efficiency.

</comment></comment><comment><USER9> Nice. This design of creating a toy boat has been extremely popular in south east asia for atleast the past 20 years. It's good to see it here again. Nothing beats nostalgia. :)

</comment><comment><USER10> Adding this to my list of things to "invent" should I ever be transported thousands of years back in time.

</comment><comment><USER11> I wonder how I could make a remote control ponyo, low-tech wise ..

<comment><USER12> It is possible, all you need is to find the controller which will control the flame, bigger==faster.</comment></comment>


Tinder for Cheetahs? Big Cats Are Attracted by Urine Smell - <AUTHOR> https://www.scientificamerican.com/article/tinder-for-cheetahs-big-cats-are-attracted-by-urine-smell/ <comment><USER2> Anyone that's ever owned a cat, or known someone that owns a cat, is well aware of this. Come on Scientific American, slow news day?

Related, I've been sprayed by two different white Bengals. Yeah. Yeah, that stuff lingers... not as bad as skunk but... yeah. Why would you take tigers to a state fair. Why?! To be fair there were signs posted that said something about them not liking umbrellas and signs warning that you were very much standing in 'the spray zone'. I should have taken that more seriously. That first one sprayed me which immediately got the other one interested in spraying me while I was still in disgusted shock.

Pro-tip, large cats do NOT like shutter noises and/or light shining off of lenses.</comment>