OpenStreetMap-based maps tend to be much better in this regard. Although this is counterbalanced by the fact that they tend to have less data on businesses in general.
Which is not surprising, as those two have very different priorities.
- OSM want's a detailed and reliable map.
- Google maps tries to either sell your data to clients, or make you buy from them.
Their business data is their priority for maps. You can see that clearly when you look at location history changes over past decade or so. It used to be actual user location history and it was glorious. Now it's "near what businesses you were more or less, help us rate them".
It's a great moment to again remind about existence of low-friction tools that you can use to add business data (among others) to OSM, like StreetComplete app, available on F-droid and Google Play :)
I have recently tried to navigate with OsmAnd a few times where I live. Once I ended up in the wrong location, and a few times I have had to look up the business in Google Maps to find their address.
I would love to use OsmAnd more. StreetComplete sounds great and looks like a nice way to be able to contribute fixes to OSM. Thanks for the recommendation!
It is smooth and kind of "I'm doing my part!" but with low friction.
> a few times I have had to look up the business in Google Maps to find their address
Exactly my point - Gmaps taught us to expect *businesses" on maps. Not addresses. Pins and stars, instead of streets and numbers. Arrival time and traffic, instead of distance, elevation and road type (size).
I use gmaps still, mostly for businesses, but to actually know where I am I have better options. Gmaps hides most of typical map features - you see less of trees, water, buildings, height elevation. On Comaps/Osmand you suddenly can correlate map with things you see (without street view! :P).
On the other hand, I would never ever consider a traditional motocycle (partly becuase they are so noisy). But an EV one is very appealing. Exactly because it's more efficient and practical.
On the other hand, I would never ever consider a traditional motocycle (partly because they are so noisy).
They don’t come that way, jackasses modify them. My large displacement BMW is louder than our ICE car, sure, but you probably won’t notice it sitting next to you at a stoplight. And yet it still has enough power to smoke just about any car that doesn’t cost deep in six figures.
While it might be possible to get the performance required for a web rendering engine out of Java, I think you'd miserable writing Java in the style you'd need to get that kind of performance. And you'd likely still end up with issues around memory usage, app bundle size (remember that browsers ship to client devices), GC pauses, and integrating with the JavaScript engine.
The problem with a constraint system is that it would likely be even more subject to performance problems than the current setup.
IMO what CSS layout really needs is:
1. A "proportion of available space" unit. That is, something like the fr unit in CSS grid except applicable to the width/height properties so it can be used in all layout modes and without an implying content-based minimum size (like fr does).
2. A new "display: stack" (name provisional) layout mode that simply stacks boxes one after the other like "display: block" but that works in both axes, and doesn't have quirks of block layout (margin-collapsing, floats, inline-block splitting, etc).
When combining 1 and 2 you'd have a much more intutive layout system that would still give you most of the power of Flexbox and could be implemented with much better performance.
(and you'd still be able to use the existing layout modes if/when you needed to extra power)
What CSS needs (opinion, caveat, really far away in advanced features) is:
- A way to get values from sliders (type="range") (and style and modify them easily). Really, a way to get "value" from any <input> element.
- A way to have radio / checkboxes or labels inside labels work for multiple choices (or something other than making enormous arrays of radio selections and CSS choices)
- A way to have indexed arrays of numbers / choices (other than using a crazy complicated animation timing trick)
- String concatenation thats not so incredibly finicky and difficult to implement correctly
- Some way to retain the final "state" of a condition without resorting to playing an animation on "forwards" mode. Also, related, some way to not require the hidden checkbox hack everywhere.
- (Advanced, lower priority) A way to force var() calculation and optimizations other than making a zillion @property statements. "This expensive trig calculation is used a hundred times later on, better make it a separate ... nvm, it gets regex placed into every other calculation on the entire page ... " ¯\_(-_')_/¯
- If() and Function() ... wait, /inappropriate_swear, we're actually getting these after a quarter century.
It looks like HTML may be getting the ability to manipulate the class/attributes of elements in response to clicks (declaratively, without JS). Which would solve a lot of the interactivity issues (checkbox hack, etc).
Agree it would be cool, it just doesn't seem to do a lot. Generalized "popovertarget" except that basically means +modal <dialog> in most of the examples. And all the modal dialogs are almost always "popover". And you can already make "popover" appear over "popover" with multiple onscreen. Maybe there's something with looking. [1]
Main Page -> General Tests Menu -> Open Popover 1 | Open Popover 2
Should both open popovers simultaneously on top of each other while dismissing neither, and also change the state of elements on the page at the same time.
(1) could be answered with container query units. Set `container-type: inline-size;` on the parent element (falls back to the whole viewport if unset), then use, e.g., `width: 50cqw; height: 50cqh` in children. The value is a percentage of the given axis
I don't think that works if you want to mix "proportion of available space" units with siblings that have a fixed size (a super-common use case for flexbox - having a fixed size box followed by another box that takes up "the rest of the space").
My understanding is that constraint based layout performance is heavily dependant on providing lots of constraints so that the solver doesn't have too much work to do. But that the reason people like constraint-based layout models is that they don't have to provide many constraints.
Couple those together and you get poor performance. Or more specifically, unpredictable performance with lots of performance pitfalls that are hard to debug. Apple's AutoLayout is the real-world case study for this.
A constraint like "make the top of this 20px below the top of the screen" should be no more computationally expensive than "margin-top: 20px". I'm not familiar with Apple's Auto-layout but why is it so slow? Maybe you have an example of what you're thinking of.
My guess is provides the power to do layouts that are difficult to do in CSS and also more computationally expensive, so it's not that constraints are slower, but that doing more complex layout requires more computation.
Edit: https://microsoft.github.io/apple-ux-guide/Layout.html (FWIW, by Microsoft?) seems to confirm this. Performance for normal layouts is normal, doing complex things with lots of chained, dependent constraints that modify many things is slow.
So, I don't think this is a good argument against constraint systems. People can do crazy things with more power. In fact, they already do crazy things because they can use Javascript which is ultimately powerful. Adding one more powerful system isn't going to change things. Companies do have limits for loading/rendering times for websites they publish, as loose as they are.
It's constraints like "line up the left side of widget A with the right side of widget B" that can be slow. In this case no width is provided for each widget, so the constraint solver has to find one (which likely involves calling into the widgets to size themselves, adjusting the sizes according to some algorithm and then laying out those widgets again with the final size).
These are also the kind of cases where CSS layout ends up being slow. But a constraint solver based layout gives you more power to shoot yourself in the foot with.
> but that doing more complex layout requires more computation.
It's exactly this. The question is whether that makes for an ergonomic system to use for the developer. My assertion is that if there is no feedback when you create a slow layout, then it is not actually an easy system to use, and you're better off with something more constrained that guides you into the pit of success.
>It's constraints like "line up the left side of widget A with the right side of widget B" that can be slow. In this case no width is provided for each widget, so the constraint solver has to find one (which likely involves calling into the widgets to size themselves, adjusting the sizes according to some algorithm and then laying out those widgets again with the final size).
The tech giants sucking up all the ad revenue is what killed local journalism. Unless you can find a solution to that problem (or an alternstove fundong model), it's not coming back.
But just think of all the people that didn’t have to receive a paycheck because of all this efficiency!
It’s really incredible how the supposedly unassailable judgement of mass consumer preference consistently leads our society to produce worse shit so we can have more or it, and rewards the chief enshittifiers with mega yachts.
Lots of the traditional car manufacturers now have good options: Renault, Nissan, Kia, and Hyundai's EVs seem to be particularly well regarded. I'd definitely opt for any of those over a Tesla given Tesla's reputation with regard to quality and repair costs.
If you ignore cost, then Tesla's cars are probably still better at this point, but the gap doesn't seem that large.
Even BMW has a few electrical cars that aren't half bad. The main problem is that they are compromise cars that can be sold as ICE, PHEV, or full EV.
That means more complexity, sub optimal design, less efficiency, etc. However, competition is indeed brutal right now. Tesla did something that only some other manufacturers have managed to copy so far: make cars that are EV only from the ground up. Love them or hate them, they don't make any design compromises to allow space for a combustion engine, a generator, or whatever. There's no room for a transmission, a fuel tank, or even an engine compartment. That's where the Frunk goes. The result is a car that's simpler, more efficient, and more optimal for what it does.
BYD did the same. Kia and Hyundai are having a lot of success with their electric only line of cars. And in the EU Renault and the Stellantis group have some decent and competitive low cost models on the market. Tesla's advantage is rapidly evaporating here.
Japanese car makers have been more conflicted on this. But Nissan's collaboration with Renault is giving them access to the right tech to adjust course. And even Toyota is now using a lot of Chinese made drive trains and components to finally offer EVs that are actually not that bad. The danger is of course that "made in Japan" has very limited value in this world if all your core tech is effectively Chinese and European. That's something that might change in the next years of course.
Cost wise, buying a compromise car means having to deal with more that can break, more components that may need replacing, and a lot of increasingly obsolete parts and components that are no longer being modernized. Combustion engine R&D ground to a halt about fifteen years ago. All those fuel injection systems, and other computer intensive hardware that keeps them going is aging fast and not really being invested in a lot at this point. Sourcing replacement parts might get harder and more expensive over time.
> Tesla's reputation with regard to quality and repair costs.
Tesla lives in the limelight 100x more than any other car brand. Every mistake or possible scandal gets insanely amplified. They are by far the most repairable EV car and have the most durable engines. What they do not tell you is that in an EV the engine giving out is the more common scenario not the battery pack.
reply