If you're not developing an iOS/macOS app, you can skip Xcode completely and just use the `swift` CLI, which is perfectly cromulent. (It works great on Linux and Windows.)
There'a great indie app called Notepad.exe [1] for developing iOS and macOS apps using macOS. You can also write and test Swift apps for Linux easily [2]. It also supports Python and JavaScript.
If you hate Xcode, this is definitely worth a look.
So wait this thing is real? Calling it notepad.exe gave me the impression that it's just an elaborate joke about how you can code any program in Notepad...
I would avoid it for Linux and Windows. Even if they are "technically supported", Apple's focus is clearly macOS and iOS. Being a second- (or even third-) class citizen often introduces lots of issues in practice ("oh, nobody teenaged that functionality on Windows"...)
Even if you're developing for macOS you can skip xcode. I've had a great time developing a menubar app for macOS and not once did I need to open xcode.
Also, a real nightmare for the municipal trade unions. (Do you know why every NYC subway train needs to have not one but two operators, even though it could run automatically just fine?)
Huh. I wonder if that makes any sense. It doesn't seem to make sense to keep employing people if you no longer need them. It sucks to be layed off, but that's just how it works.
It also shows a lack of imagination. If you have to provide a union with a job bank, why not re-deploy employees to other roles? With one person per train, re-deploy people to run more trains therefore decreasing the interval between trains. Stations used to have medics but this was cut. How about re-train people to be those medics? The subway could use a signaling upgrade and positive train control. Installing platform screen doors to greatly reduce the incidence of people falling onto the tracks is going to need a lot of labor.
Mass transit is a capacity multiplier. If 35 people are headed in the same direction compare that with the infrastructure needed to handle 35 cars. Road capacity, parking capacity, car dealerships, gas stations, repair shops, insurance, car loans.
First, these cities should be fixed by removing the traffic magnets. It's far past the point where we used the old obsolete ideology of trying to supply as much traffic capacity as possible.
But anyway, your statement is actually not true anywhere in the US except NYC. Even in Chicago, removing ALL the local transit and switching to 6-seater minivans will eliminate all the traffic issues.
Car traffic magnets like highways inside urban cores? Or people traffic magnets like office buildings, colleges, sports stadiums, performing arts venues, shopping malls?
Large stadium arenas are a special case, but they don't create sustained traffic, and their usage periods typically do not overlap with the regular rush hour.
That's the testing matrix we have to do for iOS and Android apps today. The screen sizes don't go all the way up to ultrawide, but 13" iPad (portrait and landscape) down to 4" iPhone Mini, at every "Dynamic Type" display setting is required.
It's not that tough, but there can be tricky cases.
I think the industry settled on pretty good answers, using lots of XML-like syntax (HTML, JSX) but rarely using XML™.
1. Following Postel's law, don't reject "invalid" third-party input; instead, standardize how to interpret weird syntax. This is what we did with HTML.
2. Use declarative schema definitions sparingly, only for first-party testing and as reference documentation, never to automatically reject third-party input.
3. Use XML-like syntax (like JSX) in a Turing-complete language for defining nested UI components.
Think of UI components as if they're functions, accepting a number of named, optional arguments/parameters (attributes!) and an array of child components with their own nested children. (In many UI frameworks, components literally are functions with opaque return types, exactly like this.)
Closing tags like `</article>` make sense when you're going to nest components 10+ layers deep, and when the closing tag will appear hundreds of lines of code later.
Most code shouldn't look like that, but UI code almost always does, which is why JSX is popular.
HTML elements can style themselves now using the @scope rule. (It's Baseline Newly Available.) Unlike the "style" attribute, @scope blocks can include @media and other @ rules. You can't get more self-contained than this.
The reason approaches like this continue to draw crowds is that Web Components™ as a term is a confluence of the Custom Elements JS API and Shadow DOM.
Shadow DOM is awful. Nobody should be using it for anything, ever. (It's required for putting child-element "slots" in custom elements, and so nobody should use those, either.) Shadow DOM is like an iframe in your page; styles can't escape the shadow root and they can't get into the shadow root, either. IDs are scoped in shadow roots, too, so the aria-labelledby attribute can't get in or out, either.
@scope is the right abstraction: parent styles can cascade in, but the component's styles won't escape the element, giving you all of the (limited) performance advantages of Shadow DOM with none of the drawbacks.
Decoupling slots from shadow dom would make custom elements even better.
I love custom elements. For non React.js apps I use them to create islands of reactivity. With Vue each custom element becomes a mini app, and can be easily lazy loaded for example. Due to how Vue 3 works, it’s even easy to share state & routing between them when required.
They should really move the most worthwhile features of shadow dom into custom elements: slots and the template shadow-roots, and associated forms are actually nice.
It’s all the extra stuff, like styling issues, that make it a pain in the behind
There's really no way to decouple slots for shadow roots.
For slots to work you need a container for the slots that the slotted elements do not belong to, and whose slots are separated from other slot containers. Otherwise you can't make an unambiguous relationship between element and slot. This is why a shadow root is a separate tree.
Agreed. The way I explain it is: suppose you have a `<super-table>` element, and you have a child slot called, for example, `<super-row-header>`. Presumably you want to write some JS to transform the slotted content in some way, decorating each row with the header the user provided.
But, if you do that, what happens to the original `<super-row-header>` element that the user provided? Maybe you'd want to delete it…? But how can you tell the difference between the user removing the `<row-header>` and the custom element removing it in the course of its work?
What you'd need is for `<row-header>` to somehow exist and not exist at the same time. Which is to say, you'd have one version of the DOM (the Light DOM) where the slot element exists, and another version of the DOM (the Shadow DOM) where the `<row-header>` element doesn't exist, and the transformed content exists instead.
It's clever, I guess, but the drawbacks far outweigh the benefits.
Client-side components inherently require JS anyway, so just use your favorite JS framework. Frameworks can't really interoperate while preserving fine-grained reactivity (in fact, Shadow DOM makes that harder), so, just pick a framework and use it.
That's styling itself sure, but it's not self-evidently self-contained. Does every component emit those styles? Are they in the page stylesheet? How do they get loaded?
Counterpoint: Shadow DOM is great. People should be using it more. It's the only DOM primitive that allows for interoperable composition. Without it you're at the mercy of frameworks for being able to compose container components out of internal structure and external children.
Sort by negative sentiment; Shadow DOM is at the top of the list, the most hated feature in Web Components. You can read the comments, too, and they're almost all negative, and 100% correct.
"Accessibility nightmare"
"always hard to comprehend, and it doesn't get easier with time"
"most components don't need it"
"The big issue is you need some better way to some better way to incorporate styling from outside the shadow dom"
> It's the only DOM primitive that allows for interoperable composition.
There is no DOM primitive that allows for interoperable composition with fine-grained reactivity. Your framework offers fine-grained reactivity (Virtual DOM for React/Preact, signals for Angular, runes for Svelte, etc.) and any component that contains another component has to coordinate with it.
As a result, you can only mix-and-match container components between frameworks with different reactivity workflows by giving up on fine-grained reactivity, blowing away the internals when you cross boundaries between frameworks. (And Shadow DOM makes it harder, not easier, to coordinate workflows between frameworks.)
Shadow DOM sucks at the only thing it's supposed to be for. Please, listen to the wisdom of the crowd here.
> There is no DOM primitive that allows for interoperable composition with fine-grained reactivity. Your framework offers fine-grained reactivity (Virtual DOM for React/Preact, signals for Angular, runes for Svelte, etc.) and any component that contains another component has to coordinate with it.
This just isn't true - composition and reactivity are completely orthogonal concerns.
Any reactivity system can manage DOM outside of the component, including nodes that are projected into slots. The component's internal DOM is managed by the component using whatever reactivity system it desires.
There are major applications built this way. They make have a React outer shell using vdom and Lit custom elements using lit-html for their shadow contents.
On top of those basics you can also have cross-shadow interoperable fine-grained reactivity with primitives like signals. You can pass signals around, down the tree, across subtrees, and have different reactivity systems use those signals to update the DOM.
You can do it, but that undermines the whole point of React: fine-grained reactivity.
If the child component had been a React component instead, the children would have participated in the virtual DOM, and React could do a minimal DOM update when it was done.
React can't even see the shadow contents of Lit elements, so React just has to update the light DOM and let Lit take over from there.
(Same applies to Vue, Angular, Svelte, Solid, etc. Each framework has a reactivity system, and you have to integrate with it to get its benefits.)
You still get minimal DOM updates crossing shadow boundaries. This is true fact.
React's vdom without shadow DOM passes props to components, which all return one big vdom tree, and then there's one big reconciliation. React used with shadow DOM evaluates smaller vdom trees per shadow root, and does more, but smaller reconciliations. It's the same O(n) work.
But in reality it's often much _better_ with shadow roots because the common WC base classes like Lit's ReactiveElement all do change detection on a per-property basis. So you only regenerate vdom trees for components with changed props, and with slots that doesn't include children. So if children of a component change, but props don't, the component doesn't need to re-render. You can do something similar by hand with memo, but that doesn't handle children separately. The compiler will, of course, fix everything.
Every other reactivity system works fine across shadow boundaries. Even the super-fine grained ones like Solid. The only issue with signals-based libraries like Solid is that they pass signals around instead of values, so to get true no-re-rendering behavior with web components you have to do that to, which means picking a signals library, which means less interoperability. The TC39 signals proposal points to a future where you can do that interoperably too.
I feel like it’s a niche feature that got way too much attention. In a past job, we maintained a widget customers could embed onto their page. How much trouble we had with parent styles creeping into our widget and ruining the layout! This would have been so much easier with shadow DOM effectively isolating it from the customer site; that is the only valid use case for it, I feel.
Yet, for actual web components, I entirely agree with you.
Yeah but most people don't need or want 'interoperable composition', they want sites with a consistent look-and-feel. Shadow DOM makes this much more difficult.
I haven't played with the Shadow Dom since Polymer one, but we had defaults and variables to address this that worked amazingly, and helped standardize it with other teams far better than other css things we had done at the time. It looks like that is still a thing - https://shadow-style.github.io/ - without which people injected things through the CMS that were not fun to deal with.
I've reviewed this and your other comments on the thread, and I think you're making a mistake, believing that to solve the loneliness epidemic, you primarily need to "reach people."
As long as leaving the house and making real contact is harder (requires more self discipline) than staying in and scrolling, all you can do is project a message to folks at home, like "hi, you're not alone in feeling lonely," but you haven't solved the fundamental problem: it's harder to do the right thing than it is to do the wrong thing.
To solve the loneliness epidemic, you have to make the right thing easier than the wrong thing. "Reaching out" to more people will not accomplish that. Elsewhere in this thread, you've rejected the idea of pursuing a public policy, but policy is the only answer anyone's provided in this thread that could make that happen.
(Now, it turns out that you'll have to do a lot of outreach to make a public policy happen, but you'll be asking for their vote, not a regular commitment to show up weekly at a club; outreach is the right approach to that problem.)
You're answering the question, "In a loneliness epidemic, what can I do to be less lonely?" Your answer is to use self discipline (which is hard) to get out of your house consistently, a decent answer to that question.
To actually fix the loneliness epidemic, you'd have to get everyone else to do that.
In the 20th century, getting out of the house consistently was the easiest way to interact with other people. Now, you can interact with lots of other people (in a less satisfying way) without leaving your house. What's going to fix that?
How do we get everyone to eat better? How do we get everyone to get enough sleep? How do we get everyone to exercise more? "Just tell them to do it" won't work. "Why don't we all just put our phones away?" won't work. We'd need a policy.
(My best guess: in the US, mandate that health insurers pay for therapy, and provide therapy at low/no cost in countries with national health care.)
I was with you up until you said policy was the solution. No, action must come first. Policy needs people to agree on it, and can take a long time to enact. Action can be done now, and allows experimentation and disagreement. I am looking for actionable solutions that I can experiment with as one lone individual with time to spare on Sundays.
If you're looking for individual advice, instead of "solving" the whole epidemic, then here's mine.
To solve loneliness for yourself, you've got to get out of the house more. But, deep down, you already knew that, right? Just like we all know we should exercise more, eat better, etc. Self discipline is hard.
So, my advice for that is to work with a therapist. A therapist can help you do the thing that you know you need to do but can't make yourself do.
People often think therapy is only for "serious" problems, but it's great for just helping you to stop sabotaging yourself (and we all sabotage ourselves, in big ways and small).
Therapists have regularly scheduled appointments, which also helps in its own right. (You'll get better workout results if you exercise weekly with a trainer.)
Scheduled recurring appointments make it easier to attend other social gatherings, too. The chess club means every Tuesday night. People will be watching Monday night football at the bar. Church is on Sunday. (Temple is on Saturday, Jumu'ah is on Friday, etc.)
But you knew all that, already, too. To do what you already knew you need to do, try therapy.
For the whole thread, it's open-ended. People can brainstorm whatever they want to based on the title. It's good that it's ambiguous. The more conversations, the better.
But for me, I'm looking for ways that I can help solve other people's loneliness, both on an individual basis, and eventually en masse, but still me doing something as one individual.
This is what all my replies have been about, and why I posted one top-level comment asking that very specific question. I want to know what individuals can do that's actionable to help other people.
Investing in free places where people can do cool things in public like libraries can help. Investing in public transportation so that more people can get around easier can help. Making sure that people have enough money that they don't need to work 2 jobs to get by and they aren't under constant worry of not being able to pay rent would help. Making sure people are able to get the healthcare they need so that they are feeling well enough to go out places would help.
It's hard to act when you're sick and exhausted and physically isolated and broke and there's nowhere in public filled with people worth visiting. Policy can help improve that situation so that action can happen.
> I am looking for actionable solutions that I can experiment with as one lone individual with time to spare on Sundays.
Since you've probably already got the time, energy, and money to invest this should be pretty easy.
The easiest answer? Go find a protest group. There are people out pretty much every week all over the place. You'll meet tons of very friendly people and you'll already have something to discuss with the strangers you meet. You can spend your weekends with new passionate people outdoors holding signs and marching around. Doesn't get more actionable than that. Comes with a low risk of getting shot or teargassed and a high risk of being profiled by the feds (although these days who isn't on a list right?)
Not political? Volunteer helping people. Soup kitchens, homeless shelters, and food banks are a great place to start. You'll be doing something good for others in your community and get a chance to meet and speak with other volunteers and the people you're helping. (Fair warning: repeated exposure to good people who are struggling may cause you to become more political)
Are you active? Join a sports team for a sport you enjoy or have always wanted to try. There are usually local groups looking for members and again you'll be starting with something to talk about and a shared interest.
Pay for classes in something you're interested in. Meet your teachers and classmates. Learn something cool in the process! Works best if you're learning something that requires you to create or do something.
Not in a relationship? Try dating. Be open about the fact that you're just looking to meet more interesting people. (this tip works infinitely better if you're a woman, but if you're comfortable with rejection, patient, and able to pay for multiple dating apps for indefinite periods of time where you don't get any takers it can work for almost anyone).
Pick a local bar and become a regular. Pay attention and if after a month or two you haven't clocked who the other regulars are pick a different bar and repeat. Once you've found some other regulars introduce yourself. As a bonus you'll both be socially lubricated when you meet and if it goes badly you can drown your sorrows in more drinks.
Like to drink but want to meet fewer alcoholics? Do the same thing but go to bars during karaoke and/or trivia nights.
Nerdy? Check gaming stores or the internet for a D&D group looking for members or even better look up where your local Society for Creative Anachronism meets and go there. You can meet people while you learn blacksmithing, or calligraphy, or archery.
Religious? Tour churches. This can be pretty fun even if you aren't religious. Most people will be very friendly and welcoming (results may vary depending on the church and your color/sexual orientation).
100%. Telling people they just need to work harder and do better feel like good advice but it isn't going to solve a population scale problem. Sure _you_ should do it because it's the only thing you can directly control, but also understand it isn't going to solve the problem an entire society is facing.
In the 20th century you left the house because otherwise you were bored.
I love being alone but I am not "lonely" and I am never bored.
When I go for a walk on a beautiful summer night in America, always alone, there is rarely anyone outside. They are in the house, mostly alone unless they have a partner/kids.
I think we have a loneliness epidemic because we have a culture that makes it fun to be alone. Some people don't like this level of being alone but many do. Those that do aren't really going to pitch in to help so I am not sure what the solution is. You can throw a party but I am not going to show up. I would rather be alone. This is enough interaction. There is also a culture of narcissism, hyper stimulation or both involved I imagine. I can't just close the browser window in person if the conversation seems boring or jump to something more interesting instantly.
I would even say that being alone is more fun now than hanging out at someone's house in the 20th century. There is just so much more to do. The group was less bored together but it was still pretty boring then. That is why going to the bar was so popular. Not much else to do then besides get drunk and smoke cigarettes in groups to get rid of the boredom.
> The plan is however to open source when Orion is self-sufficient (business model of Orion is you are the customer and can pay for it - like we used to pay for browsers 20 years ago before advertisers started paying for our browsing), meaning it can sustain its own development independent of Kagi Search.
Orion will never reach "self-sufficiency" as long as you don't actually charge for Orion. Orion is completely free to use. I can donate to Orion+, but Orion+ offers no paid features; it's basically a Patreon. https://help.kagi.com/orion/orion-plus/orion-plus.html
(No major browser has ever sustained its own development independent of a search engine's funding, not even Netscape, which charged $40/seat in the 1990s, with a free "shareware" tier so generous that hardly anyone paid. Netscape was funded by advertising, especially from Yahoo search. Funding browser development entirely on donations to a commercial business would be completely unprecedented.)
What if, instead, you made Orion "source available" to paying customers, but not open source? You could merge PRs only from users who sign a CLA. (Users would file PRs out of charity, for the same reason they sign up for Orion+ today.)
reply