There are various international economic laws, treaties and agreements between cooperating countries, whether or not any of them cover this scenario for to US, and whether the US would honour any agreement in the current political climate remains to be seen. But there are mechanisms in place that allow w the UK to reach US companies through each others legal systems to a degree and vice versa, regardless of asset location.
> whether the US would honour any agreement in the current political climate remains to be seen
That this is even a question is bananas to me. Isn't that handled by the judicial system rather than involving politics/the administration? Shouldn't be possible for the US to have a treaty, and there are questions about if the treaty will actually be enforced or not, how could anyone trust the US as a whole for anything if those aren't enforced?
> Components are bad for web accessibility (aria- property fatigue).
I've been using web components as a vehicle to automate and auto validate accessibility aspects as much as possible, because I think the only way to truly make things sustainably accessible is to find a way to unburden the developer by either inferring as much as possible or making validation a natural part of development rather than a separate testing cycle that will invariably cause accessibility support to become out of sync.
It sounds like you might have similar concerns. Do you have any insights to share along these lines for Gooey?
The UI components that I wrote initially are just wrappers for the Browser provided input/form elements. As I'm relying on webview/webview to build desktop apps out of it, that also kind of implies WebKitGTK4 on Linux, WebKit on MacOS, and WebView2 (Edge) on Windows.
These work quite nicely together with a screen reader because you don't have to intercept the focus event (or others) that people browsing in caret mode or similar would use to navigate the page.
Additionally I decided to make single page applications using a main and section[data-view] elements so that the HTML and CSS alone is enough to hint screen readers on what's visible and so that there are no javascript codes necessary to tween things around, the JS/WebASM side of things literally just sets a data-view property on the main element.
The whole idea behind gooey and the way it is structured is:
- all states must be serializable in HTML
- Static HTML and CSS makes the page usable (apart from web forms and REST APIs, that's developer provided code)
- Dynamic WebASM on top essentially translates the DOM to be interactive, so that things can be animated based on changing data or streams coming from the backend. All interactivity is rendered directly into the DOM, so that it can be serialized again at all times.
- Communication between Client and Server is JSON or any other Go implemented Marshaller, and using Fetch API behind the scenes.
I decided on purpose to not provide XMLHTTPRequest and other old APIs because I'm relying on WebASM and "modern Browser engines" anyways. This way I kinda force users of gooey to use modern JS from the WebASM context and I save a whole lot of trouble with compatibility issues (and don't get into the unsemantic div fatigue like React does, for example).
> And proprietary browser plugins, really? So you're not looking to reduce complexity after all, then?
Maybe they haven't lived through the world of pain that was Silverlight, Flash and Java Applets et al. I suppose from a more innocent position without any history it might seem like a good idea to break complexity out into little modules, but the reality was poor integration, more platform lockin, and a security nightmare.
Do you have any arguments that are not? The article presents actual evidence, whereas you seem to be intent on littering this thread with hypothetical counter points and abstract versions of reality.
> > Again I don't think you've thought it through.
> You can disagree with me, but these continuing, unnecessary, personal, condescending comments are in violation of the HN guidelines. Please stop.
This is absurd, you need to stop invoking HN guidelines inappropriately just because someone (far more respectfully than me) disagrees with you. Grow up.
> This is absurd, you need to stop invoking HN guidelines inappropriately just because someone (far more respectfully than me) disagrees with you. Grow up.
I don't know how a discussion about browser engines ended up here, but please don't comment like this, no matter who or what you're responding to. You're a longtime user whom we've not had to warn for several years, but we need everyone to avoid behaving like this on HN. Longtime users should be the ones to de-escalate heated discussions and raise the standards on HN, not drag them downward.
No, the worst offender (by far) does not get a free pass just because the world is not perfect.
All of the main contributors have corporate interest and are not acting out of the goodness of their hearts, yes. But Apple's level of anti competitive, vertically integrated, gaslighting bullshit goes above and beyond.
> does not get a free pass just because the world is not perfect.
Nobody is giving Apple a "free pass". I started by saying literally, "I have no wish to defend Apple." I also said, "Nobody has clean hands here, not Apple".
> But Apple's level of anti competitive, vertically integrated, gaslighting bullshit goes above and beyond.
I would note that the US Department of Justice is currently pursuing two monopoly cases against Google and suggested that Google should divest Chrome.
> > the worst offender (by far)
> This is disputable.
It really isn't. This has been argued to death, this is the point of this article (to provide data) because so many people (fans or not) buy into Apple's marketing, token browser feature releases and virtue signalling. They even have the cheek to boast about Safari's a11y feature releases while simultaneously ignoring long standing bugs that have broken overall a11y experience for years. To anyone on the ground who's been making web content and apps for a decade its clear as day, for everyone else Apple has done a good job of making it very unclear what's going on.
> Nobody is giving Apple a "free pass". I started by saying literally, "I have no wish to defend Apple." I also said, "Nobody has clean hands here, not Apple".
Yes, then go on to describe and focus on a "monopolistic landscape", and paint a picture where Apple is just another generic, monopolistic, self serving player - while completely ignoring the reality of the affect those individual players have on the web - which the article actually does investigate, but you would rather discount it's evidence because the author is involved enough in the ecosystem to have insight and form a strong opinion.
In summary you seem to be rejecting an evidence based argument (but not due to it's evidence), in favour of a philosophical perspective, entirely in the abstract, absent of detail, that equalises responsibility. To me that feels like giving Apple a pretty big free pass.
> I would note that the US Department of Justice is currently pursuing two monopoly cases against Google and suggested that Google should divest Chrome.
Yes, and I would agree, but that does not negate the reality of Apple's far worse affects on the web. I (also) don't want to defend any of them, but if you want to get philosophical, Google's monopoly is more aligned with the interest of web users', yes they will try to throw anti user and anti-competitive things in there (and they should be shamed for that), but they have also done a ton of work to move the platform forward, not out of the goodness of their heart, but that's the reality. Compare that to Apple's business, which is not aligned with the interest of web users', quite the opposite. Both companies manipulate the web in ways that benefit their business, it just happens that Apple's is so negatively aligned with the web that they do so through inaction while anti-competitively blocking other vendors, and blocking standards progression.
> Google's monopoly is more aligned with the interest of web users', yes they will try to throw anti user and anti-competitive things in there (and they should be shamed for that), but they have also done a ton of work to move the platform forward
I disagree, and it appears that you're approaching this mainly from the perspective of web developers, whose interests are not necessarily aligned with web users either. In fact, web developers nowadays are notoriously user-hostile.
As a web user, I'm perfectly fine with continuing to miss many of the features that the article author believes are "missing".
I wonder what the difference between PM2.5 from cooking oil or fat vs PM2.5 from combustion engines is on the lungs.
My instinct is that it should be less toxic from vegetable oil, if it's just vaporised... past the smoke point maybe the chemistry changes enough to make it more toxic. The body has mechanisms to remove foreign matter from the lungs, but how easily and how much it clogs up your lymph nodes seems to depend on what it's made of.
Yeah, I get that learning the codes is a little annoying, but not actually harder than finding, incorporating, and learning one of the APIs here. Also one is standard while the other is not. Seems a bit nuts to use a package for this.
Hi, missing a lot of history here. When Chalk was written, colors in the terminal wasn't a flashy thing people tried to do very often, at least not in the JS world. Coming from browsers and wanting to make CLI apps using the flashy new Node.js 0.10/0.12 at the time saw a lot of designers and other aesthetically-oriented folks with it. Chalk filled a hole for people to do that without needing to understand how TTYs worked.
Node.js proper has floated the idea of including chalk into the standard libraries, FWIW.
> Node.js proper has floated the idea of including chalk into the standard libraries, FWIW.
Oh my word please no! Every time I run into an issue where a dependency suddenly isn’t logging colors like it’s supposed to, it always boils down to chalk trying to do something fancy to handle an edge case that doesn’t actually exist. Just log the dang colors!
I doubt we'll ever see eye-to-eye on this. Some people try to think about how to write less code, and some people try to think about how to write more code.
I would argue that ANSI color output should be something natively supported in stdlib for any general purpose or systems programming language today. Precisely for this reason - it has been a standard for a very long time, and for several years now (since Windows enabled it by default) it is a truly universal standard de facto as well. This is exactly the kind of stuff that stdlib should cover.
> Could the user have trouble perceiving the change in state that just occurred? If so, then use an animation to help them visualize what happened
I think this is the only justified use of animation in UI, however I wasn't satisfied with the dilemma of increasing perceived transition while increasing perceived UI latency.
I found it's possible to get the best of both for event triggered state changes i.e clicking on stuff, by sticking to ease-out based transitions, where the start of the transition is instant and the end decelerates.
This makes it feel just as snappy as no animation, while still helping to communicate a transition, because we are more sensitive to the latency of the start of the transition when it's an event - since we are anticipating a reaction, which is satisfied as soon as it starts to react.
reply