chrisldgk

Reading this, it doesn’t seem like they’re really doing anything more than building a glorified raspberry pi with their own self-spun BSD distro preinstalled. Also the FAQ being mostly Q: „why not use X?“, A: „I don’t know X and thus it’s bloated/I don’t like it“ doesn’t inspire a lot of confidence.

I admire their dedication and it seems like a fun project. I don’t think it’s something a lot of people will pay money for though.

Haven’t tried the app itself too much, but that UI is great. Really love the modern approach to skeumorphism. Whoever your frontend designer/dev is, you’re lucky to have them.

Might yoink the general style for one of my side projects.

This is neither 4chan nor Reddit, if you don’t have anything to add to the conversation other than cheap quips, this is not the place for you to post.

I agree I would prefer if OrbStack were open source, but there’s a place and value in high quality closed source apps within the ecosystem. They do also open-source parts of the application, which is more than a lot of closed source developers do. If nothing else, maybe someone can find a way to utilize the advancements that OrbStack provides and can make an open source alternative.

If you haven’t tried it yet, I can recommend OrbStack[1] for container things on macOS. I don’t use it for anything more than spinning up dev DBs locally, but I know it supports Kubernetes in some form or another.

[1] https://orbstack.dev

It’s good for firing off an async function in sync contexts, like for example a fetch request with side-effects being called by React‘s useEffect hook. That‘s the only context where I found any value for it though, and its usefulness is only in describing that we really don’t care if it finishes or not (since handling that case will happen somewhere else) directly in the function call.

I agree, the Steam Mac app is a lot worse than it is on Windows or Linux. I would suppose that’s because they’re just running it in some kind of wrapper rather than having any kind of native implementation, that’s just an assumption based on how it feels to use though.

Not that guy, but for highly dynamic and interactive sites, it’s actually easier to manage state if you‘re working on the client side only.

Introducing SSR and data handling on the server side to an app can be much less productive if you don’t need the performance improvements that SSR brings.

I personally wouldn’t go that far, but I would say he’s at least riding the hype wave to get funding for his company, which, let’s be honest, nobody would care about if we weren’t this deep into the AI hypecycle.

I‘d say there’s a third option - anyone working in the space realized they can make a fuckton of money if they just say how „dangerous“ the product is, because not only is it great marketing to talk do that, but you might also get literal trillions of dollars from the government if you do it right.

I don’t have anything against researchers, and I agree I know a lot less about AI than they do. I do however know humans, and not assuming they’re going to take a chance to get filthy rich by doing something so banal is naive.

To be clear I was just bunching high profile AI founders and CEOs that can’t seem to stop talking about how dangerous the thing they’re trying to build is together. I don’t know (nor care) about Ilyas and Altmans current relationship.

Not to be too pessimistic here, but why are we talking about things like this? I get that it’s a fun thing to think about, what we will do when a great artificial superintelligence is achieved and how we deal with it, feels like we’re living in a science fiction book.

But, all we’ve achieved at this point is making a glorified token predicting machine trained on existing data (made by humans), not really being able to be creative outside of deriving things humans have already made before. Granted, they‘re really good at doing that, but not much else.

To me, this is such a transparent attention grab (and, by extension, money grab by being overvalued by investors and shareholders) by Altman and company, that I’m just baffled people are still going with it.

I agree to some extent, though there is a point to make about going with the basics first. React isn’t really a Blackbox, it‘s mostly written in plain old TypeScript and the internals don’t really do anything you couldn’t write yourself. What you should do however is rather than starting with a big framework like React as a beginner, start out with the absolute basics in plain JS. Learn how the language works, learn to manipulate the DOM yourself. Then, when you understand the basics, you can start appreciating what React does for you and understand (to some extent) how the underlying systems work.

Where I agree though is that you don’t have to learn all the basics before you can proceed. I’ve been writing frontend code in for about six years now and I catch myself learning something new about browsers, web infrastructure and JavaScript itself nearly every day.

All this is to say, don’t be afraid to both start at the beginning and understand the basics, and skip ahead a few chapters and try new things and learn as you go.

We’ve found him, we’ve found the one guy that likes debugging. Honestly though, good for you. There need to be more people like this in the world.

It’s not super practical yet, a lot of software won’t run on it and they even write in the article that processing power wise it will probably be worse than their x86 counterparts. As they write in the article, the point is to make developing for RISC-V more accessible so that it can find wider adoption and get over those hurdles at some point to become more mainstream.

This is an unfair side jab at Deno, it’s not being used as widely as Node (yet), but it’s the go-to edge runtime beside Cloudflare workers and the underlying system powering Supabase functions.

Yes, though server side rendering is everything but a new thing in the react world. NextJS, Remix, Astro and many other frameworks and approaches exist (and have done so for at least five years) to make sure pages are small and efficient to load.

Turns out it’s the same company that makes the wristbands for the Coldplay shows, so chances are it’s the exact same here

While we‘re here I‘d also like to recommend react-email[1] which I‘ve been using for building emails for a while now. The components it offers are more than enough and it‘s definitely better than building mails with <!—MSO—> tags every five lines like we did back in my email marketing days.

[1] https://react.email

I think it’s funny, and I see it more as a stylistic choice to vent the author‘s frustration with the process than an actual reflection of their character. It is just their personal blog overall.

Edit: Gender neutral language

I believe you hit the nail on the head there.

That, together with the fact that you can still host the deno runtime on your own hardware actually makes it a pretty viable alternative to new projects that you would be building using NodeJS otherwise, with the added bonus that if you ever decide to go serverless, you don‘t have to rewrite your code since you can take the same codebase and move it to deno deploy (or supabase functions, which just uses deno under the hood itself)

While I haven’t tried it myself yet, I remember finding nest.land[1] and thinking decentralization is a beautiful approach to something as centrally important to the JS development world as packages are.

I also remember thinking it‘s the first and only thing I‘ve ever seen where using the blockchain as the technical basis for it makes sense and isn‘t tacked on for grfiting purposes.

[1] https://nest.land

Though I‘m not sure if it will get adopted by as many people as NodeJS (and other kind-of drop-in replacements like Bun) did, I‘m really excited by the innovation that Deno brings to the JS/TS space. Particularly actually looking at the hassles that working with NodeJS currently brings and trying to find elegant solutions to that is an admirable goal. If Deno doesn‘t get adopted by many people, maybe at least some of these ideas can later find their way into other runtimes.

As anyone that has tried to publish hybrid packages that include types, a CJS and an ESM version, all the while maintaining semver and anything else can be a real hassle. Everyone seems to have a different solution, and most of the time you end up writing a convoluted build system for your package consisting of an amalgamation of tsc, esbuild, rollup or whatever other bundler is the hot new stuff.

Don‘t attribute to mal-intent which you can attribute to stupidity.

I believe most people that do this kind of thing do it because they don‘t know there‘s a native API that works better for these things.

Remember, the software engineers that are good at their jobs aren‘t the ones that end up teaching at coding bootcamps.

The good thing about all this is that a lot of things also combined into single languages and that you can still spool up everything you need to run on a cheap VPS or even a small computer at home.

Need to build a backend? JavaScript and NodeJS. Need to query a database or store data? JavaScript and an ORM of your choice. Need to build a frontend? JavaScript and a frontend library of your choice.

My point is the only thing you actually need to know is a single language and you can build anything you want. This extends to PHP with Laravel, C# and Python as well. Getting into developing things got a lot easier because you don‘t need to get into the nitty gritty of how a web or database server functions.

Obviously there‘s stuff like CI/CD, logging and error tracking that‘s a lot harder to do without PaaS solutions, not to speak of scalability. But these are things that should be left to the professionals, which should absolutely learn about the core concepts of the software they‘re building and deploying. But that’s what they‘re (read: we’re) being paid for.

Can you elaborate what you mean by that?

This might be pedantic, but iirc email clients don‘t execute any javascript due to security concerns (at least that was the case when I worked in email marketing 7 or so years ago).

The javascript is basically only used for templating, defining reusable components and rendering the static HTML together with inline CSS which does make a lot of sense because writing „bulletproof“ email components that work on every client is a huge amount of work and you would generally like to keep the amount doing that to a minimum.

In my experience every company uses some type of email templating system, some off the shelf, some built in-house, I actually got my start in (actual) programming by building one for my team.

Very nice! I feel like this is a perfect case of what PWAs are made for.

We also won multiple innovation awards for it, just in case you thought the advertising industry wasn‘t corrupt enough.

I remember when I used to work for a big advertising agency, we made a campaign that used „AI“ to find locations for rail travel within the country that looked like far away vacation spots (think a beach on bali, for example). The whole case for that campaign was that it was using AI to find these places, while in actuality we had a group of interns manually picking out the places and art directors touch up the pictures for the campaigns. We called it the „human API“.

Webflow has some huge constraints when you’re trying to actually build a good marketing page. Try framer instead, the fact that you can rely on React for anything that’s not possible to do in the visual editor is a life saver and actually enables you to build sites that are on-par with traditional headless CMS plus meta framework stacks while still being just as easy (if not easier) to maintain by non-technical users. The only problem is the price-tag which means you’ll be outpriced for small personal projects but it’s still a good deal for startups and bigger companies.