Not OP, but the buttons are a bit mushy, the shell a bit creaky and, worst of all, the the Steam and Quick Access buttons feel terrible. It's all much more apparent when I pick up my Switch Lite, which itself isn't something I'd consider high build quality. That said, I'm ok with the compromises considering the price point.
Am OP, and yeah this is pretty much it. For me it's the fact that it's a huge chunk of not-great-quality plastic, when all my other devices are aluminium or better plastic. I'm lucky to have had no issues with the inputs, but they are known for having problems.
I'm also absolutely fine with these trade-offs for the price point, and in fact if pushed, I'd probably rather have a £400 device like this compared to a £500+ device with the same spec made of aluminium with slightly better inputs.
I feel you. I have worked on an Angular project for over a year and was miserable working with it (and I _really_ tried to like it).
At first glance it seems "complete", but once you start building there's just so many insane edge cases that don't work well or have bugs. I also think that "integrating" RxJS was a mistake, while I get it and it's nice, it's imho too low level of an abstraction if you have many people that don't necessarily want to learn all the details (easy to shoot yourself in the foot with it), too different from anything else in JS, and too poorly integrated into angular.
And also the verbosity of everything.. was too much for me.
It's a bit weird to me that they're going with intel, is the new i7 better than ryzen processors if you count in energy efficienty (and thermal output)?
Electrical engineering. Getting a working PCB design for a modern CPU, especially in tight space constraints, is quite challenging.
It's probably something we will do in the v2 (the NUC solution has its drawbacks in terms of exposed IO and such), but I'm glad we don't have to do a full design immediately; only the carrier board that routes the NUC compute element to whereever we need it.
If you had to pick a multiplatform solution (for whatever reason) which one would you pick? I've been exploring this space a bit, and it's really hard to form an opinion on this.
I've been in that situation 3 times, I choose React Native and Flutter each once. I was forced to use Ionic. I would NEVER use Ionic again, terrible experience and very difficult to get decent quality/performance. I like Flutter's technology much more. I like that it is natively compiled. I dislike that it has it's own UI toolkit. React Native with TypeScript is a highly productive environment but I LOATHED the developer experience and any code that had performance goals was way harder to be successful with, not impossible but the threading model that RN imposes (it doesn't really thread at all) was hard to make the UI snappy and crisp as it should be. I've played with Xamarin also since I was a .net dev for 10+ years (I'm old in the industry 25 years now) and the developer experience was actually pretty good but the compile times and the UI performance were not. Though that was not a production level app and I might have been able to make it work.
tldr; If I HAD to do cross platform I'd use the following logic to choice one:
If I have a team of react JS/TS devs: React Native
else if I have a .net team: Xaramin
else: Flutter
Then I'd apply for a job writing native apps in Swift/Kotlin and run away ;)
Sorry to hear you had a bad experience with Ionic. The stack has improved considerably in recent years and actually Capacitor, our replacement for Cordova, was just rated the highest satisfaction mobile tool on the latest State of JS survey. Cordova was definitely a sore spot for Us but we’ve since moved beyond that and you can use any web stack to build apps with Capacitor (seeing a lot of React + Next.js apps of late)
This area is one that I've been pondering for a long time. In my view, the most sensible approach is to abstract the entire UI and write to the abstracted UI. Then you write the translation piece in whatever toolkit(s) and platform(s) you care about (and in whatever language is most appropriate). This hard separation of the platform and toolkit opens the door for some nice benefits (cross platform being the first and most obvious).
However, the benefits don't need to stop with cross-platform. By adding location independence to the non-application part of the code, you get the flexibility to decide later (even after the application is written) whether to deploy it as a "fat" app (application logic running locally) or "thin" (UI commands and events routed over network to your app running on a server).
I've been experimenting with these ideas for years and it's all doable. I've done various UI/toolkit implementations such as: Cocoa/ObjC, Gtk/C++, wxWidgets/C++, win32/C++, Delphi VCL/Pascal, HTML/JS, Java Swing, Java SWT, etc.
I look forward to being able to share publicly (once I decide which license to use).
If if a CRUD frontend for data, just go with mobile Web.
If doing games, Unity.
If I require some native access, Xamarin.
Finally, using C++ in a MVVM approach with native Views for anything else.
Those answers are for personal projects, at work we just do mobile Web, and with Chrome and Chrome Edge teams pushing the agenda of Web APIs =~ ChromeOS, we get to do most of the stuff we care about.
If you know the native platforms then Xamarin.Native. Shared business logic, platform-specific UI. Over time create your own Xamarin.Forms like DSL to do shared UI.
It's all nice, but where does the base load come in? From what I know Germany is decomissioning their reactors, and is replacing them with NEW coal power plants + importing energy from other countries (which is just sidestepping the problem)
What's the real solution here? If all countries did what Germany does, we'll have a lot of coal power plants, why not instead have nuclear ones? I don't know a lot about this topic, but it seems to me there isn't any viable solution here, even if nuclear costs a lot.
I haven't spotted this in this entire thread: managing energy consumption and more efficient distribution.
There's a massive demand for energy. Why? What's causing this? And is that demand really justified?
The controversial part is this: how do you do this? There are two totally naive approaches: either rely completely on free market dynamics, or heavily regulate how energy is consumed and conserved. Reality sits somewhere in between.
Then there's also a hard reality: optimization of consumption has a hard lower bound before the consequences become too painful. As a thought experiment, you could imagine a world with no electrical power plants whatsoever: but then you'd turn back the clock to how things were before the late 19th century. That's when you realize how electricity has shaped modern society over the past 150 years, but also how dependent modern society is on its availability.
Electricity is also a tradable commodity. It's a political and economical strategic asset. Part of why a radical shift isn't possible is because of existing interests who oppose anything that might cause a shift in power balances. I think it's important to recognize this as well. Especially in a discussion that promotes particular types of energy production over one another.
One potential scenario might be this:
Electricity has become superfluous. Nobody ever questions the intricacies of energy production and transport when they plug their smartphone charger in a socket. The vast majority of consumers are conditioned with the idea that a socket will always provide an infinite flow of power. It's only when power is cut off for whatever reason - brown outs, black outs, power is too expensive,... - that one starts to understand that this isn't always true. Having access to electricity isn't a human right after all.
The future might be painful in a sense that more and more people will be confronted with this painful truth. If not pro-actively and softly pushed through public debate; the circumstances - raising energy prices, availability,... - will force people to confront their own power consumption, the lifestyle they have build based on the assumption that power will always be available. It will also confront them with the inequities caused by all of this.
That's why I think it's a fallacy to perceive both nuclear and renewables as "silver bullet" solutions to avert such scenario's. Reality is far more complex.
Couldn't you do the same thing with class components though? From what you've mentioned it seems you've mostly moved complicated logic into reducers. I may misunderstand though.
>Couldn't you do the same thing with class components though?
Sure. But the point is that the entire class syntax becomes superfluous once you do that. Everything becomes a pure functional component, and you can just throw in a `useEffect` wherever the need for lifecycle based side effects arises.
