Andy Maleh

I can repeat it. It's basically like... It's a very interesting book that I highly recommend reading to anyone working in the software development industry. But they're basically saying that one risk that... people get into is becoming both frogs.

I can repeat it. It's basically like... It's a very interesting book that I highly recommend reading to anyone working in the software development industry. But they're basically saying that one risk that... people get into is becoming both frogs.

What they mean is like they say, if you take a frog and put it in a pot with boiling water, the frog will jump out right away of the pot as a reaction, as a like a way of like, yeah, as a reactive, basically reactive behavior. It'll jump right away just to protect its life.

What they mean is like they say, if you take a frog and put it in a pot with boiling water, the frog will jump out right away of the pot as a reaction, as a like a way of like, yeah, as a reactive, basically reactive behavior. It'll jump right away just to protect its life.

Uh, but if you put a frog in a pot with water that is cold, and then you raise the heat, uh, very gradually, like you turn on, uh, you turn on the heat and then you raise it very, very gradually. You can boil the frog without it knowing, uh, uh, because it'll boil very, very gradually. So it will not know that it is boiling, but eventually it will boil.

Uh, but if you put a frog in a pot with water that is cold, and then you raise the heat, uh, very gradually, like you turn on, uh, you turn on the heat and then you raise it very, very gradually. You can boil the frog without it knowing, uh, uh, because it'll boil very, very gradually. So it will not know that it is boiling, but eventually it will boil.

So they mentioned that a lot of developers end up in that situation where they use technologies at work that put a drag on their productivity and they get used to them. And getting used to things is like one of the biggest risks in adopting bad practices in software engineering. So people might like use JavaScript, which has very contradictory paradigms to Ruby, with a Rails application,

So they mentioned that a lot of developers end up in that situation where they use technologies at work that put a drag on their productivity and they get used to them. And getting used to things is like one of the biggest risks in adopting bad practices in software engineering. So people might like use JavaScript, which has very contradictory paradigms to Ruby, with a Rails application,

for years and think they're doing the best they could but in fact they're actually not doing the best they could uh they're creating it like a drag on productivity because they have multiple languages that have different paradigms and they're also in their head their context switching between the two languages all the time so i personally noticed like i pay a lot of attention because of reading that story in the pragmatic programmer book and at first i fell for that trap too i used javascript for many years thinking it was the best thing

for years and think they're doing the best they could but in fact they're actually not doing the best they could uh they're creating it like a drag on productivity because they have multiple languages that have different paradigms and they're also in their head their context switching between the two languages all the time so i personally noticed like i pay a lot of attention because of reading that story in the pragmatic programmer book and at first i fell for that trap too i used javascript for many years thinking it was the best thing

But eventually I realized, like I mentioned, I use Glimmer for building desktop apps a lot. I'm like, that's not even like JavaScript development is not even close to that. And so basically a lot of people are boiled frogs in a way. They're not realizing how much productivity they're losing. In my experience, I would like, I think Glimmer DSL for web would cut down the work in half

But eventually I realized, like I mentioned, I use Glimmer for building desktop apps a lot. I'm like, that's not even like JavaScript development is not even close to that. And so basically a lot of people are boiled frogs in a way. They're not realizing how much productivity they're losing. In my experience, I would like, I think Glimmer DSL for web would cut down the work in half

in half in general. So like if you have 12 months of front end development work in JavaScript and React, you could do it in six months in Ruby and Glimmer DSL for web. So that's part of the reason why I'm actually using it with Rails, not against, it's not like I still use Rails for the backend,

in half in general. So like if you have 12 months of front end development work in JavaScript and React, you could do it in six months in Ruby and Glimmer DSL for web. So that's part of the reason why I'm actually using it with Rails, not against, it's not like I still use Rails for the backend,

But Glimmer is kind of like providing a drop-in replacement for your JavaScript libraries that you're adding to Rails. So if you're using Vue.js or Ember or Svelte or Angular or React, Glimmer can do a lot better than any of those, in my experience, as far as productivity. Assuming it has fast enough performance. For my work app, the web page with the most elements has only 1,200 elements.

But Glimmer is kind of like providing a drop-in replacement for your JavaScript libraries that you're adding to Rails. So if you're using Vue.js or Ember or Svelte or Angular or React, Glimmer can do a lot better than any of those, in my experience, as far as productivity. Assuming it has fast enough performance. For my work app, the web page with the most elements has only 1,200 elements.

And I discovered they render fast enough with Glimmer. I don't even need any of the performance advertisements of React or Svelte for that. Apple Ruby is fast enough in my experience.

And I discovered they render fast enough with Glimmer. I don't even need any of the performance advertisements of React or Svelte for that. Apple Ruby is fast enough in my experience.

In general, I think we can follow the 80-20 rule where we can avoid premature optimization because people tell you it's the root of all evil in software engineering because it makes people complicate their code unnecessarily. React code is unreadable compared to Ruby code or especially Rails backend code, for example. Why are we using it in a Rails app? That's contradictory. It

In general, I think we can follow the 80-20 rule where we can avoid premature optimization because people tell you it's the root of all evil in software engineering because it makes people complicate their code unnecessarily. React code is unreadable compared to Ruby code or especially Rails backend code, for example. Why are we using it in a Rails app? That's contradictory. It