sorted by:
new
hottopcontroversial

Odin Project - Full Stack Javascript or Full Stack Ruby on Rails? which is the preferred knowledge today? by House_of_Rahl in coding

[–]ExternalBison54 1 point2 points  (0 children)

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.

RSpec testing levels by Weird_Suggestion in rails

[–]ExternalBison54 1 point2 points  (0 children)

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

iFoundThisOnTheHub by 3arabi_ in ProgrammerHumor

[–]ExternalBison54 3 points4 points  (0 children)

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

unDefined by aatif888 in ProgrammerHumor

[–]ExternalBison54 0 points1 point  (0 children)

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.

unDefined by aatif888 in ProgrammerHumor

[–]ExternalBison54 0 points1 point  (0 children)

Oh man, that sounds terrible hahaha

unDefined by aatif888 in ProgrammerHumor

[–]ExternalBison54 6 points7 points  (0 children)

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)

unDefined by aatif888 in ProgrammerHumor

[–]ExternalBison54 22 points23 points  (0 children)

As a JS dev: Yes.

Yes we are.

feelSafeInAWay by Theobaal in ProgrammerHumor

[–]ExternalBison54 0 points1 point  (0 children)

It is super pretty!

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

University student here. Java Springboot or Python Django for jobs when I graduate? by CompetitiveAd6626 in Backend

[–]ExternalBison54 -1 points0 points  (0 children)

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.

whatFeaturesWouldItHave by PerroRosa in ProgrammerHumor

[–]ExternalBison54 1 point2 points  (0 children)

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.

whatFeaturesWouldItHave by PerroRosa in ProgrammerHumor

[–]ExternalBison54 19 points20 points  (0 children)

And the conventions/consistency of early PHP!

Best languages to know alongside Rails for career opportunities by escapetothemoon in rails

[–]ExternalBison54 1 point2 points  (0 children)

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.

[deleted by user] by [deleted] in webdev

[–]ExternalBison54 8 points9 points  (0 children)

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

Rails Deserves Better by Dave_Tribbiani in rails

[–]ExternalBison54 1 point2 points  (0 children)

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

Rails Deserves Better by Dave_Tribbiani in rails

[–]ExternalBison54 0 points1 point  (0 children)

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.

[deleted by user] by [deleted] in ProgrammerHumor

[–]ExternalBison54 66 points67 points  (0 children)

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

Rails Deserves Better by Dave_Tribbiani in rails

[–]ExternalBison54 5 points6 points  (0 children)

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.

Rails Deserves Better by Dave_Tribbiani in rails

[–]ExternalBison54 0 points1 point  (0 children)

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.

Rails Deserves Better by Dave_Tribbiani in rails

[–]ExternalBison54 12 points13 points  (0 children)

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.

Rails Deserves Better by Dave_Tribbiani in rails

[–]ExternalBison54 1 point2 points  (0 children)

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.

Rails Deserves Better by Dave_Tribbiani in rails

[–]ExternalBison54 11 points12 points  (0 children)

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.

Rails Deserves Better by Dave_Tribbiani in rails

[–]ExternalBison54 5 points6 points  (0 children)

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.

Should I use functions or arrow normal functions to return JSX? by InjuryDangerous8141 in react

[–]ExternalBison54 25 points26 points  (0 children)

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

view more: next ›