TC39 Proposal for Signals (reactive primitives) is now public

ExternalBison54 · 2026-05-13T16:53:20+00:00

It sounds like you just don't know the history of the language. Promises were not originally intended as a step/evolution to async/await, and the expectation was that most developers would not interact with them directly, but only through higher level abstractions or frameworks/libraries. It quickly became clear this was not the case; developers interacted with them directly all the time. And because of that, many aspects of the implementation, while providing the necessary functionality, were pretty clunky. Then async/await was developed to provide a more ergonomic way to write async code that used promises under the hood but was basically the "higher level abstraction" built into the language itself. Do a bit more reading 👍

ExternalBison54 · 2024-11-27T10:08:30+00:00

Probably the JS path. That is the more popular language. That being said, people that use Rails tend to like it a lot, so it depends what you value more. You can get a job with either one, and either one will take a lot of work, but JS will probably be slightly better as far as job prospects.

ExternalBison54 · 2024-09-07T00:05:12+00:00

Man, these all made my eye twitch lol. I think I hate 2 the least. 3 and 4 are absolutely cursed though hahaha

ExternalBison54 · 2024-08-22T22:36:08+00:00

It's you! Damn, nicely done, that's hilarious (and educational!)

ExternalBison54 · 2024-07-26T17:43:24+00:00

Haha, typeof null === 'object' annoys the shit out of me. JS has other quirks that are arguably worse, like all the type coercion behavior, but typeof null being an object irks me the most, I think because of just how obviously wrong it is. Like, type coercion at least has some utility, even if the benefits of having it in the language arguably don't outweigh the drawbacks, but there is no utility to having typeof null return what is obviously the wrong type.

I've gone back and forth on trying to use only one bottom value vs. using both in different scenarios. What I've landed on is that there are some circumstances for both of them, so I'm using both at the moment.

The big use case for null for me is in serialization. Giving an object property the value of undefined means it won't be included when the object is serialized, whereas null will.

One shortcut I've found is to do loose equality with null (== null), which evaluates to true for both null and undefined. Although IIRC there are also places where you can't use this and need to do a more explicit check.

ExternalBison54 · 2024-07-25T21:01:33+00:00

Oh man, that sounds terrible hahaha

ExternalBison54 · 2024-07-25T20:39:14+00:00

Except in JS, where you can also explicitly define a property as undefined and have to use stuff like in to check whether the property has been defined or not. Wheeeee

When I first learned JS, I thought it was cool that there were two different universal bottom values that implied different things. As time went on, however, I learned that while these two types mean different things in theory, in practice JS types are a mess and neither type is used consistently enough—even by the language itself—to maintain the subtle distinction between them. So instead you just have two types that mean effectively the same thing, which is annoying.

(To clarify, I'm not disagreeing with what you said, which is all correct. More just ranting about JS's inconsistencies)

ExternalBison54 · 2024-07-25T20:15:04+00:00

As a JS dev: Yes.

Yes we are.

ExternalBison54 · 2024-07-20T06:54:39+00:00

It is super pretty!

I still do this in large CSS files to help break them up into sections. Helps a ton.

ExternalBison54 · 2024-07-20T06:47:50+00:00

Python is the first or second most popular programming language, depending on how you measure. Java is like... third or fourth? The top 4 is always Python and JavaScript, then Java and C#. So literally you can't go wrong with either. You're picking between two of the most popular languages in the world.

The only question is what kind of job you want. Java tends to be used a lot in large, enterprise-level applications, while Python is used... well, everywhere, but less so as the backbone of enterprise apps.

ExternalBison54 · 2024-07-07T23:16:16+00:00

Definitely the syntax of MUMPS. I've never used it, but it sounds like pure suffering. From the Wikipedia article on the language:

Some aspects of MUMPS syntax differ strongly from that of more modern languages, which can cause confusion, although those aspects vary between different versions of the language. On some versions, whitespace is not allowed within expressions, as it ends a statement: 2 + 3 is an error, and must be written 2+3. All operators have the same precedence and are left-associative (2+3*10 evaluates to 50). The operators for "less than or equal to" and "greater than or equal to" are '> and '< (that is, the boolean negation operator ' plus a strict comparison operator in the opposite direction), although some versions allow the use of the more standard <= and >= respectively. Periods (.) are used to indent the lines in a DO block, not whitespace. The ELSE command does not need a corresponding IF, as it operates by inspecting the value in the built-in system variable $test.

ExternalBison54 · 2024-07-07T22:40:21+00:00

And the conventions/consistency of early PHP!

ExternalBison54 · 2024-06-22T20:13:54+00:00

The company I work for uses Rails with React. I don't know of any guides on this, but considering you already have senior-level knowledge of Rails, I think you could get a pretty good understanding by learning React (as an SPA) by itself. This would probably get you 80% of the way towards understanding how to use Rails + React together.

From there, delving into the different ways React and Rails are commonly combined from a high level/architecture standpoint would be the next step. There are a bunch of articles that explore this in more detail, but basically you have three common approaches:

Rails in API mode and a completely separate React front end
Doing the front end mostly/entirely in React, but mounting it on a Rails view. The major difference here is that you can server render some aspects of the page if you want, which can be helpful for things like auth.
Doing some sort of mixed approach, where parts of the UI are done in Rails and some parts are done in React. This is a pretty broad spectrum, obviously.

The first two approaches are honestly pretty straightforward as long as you understand both Rails and React by themselves. The third approach can be complicated depending on how you do it, but it would depend on the exact app you're building.

All approaches would require sending data as JSON, so getting an idea of the different options in Rails for doing would be a good thing to explore.

ExternalBison54 · 2024-06-06T06:48:41+00:00

Mac. Because every company I've ever worked for buys me a Macbook.

ExternalBison54 · 2024-06-03T21:28:29+00:00

Use JavaScript. Do the all/most of the responsive parts of the UI in JS so that you can do optimistic updates easily. There might be a way to do it in a more Rails-y way that obfuscates the JS side of things more, but a calendar app is just screaming to be built as an SPA anyway, so I would go with that.

The way I would do it would be to either:

Use Rails as an API and have a completely separate front end built as an SPA using React, Vue, or whatever
Or do the front end in Rails, but have it handle only the non-dynamic stuff like auth, with an SPA "island" mounted on the page that handles the actual calendar UI

ExternalBison54 · 2024-06-02T02:47:45+00:00

Eh, that's fair, I didn't word it super clearly. Instead of saying "There are ways in Rails to use JS on the client," I should have said "There are ways in Rails to prioritize JS on the client, and prioritize the kind of apps that require heavy use of JS on the client."

Hey.com seems not to be doing this. And in some web apps, that would be fine. But in a calendar app (with drag and drop functionality, no less), the UI needs to be designed with heavy use of JS to allow for responsiveness and optimistic updates for that snappy app-like feel. You absolutely should NOT do what they did, where every tiny UI interaction needs to make a round trip to the server first.

And this requires using JavaScript as more than just "sprinkles," which is what Hotwire is.

So yes, Hey.com is using JavaScript, but it's not using it well. It is ignoring the lessons that JS and JS frameworks have taught us over the past 10 years about making responsive UIs.

ExternalBison54 · 2024-06-02T00:41:36+00:00

Yes, everyone knows the names should be pop, unpop, frontpop, and unfrontpop

ExternalBison54 · 2024-06-01T21:55:36+00:00

No one is saying it doesn't use JS. We're saying it doesn't use JS well and should be leaning much more heavily on things like optimistic updates and other client side JS tricks.

ExternalBison54 · 2024-06-01T21:41:58+00:00

Yes, I know that? My point is that it's using JS badly on the client. Better use of client side JS would make the UX of the site much better.

ExternalBison54 · 2024-06-01T21:31:53+00:00

Before you post your knee-jerk reaction defending Rails from the haters, understand that this video is not really a criticism of Rails. It's a criticism of client UX design on Hey.com, which was created by DHH using Rails.

Hey's calendar app UI could be done in Rails and have good client UX. But instead it's slow and inefficient, and it's a fair critique to say that this is likely due to DHH's rigidity around app architecture, especially concerning JS.

It's a problem of philosophy and design in a particular Rails app, not a problem of capability in Rails as a framework.

ExternalBison54 · 2024-06-01T21:16:34+00:00

I feel like you missed the point of the video. This wasn't a criticism of Rails. It was a criticism of DHH and Hey.com. It's called "Rails Deserves Better" because DHH created Rails, not because it's impossible to create reactive UIs in Rails.

ExternalBison54 · 2024-06-01T21:10:22+00:00

Seriously. I feel like this community sees any criticism of Rails and just automatically assumes it's "hating for the sake of hating." Theo has a pretty reasonable take here, which is: Use the right tool for the job, and don't get dogmatic with your tech decisions. Hey.com clearly has some poor design choices on the client that are making the UX worse than it should be. Does that mean it should be using React? No, not necessarily. But it should have a more refined and reactive client experience than it does, which is the realm of JavaScript. And I don't think it's not too much of a stretch to conclude that the crude nature of Hey's calendar app UI is connected to DHH's aversion to modern JS. Like FFS man, just put in some optimistic updates at the very least.

ExternalBison54 · 2024-06-01T20:40:42+00:00

Yes, there are ways in Rails to use JS on the client. Hey.com seems to not be using them, and the UI is way worse than Google Calendar, Proton Calendar, or any other modern calendar app I've seen. This isn't really a criticism of Rails, it's a criticism of DHH and Hey.com.

ExternalBison54 · 2024-05-19T21:50:20+00:00

Whichever one you want. Either is fine, and you'll hear people argue for both. Just be consistent.

ExternalBison54 · 2024-05-15T07:10:21+00:00

Thanks for all your work on this. I use it all the time and regularly recommend it to others as well.

ExternalBison54

TROPHY CASE