I think it's a joking dig, saying that dynamic (interpreted) languages are stupid while compiled languages are not. `im_stupid()` is not defined, so there should be a compilation error. If it first prints the output of `print` before giving an error about `im_stupid` not being defined, it's a dynamic language, and (according to the author) that's stupid.
I agree with all of the points, except the last. Protobuf is a nice transfer format but it's horrible once a human wants to inspect or copy/paste a payload.
Exactly. And this is an extremely important detail. It makes your development process go from using glass tubes where you see everything as it is sent/received to black boxes of binary data.
JSON is self describing, you can mostly just call the API, read the JSON response and figure it out from there.
Ignoring that detail is ignoring the elephant in the room.
100%. The topic is to post side projects making $500/month. Not to post failed side projects, projects that generate little to no money, or that cost money.
> they only started to look nice when React moved to Hooks and functional components
Is this a widely held opinion? Call me crazy, but I really liked class components. It was nice to see the lifecycle stages in the actual method names, and encapsulate the behavior inside of a method block. To me that was really nice to read.
With hooks, everything is inside a function without clear delineation. The lifecycle stages are put anywhere in there with (to me) strange looking calls to useEffect and such.
Before, I used to love whipping up a quick UI in React, but since hooks I loathe doing that. I really don't want to upgrade my existing apps to newer versions. And for potential future project I'm looking for an alternative.
Perhaps I don't like it so much because I'm primarily a back and systems engineer, and only do small frontends on the side.
Hooks are awful. They’re a faux-functional interface, accessing implicit local state, with so much magic going on behind the scenes that it’s obscene. At least in class component days it was obvious which components were stateful. Now you’ve got to remember which magic hook incantation is causing your “functional” component to improperly cache state and why. I cannot for the life of me see it as an improvement in any way other than “it looks nicer,” which aligns with the top-level parent’s point.
Anyway I think react in general is kind of terrible. I’ve worked at three places whereFE teams made a react codebase that wound up being so scary and difficult to work in that essentially no one would touch it, until it eventually got rewritten. Two of those just rewrote it in react again, hoping that whatever faddish state library would save them from themselves. At the third, they rewrote it in svelte, which went much better. At least for me as someone who only writes FE code when I have to, svelte is much more comprehensible and sensible.
Zero power draw is still less than a little power draw. A couple million of these babies running on idle is a considerable amount of power. Please, turn off devices when you're not using them.
Any modern computer system uses a lot of power for a few minutes after bootup. If you use the machine a few times per day you're wasting energy (and your own time) by turning it off instead of using sleep mode.
Completely agree! We just 3D printed a base switch that makes it easy to turn your Mini on and off. Here's a link: https://m4button.com/ (if you have a 3D printer, you don't need this).
I played for a few minutes but then I couldn't pick up anything because I could only carry 6 items. After a few cycles of "let's see what I can drop to pick up the new thing" I just stopped playing, because that is not a fun loop to me.
I dislike TypeScript, and I feel it's mostly fake. There are plenty of ways to accidentally bypass the "type system" and do stuff that should be illegal in a statically typed language but work because there's JavaScript underneath. I feel TypeScript adds extra cognitive load that isn't necessary and isn't really adding much value. JavaScript is simple, easy, and works well. I wish more people would invest in learning to write better JavaScript, than to have the flaky facade on top of it.
Then again, I'm not a front-end dev, I just do hobby projects with JS.
If you are mostly writing JS to enhance a web page, I would say it is good enough.
I recently to wrote an application that interfaces with a non-trivial Json API which returns many different data types.
I defined all the interfaces produced by the API in TS, and once this was done the app practically wrote itself with hardly any surprises.
With the data structures documented, the logic is concise and readable. To me, this is "better Javascript".
Of course, if the API changes, randomly all the types are a lie... it would be nice if I could reuse the types to do some runtime validation of fetch results, pydantic-style.
TS is fake in the sense that so many developers believe it to be more powerful than it actually is. If you use `any` at any point then you have virtually no guarantees. It also only helps partially when you don't validate data during runtime. Unfortunately, I've seen many developers write code as if no checks are needed during runtime because of Typescript, yet their application receives data structures from the outside.
I don't get why to use an ORM in the first place. Just define a bunch of structs, run a query, map results to structs. It's a few lines of simple code. You're in control of everything (the SQL, the running, the mapping). It's transparent. With any ORM, you give away control and make everything more complex, only to make it slightly easier to run a query and map some results.
Op is never implying they intend to maintain one to one correspondence between the DB and objects and do that through manipulating objects only. Mapping hand written queries results to structs and updating the DB yourself on the basis of what is in structs is not at all an ORM.
No, absolutely not. You don’t even try to manipulate the DB using object-oriented concept in this case. That’s just a good old I/O layer used on a need to basis. This is not in any way an ORM by any sane definition of what an ORM is.
Not in most modern web application servers. ORMs seem to solve the problem of synchronizing some persistent application state (like a desktop GUI app) to your database state, but web application servers are usually relatively stateless. It's better to think of the application's job as taking a request, parsing it, compiling it to SQL, handing that to a database, and serializing the results.
Through that lens, the parts where you load and save object state are redundant. You're going to throw those objects away after the request anyway. Just take your request and build an UPDATE, etc. Use record types merely as a way to define your schema.
No type safety & writing manual SQL is slower. I get your point but the bottleneck is often developement speed, not query efficiency. I know and hate how stupid the ORM is underneath but I have to admit it's a blessing that I dont have to think about SQL at all (until I do).
I think the whole problem is just terminology. For example take your comment. You start talking about unit tests and units, but then suddenly we're talking about components. Are they synonymous to units? Are they a higher level, or a lower level concept?
People have such varying ideas about what "unit" means. For some it's a function, for others it's a class, for others yet it's a package or module. So talking about "unit" and "unit test" without specifying your own definition of "unit" is pointless, because there will only be misunderstandings.
reply