Once you get into a mindset of quality not mattering and only pushing down the costs there’s no coming back. Look a large retail brands and how disposable we treat things. They went from northeast to southern US to Mexico to China. The creation of the product will happen in the US for cultural reasons (you cannot outsource marketing generally), but it all hits a wall.
> Don't use those...then an additional 4.9% can be handled with jotai...
Needing Jotai on top of React's defacto state management is the issue. TFA talks about an ecosystem of libraries that attempt to fix React's shortcomings. Pure React does have undeniable shortcomings like proper, non-brittle routing.
I agree with you about routing. Something so core about building web apps should be treated as a first class citizen of the ecosystem.
I don't think jotai adds a lot of complexity though, and like I said most of the time you don't need it. It just makes syntax a bit nicer to read and write, but you could do it with context if you really wanted to.
This is accurate. Their competitor, the Ecovacs Deebot, just push an OTA update making cable detection way better. In a way the previous comment encapsulates all the misconceptions about robovacs. I was recently surprised to learn how good they are because my only basis for comparison was my friend's failure of a Roomba that's always getting into shenanigans.
Right–that's what I found so weird about the Amazon acquisition of iRobot is that Roombas are clearly a few generations of technology behind their competitors like Neato, Ecovacs and Roborock...but they must have a bunch of similar technology currently under development and on the way to market. What Roomba does have is name recognition, which seems to mean that most people think that robot vacuums aren't very good–I suspect Amazon sees they get tons of sales on their platform, has a good R&D team/patents, and smells an opportunity to own the space by pouring money into it and helping them compete (and, of course, putting them to the top of Amazon results, as they always do).
To expand on this OP, I've done the AWS-full-stack approach in a mid-sized startup. Modern Serverless problems require modern serverless solutions. That ecosystem is simply not as developed as "traditional" web-server CI/CD. Here are some things that you will eventually need to optimize for.
- After crossing a certain threshold in scaling needs, Lambda costs more than regular EC2 on ELB
- Lambda cold-start times can be a deal-breaker when users first visit your website. If you contact AWS they will tell you to setup a simple cron job that keep lambdas "warm". But AWS provides no visibility in what's warm or cold, or which endpoints link to which lambdas.
- Dealing with Cloudwatch logs of various lambda runs (IMHO) is objectively a bad dev experience. Query insights is getting better, but is still a pain to work with.
- To reduce deployment and development times, you'll eventually want to deep-dive into lambda layers. Modern problems modern solutions.
- One lambda calling and awaiting another lambda is not a supported first-class use-case. There's no API that allows you to get the status of a lambda run. There's a hack around this where you use AWS Step-Functions. Modern problems modern solutions.
We're still on AWS full-stack "serverless" for our webserver and realtime stream processor. At the time I didn't know what I was getting my company into. I wish I just made a Flask webserver instead.
Nobody will suggest Java, but honestly Java. Java has pretty great flexibility when it comes down to concurrency. It sets the standard which all the other languages have to compete with.
Apart from that, I like languages and frameworks that scale out of their box and into the world of distributed systems. Elixir is very cool, because the concept of distribution with message passing is built into the core of the language. Alternatively, Scala's Akka Framework operates on a similar concept of passing messages to Actors. My bias here is that I don't like to deal with very large super-computers, and would rather have multiple smaller machines that are allowed to blackout occasionally. This is especially relevant for websockets because the stateful connection to a client can be made on any single machine in a cluster, but the state itself is (often) global.
I'm going to sound very elitist, but there is 0 chance I'm going to use Java. Aside from my own bad experiences with Java in a professional setting, .NET Core is now a thing, and I'm actually very experienced with C#, so I'd rather just use C# at that point rather than become proficient with Java and the JVM.
SPAs exist for a reason. Same with SSR. Developer ergonomics play a bigger role than you think. And if you think that the choice is either SPA or SSR then you haven't been paying attention to recent developments in the frontend world.
Websockets+SSR (PhoenixJS) attempts to store state on the server rather than the client; in that way you can still have stateful interactions with minimal JS. NextJS does an amazing job patching the bridge between SPA+SSR by having the same codebase run on the backend and the frontend. What I would like to see more of from this industry is less "grass is greener on the other side" and the unification of a single tool that allows for the cross-collaboration of SPA + SSR without having two distinct codebases that one has to context-switch between.
This is my #2 problem with Ruby, and it's also the reason why a lot of folk love it. I think of macros in the same way I think of RegEx, if you're writing one you better hope it works perfectly because chances are that you'll be the only one to maintain it.
Other Ruby "features" that I dislike:
1. Blocks + Procs + Lambdas are all function-adjacent. Can't we just call them functions?
3. Out of bounds indexes on Arrays/Maps return nil.
4. method_missing() is super cool and super abusive. Again it feels like magic when functions come from nothing.
> Blocks + Procs + Lambdas are all function-adjacent. Can't we just call them functions?
Well, Ruby has functions, they're just called Procs. Lambdas are a special, more strict breed of Procs, and blocks are just (pretty complex) syntax sugar for passing a Proc to a method. The main function-like concept is always a Proc.
> Out of bounds indexes on Arrays/Maps return nil.
Calling the #[] or #slice method on an Array with an out-of bound index returns nil, calling the #fetch method raises an IndexError or returns an arbitrary default value. You can use whichever suits the situation.
Ruby on Rails is awesome to write, horrible to maintain. It’s the fastest way to build a web app but good luck with staying productive once you have 100 engineers working on it and a million lines of rails soup to wrangle.
