Is there any mention of what kind of radioactive decay this is powered from? Based on the name, one might assume beta? This would also track with the "research done in the 20th Century" bit considering beta radiation is just electrons.
My point being - what impact does this have on the safety of the device? Any more than certain light sources containing mercury, for example.
My partner's uncle and aunt have a holiday home right on that beach, just down from these pictures. We have of course enjoyed the privilege of staying there. We arrived in the dead of night, and there are no lights on the beach, so finding the house and then the keyhole was difficult to the point the woman next door thought we were trying to break in.
It seems to be taking a while for the framework to propagate to more independent arms of the government; as well as your example, for the (e.g.) DVLA a lot of the top level information-only pages are in the new framework (and also reside on www.gov.uk), but if you click any link to a form you get taken to the DVLA subdomain (motoring.dvla.gov.uk) and the difference is stark.
For the DVLA the site isn't so bad, but I definitely get that slightly disconcerted feeling that something is going to go wrong while you're filling out this important, official form? Which I don't get at all in the new framework.
It's not actually the interface that's the problem. It's the flow.
* you have to answer dumb security questions constantly
* you pay money in (a lot of money) by direct bank transfer with a long reference code. If you get it wrong I imagine the money is just gone. Not very reliable.
* you have to "set up a new payment" every single month because it's designed under the assumption that your bill is identical every month and it never is
Actually there is one really annoying interface thing - when you set up a one-off payment it suggests a date that is one month from now, instead of one day from now which is what you want. All it needs is a "tomorrow" button. I've missed payments several times because of this.
Oh and it tells you you can't set up a payment for today after you've submitted everything instead of on the date selector.
The specific case I know you're talking about is the woman who was in an exclusion zone that was in place to stop people harassing women entering an abortion clinic.
If she doesn't want "praying silently in her head" to be interpreted as harassment, maybe she should think about the behaviour she and her cohorts have engaged in that might have lead to this interpretation.
Sure, you can disagree with that as well, but she wasn't arrested for praying. She was arrested for intimidation and harassment. She doesn't get a special pass just because of the method.
This is a common misunderstanding. Harassing people near abortion clinics is a separate offense. The lady in question has harassed people in the past, but she was specifically arrested and charged for prayer in this case. This offense of prayer is separate to her harassment of people.
It’s like if you had drugs in your pocket while harassing someone. They’re separate offenses.
This video explains the situation and references the original police and court records.
If anyone wants to jump straight to the order itself, it's the first link under that youtube video.
> the council is satisfied on reasonable grounds that there are a number of activities, carried out or are likely to be carried out in a public space namely the area within and surrounding Station Road, Birmingham, B30, shown outlined on the map attached ( the restricted area) that have had, or are likely to have, a detrimental effect on the quality of life of those in the locality. The effect or likely effect of these activities is of a persistent or continuing nature such as to make these activities unreasonable, and justifies the restrictions imposed in this order
[...]
> The Activities prohibited by the Order are:
> i Protesting, namely engaging in any act of approval or disapproval or attempted act of approval or disapproval, with respect to issues related to abortion services, by any means. This includes but is not limited to graphic, verbal or written means, prayer or counselling,
> ii Interfering, or attempting to interfere, whether verbally or physically, with a Robert Clinic service user, visitor or member of staff,
> iii Intimidating or harassing, or attempting to intimidate or harass, a Robert Clinic service user, visitor or a member of staff,
> iv Recording or photographing a Robert Clinic service user, visitor or member of staff or
> v Displaying any text or images relating directly or indirectly to the termination of pregnancy.
She was protesting. It's a persistent pattern of behaviour. It's harassment.
By specifically calling out prayer the order does ban prayer...
In that case the woman was arrested for silently praying by herself. Her prayer was to stop the abortion clinic, but it was silent and in her own head.
I understand that the intent of the law is to ban prayer near an abortion clinic to stop harassment, but they have banned prayer.
(I support everything else in that order, I’m pro choice. I just don’t think we should ban prayer)
Any form of harassment is illegal. See the pics I posted in an edit above; the protestors make their opinions clear to visitors to the clinic, even while being silent.
Pretty sure I could walk through that area while praying and not get arrested. I'd do it by making no outward signs that I was praying. Therefore, prayer is not banned.
Also pretty sure I could get arrested in that area by kneeling on the pavement and meditating, rather than praying. I don't think "but I was meditating" would cut it as a defence, either, because what's banned is "anything that looks like protest, here are some examples".
I think it's the kneeling she got arrested for, which happens to be coded as "prayer" in our culture. In other words, she was arrested for protesting.
> Do you agree that the UK has banned some silent prayer?
This is true in the same sense that the UK has also banned breathing, because murdering people is illegal and some people happen to be breathing whilst doing their murdering.
>I don't understand the cult following around Svelte.
What I don't get is how I never (at least on HN) see any criticism of it. Like... never ever. And sure I've probably missed the odd negative post about it, but as someone who has never used it and whose entire knowledge of it is based on what I've read on here, I couldn't tell you a single supposed downside of using Svelte. And sure, it could just be That Good, but... I dunno? There's something off about that.
My team switched from React to Svelte a couple of years ago. We were working on new app, not refactoring or rewriting an old one, so we had the opportunity to choose whatever tooling we wanted.
The whole team loved Svelte. It did the stuff React did, without a lot of the ceremony or boilerplate. It was easy for the junior devs to pick up, and powerful enough for the senior devs to what needed doing.
We weren't pushing it very hard; the app was basically data entry and data display, and I assume that if you got deep enough into corner cases, it would break down like any other framework. But for our purposes, Svelte felt like someone had taken the time to understand React's issues, and fixed them.
If you want to see some criticism of svelte, one of the core maintainers recently asked about some things that could be improved about svelte in the next major version: https://twitter.com/trueadm/status/1676694161188159490
That should give you some rough ideas about the things that the community itself thinks need improvements.
I have no expectations, but I thought I might as well ask: do you know if there are any apps that will unroll a Twitter thread given a link like the one in your comment? The web version of Twitter no longer shows threads, and I've spent enough time scrolling through the shitty Twitter user page UI looking for old tweets that I'd really prefer an alternative if there is one.
I tried using it 2 years ago on a mid complexity webapp and it blew up in my face as soon as things got a little more complex. The hidden mechanics of everything made it absolutely horrible to debug. Including some serverside rendering issues in the svelte code base at the time. The pain wasn't worth it in the end. I'm probably never gonna touch svelte again without having to.
Similar experience with preact.
It works till it doesn't.
In many cases, compared to what people were using before, it really is that good.
That's not to say it doesn't have its flaws, but when people talk about how it's cleaner, they can dev and debug faster, it takes less of a cognitive load, etc. - they are being genuine.
Some of it is subjective probably, but I'd die if I had to go back to e.g. React. :)
I've been using Svelte exclusively for my projects (and at my day job) for the last 3 years. I've converted several large projects over from React to Svelte. I also do some part time work as contractor on a very large React app. I can provide you with some downsides for Svelte:
1. The developer experience with Svelte just isn't that great. Unfortunately, the Svelte team has (understandably) optimized for VS Code. I've been a WebStorm user for about 8 years and have no plans of switching over to VS Code. They just introduced Svelte LSP integration in WebStorm, but it's buggy. For the longest time you didn't get autocomplete on props with the Svelte plugin. With the Svelte LSP, you do, but I'm getting a bunch of errors from the LSP saying "x is not a module". This may be a configuration issue (I'm using pnpm workspaces and TS path aliasing). But I don't really want to go down that rabbit hole, so I just turn the LSP stuff off. It has gotten better, but it comes nowhere near the DX you get with React.
2. You technically can spread props down the component tree using $$props and $$restProps, but the documentation recommends you don't because there's a performance hit. So for stuff like "aria-" attributes, you either need to define them explicitly as props (e.g. "export let ariaLabel"), which is sort of gross, or you bite the bullet and use $$props or $$restProps.
3. Unless I'm doing something totally wrong here, using CSS nesting doesn't work the way I expect it to for scoped styles. I get that they are scoped, which is good. But if I have a button element with a child Icon component, and I want to change some CSS property in the Icon component's inner svg element using CSS nesting, it won't work:
<script>
// Icon has an inner svg element:
import Icon from "./Icon.svelte";
</script>
<style>
button {
& svg {
width: 1rem;
height: 1rem;
}
}
</style>
<button><Icon name="close" /></button>
The Icon's svg won't pick up that 1rem x 1rem sizing. I guess this makes sense because that is essentially just button > svg, which also doesn't work. But I end up having to fall back to CSS modules (or Emotion, which I stopped using because it needs a runtime).
4. I feel like the whole "$" reactivity gets overused, which leads to confusing and, in some cases, difficult to debug code. Maybe this is the ol' React dev in me (one way data flow), but 9 times out of 10, instead of binding a value to an input component, and listening for changes in a "$" block, I'm going to use the "on:input" or "on:change" event listener to capture that and just reassign the value variable.
<script>
let value = "";
// Instead of this:
$: {
// Do something with value.
}
// I do this:
function handleValueChange(event) {
value = event.currentTarget.value;
// Do something with value.
}
</script>
<input id="use-binding" bind:value />
<input id="use-event" {value} on:change={handleValueChange} />
5. This isn't a Svelte-specific issue, but I'm not crazy about single file components. I really like how components === functions in React, so you can put multiple components in the same file. In lieu of a function that returns a bunch of JSX based on some args, you can switch that over to a component with props. I think that's a really clean design that encourages good separation of concerns. In Svelte, you either end up with a bunch of extra files that need to use context + store or prop passing for state, or a giant component file.
6. Unless there have been major improvements in the testing space that I haven't taken advantage of recently, you can pretty much throw any hopes of reliable test coverage out of the window. At some point I just stopped testing my Svelte components and moved as much logic as I could outside of of the component so I could write unit/integration tests against that to get reliable branch coverage. This sort of ties into point #1, but I feel pretty strongly about having a comprehensive test suite to avoid regressions (enough to make this it's own bullet point). I don't put a lot of emphasis on the coverage percentage because that way lies madness, but it is nice to see at a glance if I'm missing a test case for a branch in the coverage report.
There's probably a few more minor gripes that I can't think of right now, but those are the heavy hitters. That all being said, two of the biggest advantages Svelte offers over React:
1. No virtual DOM. This allows you to do things like change the style of something based solely on an HTML attribute using CSS, no state variable needed. Also mentioned in the original post: you can use plain ol' JS libraries and everything just works. This is a big deal for stuff like D3, because you don't need to add any wrappers. I've had problems with React + D3 in the past, and it drove me bananas.
2. Much fewer footguns. I know this is a controversial take, but I don't like React Hooks. They're a pretty big footgun. They often require you to break up a component needlessly so you adhere to the "Rules of Hooks". Stale closures are a thing. I never had a problem with class components. I never understood the confusion around "this", which was a common defense for using hooks whenever the topic of the weirdness of hooks came up. If writing class components was still acceptable, I would be more amenable to using React in my projects. But whenever anyone I work with at the contractor gig encounters a class component, they immediately want to refactor it to a functional component with hooks. It's never even up for debate, class components bad, functional components good. Svelte doesn't have anything analogous to a hook, which makes me happy.
It depends what you mean by data. Metadata maybe, but I'd think they're meaning that once your passwords data is encrypted (on your device), it is no longer your data without the encryption key?
My point being - what impact does this have on the safety of the device? Any more than certain light sources containing mercury, for example.