Existing hearing aid products are still available for purchase for those who want them. I don’t think AirPods are going to replace hearing aids. Hopefully they lower the barrier for entry and perhaps lower the price of existing products.
If iPhone owners can improve their hearing for $250, that’s a win for a large number of people. Sure, it doesn’t solve the problem for everyone, but neither does a $2000 pair of hearing aids.
I've used Affinity for years, it was pretty much in a feature freeze state before V2 (which didn't really add anything major). I'm fine with that, it's more capable and user friendly than GIMP and Inkscape so I was happy to pay for it.
With the exception of the instruments features, Xcode’s poor refactoring features, needless animations, bad code navigation, lack of a terminal, and limited plugin support make it such a drag to use. AppCode was better in almost every regard but was discontinued.
My biggest problem with Xcode is that it really only works for Swift, while the Jetbrains stuff (incl. Android Studio) works well for a lot of languages.
Can you provide some examples of modern layout systems? I’d be curious to see what’s on offer.
I have experience with various iterations of UIKit’s auto layout, Yoga, as well as CSS and some Swift UI. I’ve found CSS to be considerably easier to work with, particularly when using flexbox and grid.
Outer
+---------------------------------+
| |
| Left Middle Right |
| |
+---------------------------------+
Everything should be vertically centered. Left should stick to the "left" of the outer div, "middle" should be centered, "right" should stick to the right. Left/middle/right can have different widths and heights.
In AutoLayout this is achieved by 6 constraints:
- left.left = outer.left
- left.centerY = outer.centerY
- middle.centerX = outer.centerX
- middle.centerY = outer.centerY
- right.right = outer.right
- right.centerY = outer.centerY
I'd like to see how you implement it in CSS. (note: extra wrapper divs are not allowed)
Chrome just added CSS Anchor Positioning this year. The other browsers also expressed interest in implementing it, with Firefox having announced an Intent to Implement. The feature would likely be available on all major browsers sometime next year.
No. You're hardcoding the item widths in `grid-template-columns`. The left/middle/right items should be self-sizing. E.g. consider three divs with arbitrary text content.
Grid allows minmax(a, b) to specify the bounds of tracks. Possible values can be the remaining free space in the parent (fr), or the size of the content in the child.
But this does not keep the center col exactly centered, but it does allow the content to take the free white space and then wrap when needed.
In your original post with Swift, what happens?
I am not familiar with auto layout so I do not know the exact behaviour vs CSS. Do you have a few screen shots of how it would handle different sized content?
But now you just added `whitespace: no-wrap` to the middle element, with `overflow: visible`, to force it into a single line. That's hardly a generic solution, because it makes assumptions about the contained items... i.e. applying `whitespace: no-wrap` and `overflow: visible` will typically break the appearance of things.
Regarding AutoLayout: the six constraints from my original comment, don't say anything about the relationship between the left/middle/right items, so they will simply overlap if there isn't enough space. This can be remedied by adding two extra constraints:
1. left.right < middle.left
2. middle.right < right.left
It's just a bunch of equations. No weird tricks, no special cases, no hacks. You describe what you want with equations, and the solver spits out the solution.
Either put left, right as absolute (like the following) and leave middle in the flex, or do the opposite. One may decide which option to use based on whether the centre or the left/right is more semantically important in the layout.
We did have to use some CSS "tricks" (transform for absolute centring), but once you've learnt those then CSS is indeed quite sane.
outer {
flex-direction: row;
justify-content: center;
align-items: center; }
left, right {
position: absolute;
top: 50%;
transform: translateY(-50%); }
left {
left: 0; }
right {
right: 0; }
(This kind of layout, which is common in eg top nav bars, is slightly deceptive.
robin_reala's solution does not conform to requirements that left and right can be different widths, which would cause middle to be not centred under simple justify-content: space-between.)
Which underlines the original point, that CSS is a hodgepodge of different ideas with no overarching system behind them. A simple task like this needed 3 different positioning systems:
1. flexbox for positioning the middle item
2. absolute positioning for left/right
3. and the translateY(-50%) trick for vertically positioning the absolute positioned items
Touché. Indeed, CSS forces one to recognise layouts that may not conform to a layout 'flow' in boxes.
In its defence, I suppose recognising this is important, as to make potential box overlaps explicit (which is typically unwanted).
CSS also handles a whole lot of things other than layout, which I'm not well informed of layout constraint systems being able to handle. Being a hodgepodge is an advantage, comparable to how its a great advantage that one can invoke any hodgepodge systems task from bash, as one single tool.
Wrong. `flex: 1` will cause the items to have a max-width of 1/3rd the container width. E.g. if the left and right items are small icons, and the middle one is a longer text, then the text will be forced to wrap into multiple lines as soon as it tries to grow beyond 1/3rd of the available space, even though there's tons of wasted space on the left/right.
The cable/charger situation was worse in the pre-smartphone era. I remember two variants of Nokia, several for Sony/Ericsson and an even greater number for Samsung. Most phones had proprietary audio connectors too. People are now able to switch between all major smartphone brands without purchasing new cables or power supplies. If you wanted to, you could just use your USB-A power brick with a USB-A to USB-C cable.
Is React irrelevant? Stack Overflow’s 2023 developer survey places it first overall for web technologies [1]. I’ve always considered React to be one of the more straightforward front end libraries, so it’s surprising to hear it being called bloated.
The fact that you have to go to often heroic measures to keep your bundle size under 500KB even for simple apps doesn't make it irrelevant or useless. It is indeed bloated: on the development boilerplate side, the bundling/deployment side, and the browser runtime experience.
With an experienced and top-notch developer, anything is possible in any language or framework. For the other 95% of devs out there—especially on a team where the lead doesn't keep a strong grip on the reins—React turns to mud awfully fast. But it's mud with an extensive ecosystem and tons of inertia helping it succeed.
> Is React irrelevant? Stack Overflow’s 2023 developer survey places it first overall for web technologies
Consider jQuery. It was extremely popular once; was super influential to the point that some of its apis were adopted by the browser; is completely irrelevant now; but is taking a long time to die. I've been wondering whether React is destined to repeat this trajectory.
The worst library except for all the others? The complexities are there for good reasons IMO; I also like React — and I look forward to the compiler allowing simpler code.
I’ve haven’t worked at a company where Figma is used “correctly”. It’s mostly used as a canvas to dump designs, slideshows, flowcharts and diagrams.
For example, N/Shift+N moves forward/backward a frame. I’m yet to see a Figma file where frames are correctly ordered or laid out, rendering this feature almost useless.
FYI - there are plugins that can help you easily order your frames by position or in other ways that make sense (I think the one I use is called Sorter).
But that's another example of the sort of hacky 'workaround' that should have first-class support if enough people need it.
You might be thinking of Objective-C metadata, which contains information about classes, protocols and categories. Unlike symbols, metadata can’t be stripped.
