You can still do this with Vue 3! The CodePen embeds they use in their "Getting Started" docs are all still just loading in an external library and making use of it with vanilla JS.
181 karma · joined November 7, 2019
Firefox Developer Edition is a first party version of the software from Mozilla. It runs slightly ahead of the standard Firefox version I think.
FWIW, Waterfox also uses dark browser chrome by default, although if you're worried about security risks in installing extensions, a third-party fork of Firefox may not sit well with you either.
Regardless, I've used both pieces of software and had very positive experiences.
For updates, I've got a filter based on substrings in the subject like "receipt", "invoice", "latest bill" which does fairly well at catching that transactional type of email.
It definitely takes more time than Google's implementation, but in curating the filters myself I've found I've been left with a cleaner, more organised inbox.
[0] https://protonmail.com/support/knowledge-base/sieve-advanced...
The first two are new to me, so thank you, I'll read up. The third succinctly explains a quirk I've never bothered to check the legitimacy of, so thank you again.
With your changes, that brings us way below the character limit, sitting at 208 characters with the <body> and <script> tags the challenge dictates.
I had to rejig things to use parent.append(child) as it doesn't return the element, but using the child.remove() method directly means there's no parameter and therefore one less character there, so it all balances out. I also had to rename the event variable as it caused a scoping conflict for the variable `a`.
With all that space left over you could certainly add in the clear all and strike-through behaviour properly. Maybe even some real state!
Updated fiddle: https://jsfiddle.net/2z0bus8d/1/
<body><script>let win=window;document.body.innerHTML=`<input id="a"/><b id="b"></b><ul id="c"></ul>`,win.b.onclick=a=>{let b=win.c.appendChild(document.createElement("p"));b.innerText=win.a.value,win.a.value="",b.onclick=()=>win.c.removeChild(b)};</script>
JS Fiddle: https://jsfiddle.net/2z0bus8d/
While I think there's always the standard caveat around code golf in JS (you're building on a vast set of APIs and an often resource hungry platform), reaching for a framework really doesn't feel in the spirit of this kind of puzzle.
VSCode itself doesn't fall over, but code completion and error highlighting are painfully slow to catch up and several of the extensions that provide that functionality regularly crash out.
With that said, there could easily be an array being iterated under the hood with the `replace` method anyway.
Vue 3 seems to have taken a lot of cues from React during its rewrite, give it a second look if you weren't keen on 2.
I'm certainly glad a standardised way of handling custom fonts emerged though, I remember SIFR being particularly painful.
That said, this site could almost do with a "Best viewed in Chrome" sticker, as the removal of -webkit-font-smoothing does some weird things to text in desktop Safari for me.
This article actually incorrectly suggests Quibi is only accessible in US and Canada...
> (Quibi is only available in the US and Canada)
...and no one I've spoken to has ever heard of it.
All three of the issues you raise would be solved by involving a VCS somewhere in your FTP deployment.
Incidentally, claiming that either option is "no more difficult" than FTP upload or even using VCS is either disingenuous or at least a little blinkered. FTP can work as simply as copying files between "folders", I've successfully taught my non-techy parents to use FTP. Setting up docker images or static binaries requires significantly more understanding of what's going on but of course provide speed, consistency and scalability benefits.
On the other hand, the 10s saw a dramatic increase in model variation in Apple's product line. It's been said before but I now have a fair amount of trouble knowing whether an iPhone model is current gen or not, I see people talking about iPhone 8, iPhone X, iPhone 11, iPhone XR, iPhone 11 Pro and now the iPhone SE has had a refresh again. A far cry from the canonical product line where Apple insisted one device was perfect for all... Whether that's a positive or a negative is up for debate. Samsung were doing fairly well until the S10 line where there were three versions of the Note and non-Note models. Google's Pixel line appears to be the last to keep with roughly one phone a generation (though the 3a slightly disrupts that rule).
I eventually went for an iPhone SE (2016) in the last year, after it was discontinued and managed to get a boxed, new unit for less than even the low-end android market phones go for. Thus far it's the most enjoyable phone to use having moved from an S8 which was certainly "better" on paper.
The size is incredibly portable and easy to handle, the battery, despite only being 1500mAh, does a very good job lasting me the day (though I certainly expect it won't continue to do so) and the screen is acceptable but annoying enough that I don't want to be using it for long stretches. It's got the lastest iOS and I fully expect the lack of iOS 14 support will be the reason I have to swap it for a new model once software support falls away.
It seems like this new SE model is still the smallest phone you can get despite the increase in dimensions and weight that you mention. It's nice to see a comment that shares my view and I hope a market for the smaller phone will come back around similar to that odd stage in the early 00s where handsets suddenly became impossibly small.
Besides that, this certainly isn't the first time Zoom's shady practices have been exposed, where many other conferencing products haven't had such a track record.
As an aside, I was actually looking for a comment about the opposite issue: I have a browser which blocks autoplaying videos, it took me a while to realise that what I thought were static images, were in fact videos without playback controls (and a little bit longer to work out how to re-enable playback controls!).
Either way, once I got them playing, it looked like a slick experience, congrats on the launch!
Thanks for the correction, I admit I have limited knowledge of production ready native app development! As with the UI issue, a PWA developer could still use the JS crypto APIs to roll their own secure store for credentials, or store something similar to an API key issued on successful authentication? Handling this kind of data correctly has a lot of pitfalls, which is likely why most PWAs still use standard authentication processes.
There are APIs and specs [0] [1] [2] that have been floating about for at least the last couple of years which aim to solve credential and authentication management in a more formal way in the browser, but as with many of these features, they're slower moving than the native SDKs. I still don't believe that makes it impossible to achieve a similar flow in a PWA but I certainly concede it's much harder to get right (secure and convenient).
"Can you tell me how?"
As a disclaimer, I jumped ship to 1Password before I jumped ship to iOS, so I've never actually done this with LastPass. But this article[3] appears to offer a similar experience to what I have with 1Password:
- I go to an app or website
- A prompt above the keyboard offers to autofill with credentials
- I tap it and authenticate with 1Password (it normally pre-filters the list by app or website I'm using)
- When I make a selection it autofills everything it can
In 1Password, there is also the option to keep your OTP seed stored too, in which case it will copy the OTP to your clipboard for a short time (and slightly invalidate the purpose of 2FA...).
[0] https://news.ycombinator.com/item?id=16801858
[1] https://github.com/WebKit/explainers/tree/master/IsLoggedIn
[2] https://w3c.github.io/webappsec-credential-management/
[3] https://blog.lastpass.com/2018/09/get-in-app-autofill-with-l...
If a native app can remain authenticated with whatever service it communicates with a PWA should be able to as well, that's an implementation issue rather than a PWA issue, no? Similarly if LastPass doesn't integrate correctly to the point where you're having to manually look up details rather than having details auto-filled across websites and apps (iOS and Android both support this), that sounds like an issue with LastPass.
With all that said, it's hard to deny that it's easier to keep a mobile app performant and flexible than it is a PWA. I'd also add to your list that native apps have familiar UIs by default, which is tricky to replicate in a PWA.
In a world of docs on tap and Q&A forums aplenty, learning an esoteric branch of a small, ageing language provided a crash course in concurrent programming and a DIY mentality to problem solving that our Java assignments maybe didn't insist on.
It doesn't look like much has changed but it was nice to re-read all the same!
That would allow the attacker in straight away, while also allowing your original browser in with a bit of faff. There's an active session list, but presumably most users wouldn't be looking at that.
Certainly made me more sceptical as I was otherwise quite interested!