> Just yesterday I was thinking hmm, copying the .env seems like a shitty way to store env vars.
It really depends on the context. Docker already supports defining env cars in container images, so it makes no sense to sneak a .env file into a container image. If all you're doing is setting env cars locally to run a container then if those env cars don't include secrets then it's pretty safe. However it would be preferable if those env cars are handled by the container orchestration system. For instance, docker compose files also support specificing env variables, as well as Kubernetes.
I hate this. I have 2 accounts with adsense, no recovery email because google banned all adsense account associated to my old emails (in 2012), which was not my fault. So I know the password, I know the email, still can't login because that phone number expired.
to login to my Outlook need get code from old email account then again get another from different email account then get code from phone that is is pay as you go and mostly turned off and have to charge battery. so login to my email is like 30 minutes of dealing with codes and different shit.
Ebay is the best need know usernames of other users who live in my old flat 10 years ago.
Try to login to PayPal,ebay, outlook gmail from mexico or Vietnam captcha every 10 minutes everywhere how this people can live like this
every other time i try to log into paypal it insists on verifying my identity by calling me, started a couple months ago. it certainly has somewhat dampened my online spending, so I'm not entirely against it
I'm a full time Android dev, who's also a intermediate in web dev. When I first started using compose / flutter, I assumed it was for the best, since I didn't have to learn anything new. I battled myself everyday, whether or not I had to learn React. My views are pretty clear now.
React with PWA - For my internal projects.
React & Android app with Kotlin - For Products I ship.
Ended up learning and liking react!
Like pier25 has pointed out, I don't think it's worth loading
2 mb for a single button. So as painful as it maybe to have 3 code bases for 3 platforms, IMO gives the user the best experience.
I think it'll get optimized. We went from GWT apps needing like 250k to render a HelloWorld, to J2CL + Closure Compiler being able to do the same thing with a 1 line output.
Compose has an elegant, theoretically pleasant way of modeling reactive frameworks as pure functions with memoized state, and an explicit call stack.
But right now you're paying a giant tax for all this since you bring in the entire Kotlin runtime, coroutines, collections, etc plus the Compose runtime, plus the Widget library. Since Compose is only beta right now, this is clearly unoptimized.
It's definitely not eliminating all the dead code or metadata it could, there's a ton of code like this:
GWT is still being used, no one needed to adopt J2CL, and with judicious use of code splitting, the enterprise apps it was designed for worked fine. It’s still being activity developed and used by the open source community.
There are plenty of SPA JS projects that send down a MB of JS.
A lot of the tech JS frameworks adopted in the last few years was shipping in GWT more than a decade ago: tree shaking, uglification, sprite sheets, style sheet languages, compiler directed code splitting, etc
GWTs Achilles heel was it was developed to paper over differences in browsers from the IE4 era, and so the widget model design is a left over heavyweight legacy from needing to make modern and ancient browsers work similarly.
