wyqydsyq's comments

There is absolutely no reason DataGrip needs to be a subscription service. There aren't any ongoing costs for customers to use it.

It should be a one-off purchase with optional support subscription, maybe requiring re-purchase at major version increments, not this bullshit where you need to maintain a subscription for a license on a binary program you already paid for and installed.

Feels as dodgy as Adobe turning Photoshop into a subscription service

Fuck these business models and the sales idiots who try to apply them to every single product

AFAIK the box-sizing box model you mentioned was implemented since the beginning of Trident, well before IE6 came about.

XHR was available from IE5 onwards (only accessible via ActiveX object, it didn't become available as a native window property in JS until IE7 but the feature was still available), so again isn't "since IE6". If you think whether it was available in native JS matters, note that Mozilla had a native JS XHR object available in 2002, well before it was available in IE7 in 2006.

I specifically mentioned "since IE6" because that was the point at which Microsoft had decided they'd won the browser war, and ceased to innovate. From that point onwards they have been playing a perpetual game of catch-up, constantly lagging behind other browsers in implementing new specifications and features.

setImmediate is not standardised for good reason, there are already more appropriate use-case specific solutions: use `requestAnimationFrame` if you are working with animations/visual changes use `postMessage` or WebWorkers if you are working with transporting or processing heavy data

There's no browser use-case enabled by `setImmediate` that isn't supported by one of the above. It does however make sense for `setImmediate` to be implemented in node because a node environment lacks the two APIs mentioned above and doesn't really have any way of achieving the desired outcome short of forking child processes.

Safari and Konqueror still use WebKit, Firefox still uses Gecko, so not "only a single browser will be able to display it", but multiple maintained browsers using 3 different implementations will still be able to display it. Additionally, even in that worst-case scenario of Chromium/Blink/V8 becoming the de-facto implementation and making standards irrelevant, it wouldn't be "whatever Chrome does", but "whatever Chromium does". Being in that situation Chromium would be in use by everyone, so if anything that only places more power in the hands of the community because Chromium is an open-source project. Why should every browser have their own competing (and often incompatible) implementations of each standard to the detriment of the web? How is that more beneficial than browser developers all collaborating on a common, shared implementation? Very rarely have implementation-specific differences between browsers benefited the web, generally such differences will either remain implementation-specific and become redundant (e.g. all the IE-only APIs) or are experimental implementations of a standard that's only in draft state and will be updated to be consistent once the relevant standard is finalised, in both cases they're just neat toys for developers to play with that aren't practical to employ in production (because they'll only work for a fraction of viewers).

> This is a terrible and fatal result for the web as we know it. Because why would we continue the practice of creating baroque, power-inefficient web frontends with JavaScript and the browser stack monstrosity when we're essentially targetting a single browser? We could as well use a much leaner and lighter GUI framework designed for the purpose, and a saner language.

This is a fantastic and wonderful result for the web as we know it. With less implementations to support, the web would be substantially faster and more efficient. Because why would we want to load our asset bundles with megabytes of polyfills and shims just so things don't explode on the odd chance someone tries to view your website in the default browser of their OS that's either outdated or poorly implements specs?

If every major browser ran Blink/Webkit + V8, the web could be written once in native ES2018 javascript and consistently execute anywhere. This is not the case today because implementations behave differently, you can't write a webapp purely following the established specs because the specs are inconsistently implemented. For example `navigator.mediaDevices` API works differently across browsers, some browsers support-sub features that others don't etc. This ends up requiring checks and work-arounds that waste processing power to execute and human resources to implement.

You know what open-source is, right?

People threw their arms in the air because IE was substantially behind other browsers in stability and capabilities, and all their new features were IE-specific APIs that didn't work anywhere else.

Chromium is an open-source project that largely follows IETF/W3C/ECMA standards.

The two are not even remotely comparable.

Microsoft has hardly offered much as far as competition and diversity goes since IE6, basically the only web "innovations" they're responsible for is a bunch of IE-specific APIs that didn't work in any other browser.

The garbage rhetoric that Mozilla and their supporters have been spreading is pure FUD:

> By adopting Chromium, Microsoft hands over control of even more of online life to Google.

MS' new default browser being based on Chromium does not give any additional control of online life to Google. They're open-source projects that, while Google manages, does not have absolute control over the consumption of. If Google did ever try to muscle control on Chromium like they've been doing with Android, Microsoft could simply fork it without the hostile Google changes.

If anything I see this whole thing being beneficial for the web in the long run - now instead of MS engineers pissing their time and effort down the drain on a dead browser and needlessly fragmenting the market with engine differences, even if people don't use the default Windows browser Microsoft's engineers can contribute to and benefit the web by contributing their improvements upstream to the Chromium/Blink/V8 projects.

MS are going to be using Chromium, the open-source project along with it's Blink and V8 rendering and JS engines as the basis for their next default browser. They are not planning to install Google Chrome as the default browser.

Microsoft choosing to use one open-source project over another to fork their next browser from does not threaten the health or diversity of the internet. It isn't giving Google any additional control or power over the internet, because Chromium is an open-source project and any integrations to Google's own services exists only in Google Chrome.

Basically this article is just Mozilla whinging because their project wasn't chosen and pushing FUD about the health and balance of the internet being threatened as a result.

In reality Google does not gain any "power" from this, unless you count the couple of contributions Microsoft have submitted to the Chromium project (which again, is open-source) as an increase in "power", by which logic Mozilla should already have more "power" because they have been receiving decades of contributions as a result of being the default browser in most Linux distributions (leading hackers to write Firefox contributions and addons instead of for Chromium for example).

There is a profile manager but it sucks. You have to launch it directly (can't open from a FF window) and you can only have one profile active at a time.

Compared to Chrome where I can seamlessly have my work and personal profiles active at once, allowing me to do all of my work in a segregated profile while still having access to all my personal stuff like music playing in another window.

> According to Alexa the site is ranked as the 209,334 most visited site in the world

Clickbait much? I think to be considered "one of the world's most visited" it should at least be in the top 1,000

master branch being broken for 3 months doesn't exactly instil a lot of confidence in something that seems to be intended to run critical legacy software

The only meaningful use case I see in Lucee is to be able to run and maintain legacy CF applications in an environment that is still supported without rewriting them for a more modern and capable language/runtime. It would be best utilised for putting legacy applications on life support, not for creating the next big thing.

Yeah people said the same thing about MySpace and look what happened

However I feel you guys have chosen a poor approach to distributing it.

① I feel it would have been far better to implement the studio as an Atom plugin rather than a fork of Atom

② I feel having the compiler only available bundled into the studio is a mistake, there should be a pure CLI interface with minimal external dependencies so that people can use Luna in their existing CI pipelines

This way you only need to remember one password (master) to re-generate your password for any given service, and nobody can replicate the resulting service passwords without knowing BOTH your master password and your salt.

I wrote a proof of concept a few years ago, it's pretty outdated and generating word phrases would be better than just hashes, but it conveys the idea: https://github.com/wyqydsyq/ysnp