Hacker News new | past | comments | ask | show | jobs | submit | more drvortex's comments login

Well, what can you do?

Mozilla has a very unique problem. It's most ardent and loyal users are technically savvy. They expect a high quality, privacy-respecting, ad-free product.

But, here's the catch, they will not pay for it. How does Mozilla survive?

Google finances Chrome through its Search/Ad business. Safari and IE costs are bundled in the cost of the devices/OS they are on.

How should Mozilla survive? Should they go the shareware route and have a paid copy for 20$ ?

They have to make money somehow.


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.


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.)


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. :)


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...

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.


The practical upshot of what you're saying is that the browser vendor with the biggest market share can do whatever the heck they want, and everybody else can either reverse-engineer it or eat dirt.

I'd tell you why you're so spectacularly wrong, but since we've already lived through the nightmare you're currently endorsing... instead I'll simply refer you to the 1990s and early 2000s.

You don't want that.


Depends on who your target audience is.

Germany for example uses 38.22% Chrome and 31.11% Firefox on Desktops. No way you can speak about a de facto standard here.

I, as an end user, don't know about industry standards for screws, magnet strips or pipelines either, but that doesn't make them less important.

We already tried giving a commercial company free reign in this regard, with Microsoft and it's Internet Explorer, and it did not end well. I see no reason to try this again.

Standards also just make it easier for new players to enter the browser market, instead of having to reverse engineer how Google does stuff, so Standards even help with competition.

I will happily discuss current shortcomings of the W3C and standardization process in general, but we shouldn't repeat the past.


Same could be said for IE, but then Microsoft isn't a HN darling so it gets bashed, while Google gets praised for doing exactly the same.


Oh yes. The same could be said about IE. In fact, I personally have no problems with IE implementing new features. The problem with IE was never that it was standards-incompliant. Heck, they were the de facto standard and there software used even today that won't run on anything but IE.

The problem with IE was that it was a shitty bloated browser. And to be honest, nothing shook its dominance before Chrome. Not even Firefox.


Chrome isn't the de facto standard, it doesn't have complete dominance of the web yet so you also have to support, at the very least, Safari.


No, it doesn't have complete dominance. But it has more share than all the other players combined. https://www.w3counter.com/globalstats.php

That is a dominating position making it the de facto standard, even if not absolute.


By that logic, GTK/Qt, basically any cross platform GUI library etc. is not 'native'.


Nice, but really, it is a narrow column on a 4K screen. Can you make it adapt to screen sizes so that it can use at least 80% of the screen?


I did some fixes to improve that experience. Let me know what do you think


Good point. I'll work on it!


Does not run offline. Need notes app to work in offline conditions.

Take a cue from Onenote/Evernote/Keep. A notes application MUST run even in shady/non existent internet connection.


So this basically replicates the functionality provided by https://sessionbox.io/

Is multi-process here already?


> Is multi-process here already?

Yes.


Oh God. It's Trillian/Pidgin all over again.


What is the point ? If it is just academic curiosity that is fine. But if it compiles one to one to C++, then it is just a different and more Python-like syntax for C++ ?


> But if it compiles one to one to C++, then it is just a different and more Python-like syntax for C++ ?

Yes. In some cases this is an advantage as C++ can become very verbose with unnecessary repetitions (manually synchronize signatures in .hpp and .cpp files) or stuff that can result in bugs after merges (public/protected/private not explicitly written in front of each method).


Not saying this is the point of Coffee++, but I thought about doing the same thing for Golang -> JavaScript, specifically for React Native. I was willing to use a subset of Golang to get a 1:1 transpile.

My reasons were gaining that my tooling, testing, etc was very Go centric, yet React Native offered a compelling solution to mobile UI development.

Currently I'm choosing not to do it, mainly because JSX is a very nice syntax for React, compared to chaining Go functions ad infinitum. Regardless, I'm just offering some perspective as best I can. Making their own language though is a bit different than my example, because they're just changing syntax, not re-using tooling.


Every programming language can be described as "just a different syntax" for some other language, e.g. "C is just a different more Algol like syntax for assembly language." The differences in syntax is what can make a language useful (or not useful, e.g. Brainfuck).


That isn't really true.

There are clear differences in semantics between most programming languages. C is not just a different syntax over assembly: It has a type system, and obviously restricts what you can do (e.g. C abstracts over the registers)

A higher level language can be translated to a lower level one, (hence why Haskell can exist), but saying it's a purely syntactic transformation is extremely reductive.


A Haskell program compiles to something that uses places and mutates what is stored in those places because a Haskell program ulitimately runs on a machine designed with the Von Neumann architecture.

Reduction is what compilers do. In the old days C was often compiled to assembly (at least the parts that were not in-line assembly) and the assembly was assembled and all of it got linked into an executable. Crenshaw's classic Let's Build a Compiler is a great way to see how it was done even if it is written using Pascal. http://www.stack.nl/~marcov/compiler.pdf


Umm, I know how compilers work.

C is compiled to still compiles to assembly, but usually (GCC) your compiler driver handles assembling, linking etc.

Haskell is translated to core (basically a simplification of a small subset of Haskell), then the STG(The abstract machine, spinless-tagless-Gmachine) then Cmm (Basically unsafe C) then LLVM.


The turtle at the bottom of Haskell is machine code...mutable non functional machine code that is isomorphic with the Haskell source.


The machine code can still be basically functional. GHC doesn't use any mutable data unless you tell it to, it generates and then immediately collects garbage rather than reuse mutable memory.

You can have mutable data in Haskell, obviously.


Garbage collection, RAII, dynamic typing, template metaprogramming, macros, type inference, exceptions ... are not "syntactic" features of programming languages. Those are semantic features, that happen to have a syntax.

Reducing programming languages to syntax+isTuringComplete is missing the forest for the trees.


I agree because I think dismissing Coffee++ as just Python-like syntax also seems to ignore semantics. That was the gist of my remark.


So basically, ChromeOS.


I cannot understand the relevance of an email client, now that browsers can do email. It may be my workflow, so I will ask:

Is there any scenario where an email client would be necessary - i.e. a browser based solution will not work?


> Is there any scenario where an email client would be necessary - i.e. a browser based solution will not work?

Here's one: multiple email accounts that you need to check on a regular basis. I would lose my mind if I had to track my emails across three different web interfaces.


If you have an email address that is not gmail, which browser email client will you use?


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: