|
libcxx posted:If you ever thought to yourself "I wish make was worse and depended on node-loving-js" then grunt is the tool for you.  Node is basically the easiest runtime of any language to get up and running with. There's no virtual environments or bundler to worry about.The problem with Grunt is that its declarative nature makes it a poor fit for creating complex build pipelines, and it totally lacks any kind of partial rebuild support (i.e. I have ten ES6 files that get compiled through Traceur and concatenated, I change one, all of them have to rebuild). Also the problem with Bower is that it's based on loving Git and after years of telling people "don't check in your built assets to Git" you now have to tell devs "okay check in your built assets to an orphaned build branch or another repo," which is a pain in the rear end compared to npm publish. There's apparently a slow-rear end rewrite of Bower happening to add a real registry, but really we just need to use NPM for browser packages because it literally already does everything you'd want it to do except let you install to a folder not called node_modules  Kobayashi posted:Ahh OK, I can see that. There's nothing discouraged about Require.js, except for the part where its documentation is unreadable. Just make sure to run it through the optimizer (probably via Grunt) before deploying. Please Use Modules. If you're writing more than one <script> tag in 2014, you're doing something wrong.
|
#
¿
Jan 22, 2014 15:22
|
|
|
|
| # ¿ Apr 29, 2024 18:00 |
|
|
Head Bee Guy posted:I'm also open to rethinking the stack. For reference, I have some familiarity with React and would like to stick with that, and the company will most likely be using Shopify logistics for shipping/returns etc. not to blow up what you've got so far, but shopify has their own react-based framework called hydrogen, might be worth taking a look: https://shopify.dev/docs/custom-storefronts/hydrogen they have been investing big in it over the last year or two and are doing a lot of cutting edge react-y things, but i have no experience with it myself so can't actually vouch for it. just always seemed like a neat thing if you're already invested in that world
|
|
#
¿
Sep 12, 2023 00:52
|
|
|
if you just want runtime type-safety with no ORM, you can hand-write zod schemas for the expected query results, and this brings up typescript to parity with, like, every other typed language where the types exist at runtime. there's some libraries that'll integrate this like slonik (https://github.com/gajus/slonik).MrMoo posted:Drizzle ORM is the main one that comes up in search results, although it’s a bit tedious that yet again another layer wants to be the single source of truth for domain models. if you're using an ORM like drizzle you probably don't need any extra runtime validation? it already has its own schema DSL that i assume would enforce stuff at runtime if you want actual end-to-end type safety when interacting with a database that is a huge can of worms in any language and can be a pit of a pain in the rear end to get set up (e.g. my java-heavy employer eventually gave up on JOOQ's DSL for being way too hard to work with and is still keeping on with JDBI). stuff like prisma exists but whoof that is some heavyweight stuff abraham linksys fucked around with this message at 19:07 on Mar 25, 2024 |
|
#
¿
Mar 25, 2024 19:04
|
|