3 ms·

> Basetool is written in TypeScript and (in our opinion) with most modern pieces of tech out there; React, Redux toolkit, Next.js, Prisma, and tailwindcss. We w

> Basetool is written in TypeScript and (in our opinion) with most modern pieces of tech out there; React, Redux toolkit, Next.js, Prisma, and tailwindcss. We want this to be a project that lives on in the future. This always struck me as weird thinking. If you aim for sustainability and longevity, shouldn't you use technologies that have stood the test of time rather than the latest and shiniest pieces of tech?

neurotrace 5y ago
I have _serious_ doubts about the longevity of tailwind. It adds unnecessary tooling to recreate inline styles with theme support. I tried adding it to a project which used other technologies listed here and it was obnoxious to use. You end up with class name soup unless you combine all of the styles under a combined class. Once you do that, it's literally just normal CSS with extra steps
- adrianthedev 5y ago
  > Once you do that, it's literally just normal CSS with extra steps. Yeah, I agree. That's not the way to go. Components is the way to go. Regarding using tailwind in general, I had a few issues in the beginning, too, until I figured out how it's supposed to be used. It is a bit tough to use it with frameworks that don't allow you to create components in a more modular way. But if you get to create these components, it's really a joy. It reminds me a bit of the BEM methodology (just a bit). Again... it's also a matter of what each person is vibing with.
  - neurotrace 5y ago
    Components don't stop the soup though. It's a fundamental issue where you're just replacing inline styles with classes. But hey, you do you
dragonwriter 5y ago
> This always struck me as weird thinking. If you aim for sustainability and longevity, shouldn't you use technologies that have stood the test of time rather than the latest and shiniest pieces of tech? Because the fact that the things likely to last the longest into the future are the ones that have already lasted and not the newest, most-apparently-forward-looking is counterintuitive to many people. Or because they recognize that, but recognize that its also likely that something new will do even better than the things that are already old but that the hard part is picking the right new thing, and they think they have unique insight on the right new thing. Or because they realize they probably don't have unique insight, but gambling on new has the best payoff if you are right, whereas the upside of choosing COBOL because its still trucking since the 50s is...you have job security eternally working on a COBOL [0] code base. [0] And this generalized to all the metaphorical COBOLs out there in various domains, as well as actual literal COBOL.
- adrianthedev 5y ago
  I wrote a comment above addressing some of your thoughts. I'm not the one to say if what we choose will last in the future, but we really are not afraid that they will be gone in the near future. The technologies we picked are not the "hot new thing", and we just picked them up. If I can use your metaphor, I'm not sure we could have built this in COBOL. We chose the tools that we thought were best at this moment in time.
adrianthedev 5y ago
That's a good question. So, we come from Rails. We actually built Avo (https://avohq.io https://avohq.io), an admin gem for Rails, so we can say we have tried it that way. Avo was first a Rails-backed SPA (Rails server and Vue front-end), and it didn't work out that well. Unfortunately, the Rails community didn't take that lightly, and for a good reason. I won't go into too much bike-shedding here, but the most important reason is that you have to maintain two codebases (ruby & JS). In January, we re-wrote Avo with Hotwire (the JS front-end suite created for Rails), and it went very well. It's a joy to write apps using Rails and Hotwire. But the fact of the matter is that we need an app that's a bit more dynamic on the front-end than Hotwire can deliver. I mean, yes, we could weave together Hotwire and a few other JS libraries to get what we need, but we'd get the same two codebases and the same two sets of skills you need to run your app. The reason we chose to go with React is the ecosystem, mostly (*fun fact; I'm sitting here writing this wearing a VueJS hoodie). We're running Next.JS because, honestly, it's a beast when you're talking about React apps. TailwindCSS because of its popularity, and it vibes with us, and we move fast using it. Prisma because it really is a breath of fresh air when you consider the alternatives in the JS world. I left TS at the end because it's the most "well-known development secret" out there. It keeps your codebase in check and your team on the same page.

neurotrace 5y ago

I have _serious_ doubts about the longevity of tailwind. It adds unnecessary tooling to recreate inline styles with theme support. I tried adding it to a project which used other technologies listed here and it was obnoxious to use. You end up with class name soup unless you combine all of the styles under a combined class. Once you do that, it's literally just normal CSS with extra steps

adrianthedev 5y ago
> Once you do that, it's literally just normal CSS with extra steps. Yeah, I agree. That's not the way to go. Components is the way to go. Regarding using tailwind in general, I had a few issues in the beginning, too, until I figured out how it's supposed to be used. It is a bit tough to use it with frameworks that don't allow you to create components in a more modular way. But if you get to create these components, it's really a joy. It reminds me a bit of the BEM methodology (just a bit). Again... it's also a matter of what each person is vibing with.
- neurotrace 5y ago
  Components don't stop the soup though. It's a fundamental issue where you're just replacing inline styles with classes. But hey, you do you

dragonwriter 5y ago

> This always struck me as weird thinking. If you aim for sustainability and longevity, shouldn't you use technologies that have stood the test of time rather than the latest and shiniest pieces of tech? Because the fact that the things likely to last the longest into the future are the ones that have already lasted and not the newest, most-apparently-forward-looking is counterintuitive to many people. Or because they recognize that, but recognize that its also likely that something new will do even better than the things that are already old but that the hard part is picking the right new thing, and they think they have unique insight on the right new thing. Or because they realize they probably don't have unique insight, but gambling on new has the best payoff if you are right, whereas the upside of choosing COBOL because its still trucking since the 50s is...you have job security eternally working on a COBOL [0] code base. [0] And this generalized to all the metaphorical COBOLs out there in various domains, as well as actual literal COBOL.

adrianthedev 5y ago
I wrote a comment above addressing some of your thoughts. I'm not the one to say if what we choose will last in the future, but we really are not afraid that they will be gone in the near future. The technologies we picked are not the "hot new thing", and we just picked them up. If I can use your metaphor, I'm not sure we could have built this in COBOL. We chose the tools that we thought were best at this moment in time.

adrianthedev 5y ago

That's a good question. So, we come from Rails. We actually built Avo (https://avohq.io https://avohq.io), an admin gem for Rails, so we can say we have tried it that way. Avo was first a Rails-backed SPA (Rails server and Vue front-end), and it didn't work out that well. Unfortunately, the Rails community didn't take that lightly, and for a good reason. I won't go into too much bike-shedding here, but the most important reason is that you have to maintain two codebases (ruby & JS). In January, we re-wrote Avo with Hotwire (the JS front-end suite created for Rails), and it went very well. It's a joy to write apps using Rails and Hotwire. But the fact of the matter is that we need an app that's a bit more dynamic on the front-end than Hotwire can deliver. I mean, yes, we could weave together Hotwire and a few other JS libraries to get what we need, but we'd get the same two codebases and the same two sets of skills you need to run your app. The reason we chose to go with React is the ecosystem, mostly (*fun fact; I'm sitting here writing this wearing a VueJS hoodie). We're running Next.JS because, honestly, it's a beast when you're talking about React apps. TailwindCSS because of its popularity, and it vibes with us, and we move fast using it. Prisma because it really is a breath of fresh air when you consider the alternatives in the JS world. I left TS at the end because it's the most "well-known development secret" out there. It keeps your codebase in check and your team on the same page.