Modern front-end development: skinny jeans and handlebar mustaches ITT

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »

huhu: Feb 24, 2006

Lumpy posted:

Has anyone used launchdarkly for A/B testing, feature gating, etc. If so, any thoughts and opinions?

I've used it at two companies. Loved it both times.

# ? Dec 8, 2023 02:57

Adbot: ADBOT LOVES YOU

# ? Jun 3, 2024 09:56

gbut: Mar 28, 2008; 😤I put the UN🇺🇳 in 🎊FUN🎉

Same. I liked it, and I think it�s great when used as designed.

# ? Dec 8, 2023 03:52

uncle blog: Nov 18, 2012

A custom React hook always calls another hook (like useState, useEffect, etc)? And otherwise it's just a function?

# ? Dec 12, 2023 09:03

hey mom its 420: May 12, 2007

uncle blog posted:

A custom React hook always calls another hook (like useState, useEffect, etc)? And otherwise it's just a function?

yup

# ? Dec 12, 2023 09:13

uncle blog: Nov 18, 2012

Cool. Is there somewhere this is explicitly stated? https://react.dev/learn/reusing-logic-with-custom-hooks is a bit vague on the topic.

# ? Dec 12, 2023 09:27

prom candy: Dec 16, 2005; Only I may dance

They don't have to, you can make a custom hook that doesn't use other hooks if you really want to. There's just no reason to do that.

# ? Dec 12, 2023 16:55

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

uncle blog posted:

A custom React hook always calls another hook (like useState, useEffect, etc)? And otherwise it's just a function?

As prom candy said, that is not true.

What makes a hook a hook is that it starts with "use".

# ? Dec 12, 2023 21:17

hey mom its 420: May 12, 2007

Hmm OK, can you show me an example of a hook that doesn't use any of React's hooks?

# ? Dec 13, 2023 08:19

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

hey mom its 420 posted:

Hmm OK, can you show me an example of a hook that doesn't use any of React's hooks?

click on any of the ones here: https://usehooks.com/

# ? Dec 13, 2023 08:48

Full Circle: Feb 20, 2008

teen phone cutie posted:

click on any of the ones here: https://usehooks.com/

Those pretty much all use react hooks https://github.com/uidotdev/usehooks/blob/main/index.js

# ? Dec 13, 2023 15:43

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

hey mom its 420 posted:

Hmm OK, can you show me an example of a hook that doesn't use any of React's hooks?

I would, because a junior developer wrote one like a year ago in our app, but when I came across it, I converted it into a plain old function export and told them why they shouldn't have made it a hook.

# ? Dec 13, 2023 15:53

abraham linksys: Sep 6, 2010

Lumpy posted:

As prom candy said, that is not true.

What makes a hook a hook is that it starts with "use".

this is hilariously pedantic but i'll bite

the following things are all true:

* A hook, by convention, starts with `use`
* React itself does not treat functions that start with `use` in any special way*; they're just functions. If you define `const useHelloWorld = () => 'hello world'` and call `useHelloWorld()` inside your React component, that's not a hook, that's just a function starting with `use`
* What makes a function a hook is that it's either a built-in hook or a custom hook that wraps a built-in hook.

the closest thing you'll find to a definition of a hook in react's docs is that they are functions that allow functional components access to react's features (state, context, lifecycle, suspense, etc)

_{_{* i have not kept up with react 18/suspense so apologies if this has changed lol}}

Lumpy posted:

I would, because a junior developer wrote one like a year ago in our app, but when I came across it, I converted it into a plain old function export and told them why they shouldn't have made it a hook.

this is a function! your junior developer just wrote a function and prefixed with `use` inaccurately, it is not a hook lol

# ? Dec 13, 2023 16:10

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

abraham linksys posted:

this is hilariously pedantic but i'll bite

the following things are all true:

* A hook, by convention, starts with `use`
* React itself does not treat functions that start with `use` in any special way*; they're just functions. If you define `const useHelloWorld = () => 'hello world'` and call `useHelloWorld()` inside your React component, that's not a hook, that's just a function starting with `use`
* What makes a function a hook is that it's either a built-in hook or a custom hook that wraps a built-in hook.

the closest thing you'll find to a definition of a hook in react's docs is that they are functions that allow functional components access to react's features (state, context, lifecycle, suspense, etc)

_{_{* i have not kept up with react 18/suspense so apologies if this has changed lol}}

this is a function! your junior developer just wrote a function and prefixed with `use` inaccurately, it is not a hook lol

It is completely pedantic, which I was attempting to point out, but I guess failed to do so appropriately.

The React Docs posted:

Hook names must start with use followed by a capital letter, like useState (built-in) or useOnlineStatus (custom, like earlier on the page). Hooks may return arbitrary values.
This convention guarantees that you can always look at a component and know where its state, Effects, and other React features might �hide�. For example, if you see a getColor() function call inside your component, you can be sure that it can�t possibly contain React state inside because its name doesn�t start with use. However, a function call like useOnlineStatus() will most likely contain calls to other Hooks inside!

Note the bolded part. Hooks do not have to contain calls to other hooks to "be hooks". I can't think of any reason you'd ever do that, but you could. If you do this:

JavaScript code:

// useDonges.ts
export const useDonges = () => {
  const lol = 'lmfao';
  return lol;
};

// app.tsx
export function App() {
  let cow = 'bell';
  if (Math.random() < 0.5) {
    cow = useDonges();
  }
  return <div>{cow}</div>;
}

You get the React Hook "useDonges" is called conditionally. React Hooks must be called in the exact same order in every component render warning. So pedantic or not, it's treated like a hook because of the name.

# ? Dec 13, 2023 17:04

fsif: Jul 18, 2003

Happy to discover I'm not the only freak that uses `lol` and `lmao` in place of `foo` and `bar`.

# ? Dec 13, 2023 17:39

prom candy: Dec 16, 2005; Only I may dance

hey mom its 420 posted:

Hmm OK, can you show me an example of a hook that doesn't use any of React's hooks?

code:

function useDumbHook() {
  return "There is no reason to do this but it is technically still a hook."
}

# ? Dec 13, 2023 18:00

Ima Computer: Oct 28, 2007; Stop all the downloading!

Help computer.

The react-hooks eslint plugin does a naive check for the function's name because it's a lot more reasonable than actually checking the implementation of the body of the function, not because any function named "use" is a hook.

The class of errors that lint rule is intended to guard against only occurs when using react's builtin hooks. If your function doesn't use hooks, nothing will break if you conditionally call it or change the order in which its called within a render function.

What determines if a function a hook is whether or not it "hooks into" the React rendering lifecycle - and the only way to do that is with React's builtin hooks (or I guess a class component)

If you're naming a function "use____" and it's not calling any hooks, then you're misrepresenting what that function does and are going to create confusion for anyone who tries to consume it.

Ima Computer fucked around with this message at 18:14 on Dec 13, 2023

# ? Dec 13, 2023 18:11

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Ima Computer posted:

The react-hooks eslint plugin does a naive check for the function's name because it's a lot more reasonable than actually checking the implementation of the body of the function, not because any function named "use" is a hook.

The class of errors that lint rule is intended to guard against only occurs when using react's builtin hooks. If your function doesn't use hooks, nothing will break if you conditionally call it or change the order in which its called within a render function.

What determines if a function a hook is whether or not it "hooks into" the React rendering lifecycle - and the only way to do that is with React's builtin hooks (or I guess a class component)

If you're naming a function "use____" and it's not calling any hooks, then you're misrepresenting what that function does and are going to create confusion for anyone who tries to consume it.

I agree with this 100%. "What is a hook" is simply a convention, and that is silly, but it is what it is.

# ? Dec 13, 2023 18:24

HaB: Jan 5, 2001; What are the odds?

fsif posted:

Happy to discover I'm not the only freak that uses `lol` and `lmao` in place of `foo` and `bar`.

I use derp, herp, flerp and nerp;

code:

const derp = herp('nerp');
flerp('yoooooo');

# ? Dec 13, 2023 18:37

prom candy: Dec 16, 2005; Only I may dance

Ima Computer posted:

If you're naming a function "use____" and it's not calling any hooks, then you're misrepresenting what that function does and are going to create confusion for anyone who tries to consume it.

100%

# ? Dec 13, 2023 19:46

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Vue 3 for my project and here's basically App.vue surely this is not the best way to load a session into the store before rendering.

code:

const userStore = useUserStore();
const isLoaded = ref<boolean>(false);

async function load () {
  const res = await api('/user');
  if (res.user) userStore.$patch(res.user);
  isLoaded.value = true;
}
load();

code:

<template>
  <PageHeader v-if="isLoaded" />
  <RouterView v-if="isLoaded" />
</template>

# ? Dec 14, 2023 20:14

HaB: Jan 5, 2001; What are the odds?

Nolgthorn posted:

Vue 3 for my project and here's basically App.vue surely this is not the best way to load a session into the store before rendering.
code:
const userStore = useUserStore();
const isLoaded = ref<boolean>(false);

async function load () {
  const res = await api('/user');
  if (res.user) userStore.$patch(res.user);
  isLoaded.value = true;
}
load();

I would make load() a function of the userStore itself, but even if you don�t, call it in a lifecycle hook like onBeforeMount

code:

const userStore = useUserStore();
const isLoaded = ref<boolean>(false);

onBeforeMount( async() => {
  isLoaded.value = await userStore.load();
});

# ? Dec 15, 2023 09:59

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

Full Circle posted:

Those pretty much all use react hooks https://github.com/uidotdev/usehooks/blob/main/index.js

oh dam i did not read that post correctly

# ? Dec 15, 2023 18:29

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

HaB posted:

I would make load() a function of the userStore itself, but even if you don�t, call it in a lifecycle hook like onBeforeMount

Ok.

Using onBeforeMount is a good idea. I am making use of the router's beforeEach hook, unfortunately the beforeEach hook is running before the onBeforeMount finishes, so even though the session is loaded the user is already redirected to the login page.

TypeScript code:

onBeforeMount(async () => {
    const res = await api('/user');
    if (res.user) userStore.$patch(res.user);
    isLoaded.value = true;
});

code:

<template>
    <PageHeader :isLoaded="isLoaded" />
    <RouterView v-if="isLoaded" />
</template>

TypeScript code:

router.beforeEach((to) => {
    if (to.meta.requiresAuth && !isLoggedIn()) {
        return { path: '/login', query: { redirect: to.fullPath } };
    }
});

Nolgthorn fucked around with this message at 06:12 on Dec 18, 2023

# ? Dec 18, 2023 06:07

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

It seems beforeResolve was the hook I'm looking for.

TypeScript code:

router.beforeResolve(async (to) => {
    const userStore = useUserStore();

    if (userStore.state !== USER_STATE.READY) {
        await userStore.$fetch();
    }

    if (userStore.id) {
        if (to.name === 'home') return '/messages';
    } else if (to.meta.requiresAuth !== false) {
        return { path: '/login', query: { redirect: to.fullPath } };
    }
});

# ? Dec 18, 2023 18:44

Chas McGill: Oct 29, 2010; loves Fat Philippe

Trying out solidjs for a small project. People bitch about React all the time, but I'm finding solid fiddlier from a typescript perspective, particularly around conditional rendering.

Here's a snippet where some stuff is rendered if a signal called lesson is defined:

code:

      
const [lesson, setLesson] = createSignal<LessonModel>()

<Show when={lesson()}>
        {(lessonState) => ( // lessonState is the value returned by lesson(). If I were to try and just use lesson(), TS doesn't have a way of knowing that the result is defined, even though the condition has already been checked.
          <div class="lesson-container">
           // All the stuff that uses lessonState to render
          </div>
        )}
      </Show>

In the <Show> I use the value lessonState that is the result of calling the lesson() signal accessor, which TS knows is defined. But what if I wanted to make the condition more complex? Like lesson() && someOtherCondition. If I try and do that, the value returned is just a boolean, since that's what it would be. I could create a variable like const lessonState = lesson() in the block and check it there, but it feels redundant given that it's already been checked.

There's also the annoyance of not being able to destructure reactive props in components without an extra plugin. Currently not really seeing the benefits over ol' React, though maybe it's more apparent from a performance perspective. For small projects I'm much more inclined to value ease of use. I thought about using Svelte for this as well, but I'm a weirdo who actually likes JSX.

e: I just realised I misread the docs and I don't need to use their <Show> component - a simple condition should work, although I'd still have the same problem of needing to evaluate the result of the signal.

Chas McGill fucked around with this message at 18:55 on Dec 18, 2023

# ? Dec 18, 2023 18:48

Oysters Autobio: Mar 13, 2017

What are peoples thoughts on HTMX? Getting flooded on it from the algo, but as someone without frontend experience and wants to avoid JS or JS frameworks, I really like some of the concepts around HATEOAS, hypermedia and declarative use of HTML/CSS.

I'm primarily a python guy doing data analysis who secretly loves UI and front end, but everytime I start looking at the front-end JS spaghetti world I get this feeling in the pit of my stomach where I just want to crawl back into the dirt simple python world.

Other than job/career dev (ie learning popular frameworks), is there any other aspects of the whole HTMX thing that make folks who do this professionally cringe or thinking "it's a bad idea op"?

It just seems like there's a ton of deadass simple use cases where bootstrap, HTMX and flask would make a solid choice on a stack but I also am worried about creating future debt that a real frontend dev would have to maintain.

# ? Dec 19, 2023 13:37

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

My impression of htmx is that it's a sort of jQuery competitor that forces you to learn a million different html attributes instead of letting you write the code that you really need yourself.

It feels like something trendy to me. I don't really appreciate it or understand it. I thought web components would take off more than they did. Since web components didn't take off I'm pretty suspicious htmx definitely won't.

# ? Dec 19, 2023 13:58

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Oysters Autobio posted:

What are peoples thoughts on HTMX? Getting flooded on it from the algo, but as someone without frontend experience and wants to avoid JS or JS frameworks, I really like some of the concepts around HATEOAS, hypermedia and declarative use of HTML/CSS.

I'm primarily a python guy doing data analysis who secretly loves UI and front end, but everytime I start looking at the front-end JS spaghetti world I get this feeling in the pit of my stomach where I just want to crawl back into the dirt simple python world.

Other than job/career dev (ie learning popular frameworks), is there any other aspects of the whole HTMX thing that make folks who do this professionally cringe or thinking "it's a bad idea op"?

It just seems like there's a ton of deadass simple use cases where bootstrap, HTMX and flask would make a solid choice on a stack but I also am worried about creating future debt that a real frontend dev would have to maintain.

htmx, like most web technologies, sounds like something i could come up with as a joke in a bar. ( i have designed components for software products used by millions of users as a joke in a bar.)

this also might be a boomer take but i wouldn't pick a library that doesn't have a wikipedia page as something i'd design a product around for work. i'm sure it's fine if you're just playing around though, people can get almost anything to work on the front end.

# ? Dec 19, 2023 16:49

kedo: Nov 27, 2007

HTMX feels like CSS utility classes in that they both seem like they were designed by people who have a paralyzing fear of doing anything outside of markup.

Me? Open up a javascript file? When building a WEBSITE? No thank you.

# ? Dec 19, 2023 18:00

Haystack: Jan 23, 2005

HTMX seems fine for document-driven sorts of webpages that need some light UI elements,. However, it doesn't do any of the heavy state management and reactivity that modern javascript frameworks offer and will probably get in the way if you end up needing that down the line.

That being said, gently caress learning modern javascript frameworks. I had to scratch-build a drop-in shopping cart as a Vue application, and holy gently caress is was that a lot of goddamn layers to learn and evaluate and configure. Just to bitch a bit, I had to:

Setup a new IDE with nodejs and whatnot , guessing the correct language features to target along the way. gently caress you, node, I hate you. Commonjs can go burn in hell.
Get Vite set up and configured. This was after I tried Parcel first and found out that it was so opinionated as to be useless. Vite was decent, comparatively. A lot, mind you, but genuinely decent.
Learn and setup Typescript. Technically optional, but Typescript is nice! Fairly easy to learn, integrates with Vite nicely, makes me code less stupid, and makes my IDE smarter. Thumbs up.
Learn all of the new vanilla javascript paradigms that have cropped up since the jQuery era. loving async, man. Why the hell isn't await a top level keyword? Stop poisoning my functions. I hate it. It beats callback hell, I guess.
Learn Vue (and associated libraries) and actually code the app. Actually fairly pleasant, compared to the above. It took me longer than I'd care to admit to figure out how get a value out of a ref in the same scope.

Once you get going it's fine, but whoo boy is that a steep learning curve.

# ? Dec 19, 2023 18:15

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

Modern front-end development is a staggering amount of footguns and self-owns that could've been avoided if js devs hadn't rejected the entirety of existing software engineering practices as "too bloated" (ironic considering the bloated mess it has become, of course)

# ? Dec 19, 2023 18:25

lunar detritus: May 6, 2009

Haystack posted:

HTMX seems fine for document-driven sorts of webpages that need some light UI elements,. However, it doesn't do any of the heavy state management and reactivity that modern javascript frameworks offer and will probably get in the way if you end up needing that down the line.

That being said, gently caress learning modern javascript frameworks. I had to scratch-build a drop-in shopping cart as a Vue application, and holy gently caress is was that a lot of goddamn layers to learn and evaluate and configure. Just to bitch a bit, I had to:

Setup a new IDE with nodejs and whatnot , guessing the correct language features to target along the way. gently caress you, node, I hate you. Commonjs can go burn in hell.

Get Vite set up and configured. This was after I tried Parcel first and found out that it was so opinionated as to be useless. Vite was decent, comparatively. A lot, mind you, but genuinely decent.

Learn and setup Typescript. Technically optional, but Typescript is nice! Fairly easy to learn, integrates with Vite nicely, makes me code less stupid, and makes my IDE smarter. Thumbs up.

Learn all of the new vanilla javascript paradigms that have cropped up since the jQuery era. loving async, man. Why the hell isn't await a top level keyword? Stop poisoning my functions. I hate it. It beats callback hell, I guess.

Learn Vue (and associated libraries) and actually code the app. Actually fairly pleasant, compared to the above. It took me longer than I'd care to admit to figure out how get a value out of a ref in the same scope.

Once you get going it's fine, but whoo boy is that a steep learning curve.

I mean, once you do the first four steps you're ready for any modern framework.

# ? Dec 19, 2023 18:29

Ima Computer: Oct 28, 2007; Stop all the downloading!

Help computer.

I haven't used it for anything yet, but I really like HTMX. It reminds me of Tailwind, except that instead of colocating styles with your markup templates, it colocates your JS code with your markup templates. Colocation gives you dead code elimination for free, and saves you from the cognitive burden of cross-referencing markup templates and their associated JS glue code.

I could see it being used to build sites that are heavily backend-driven, with limited amounts of interactivity and/or complex state management. Basically, any time when a fully-fledged frontend framework would feel like overkill. Like for building internal tooling / reporting / dashboard-y things.

Oysters Autobio posted:

It just seems like there's a ton of deadass simple use cases where bootstrap, HTMX and flask would make a solid choice on a stack but I also am worried about creating future debt that a real frontend dev would have to maintain.

If your use cases are truly simple, then I honestly wouldn't worry about creating technical debt. You won't be able to create a significant-enough mess if you're building simple features.

Just don't use bootstrap - use Tailwind with DaisyUI instead :ssh:

# ? Dec 19, 2023 20:22

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

We use HTMX in our Django app and it's really great. Because we have a lot of forms which need really simple interactivity like "Only show this form field if this other radio button is selected", and to handle that in Django you need to either:
- write some jQuery: ewww, because (a) jQuery, and (b) now that code has to live in the HTML template instead of the where the form is defined in Python.
- convert the whole form to React: smashing the walnut with a sledgehammer.
- use HTMX: pretty easy, just add a couple of custom CSS attrs and you're away.

# ? Dec 19, 2023 23:09

Oysters Autobio: Mar 13, 2017

kedo posted:

Me? Open up a javascript file? When building a WEBSITE? No thank you.

Unironically yes. This is the sole reason I'm interested in HTMX.

I do python and mainly data analysis / data science stuff, there is zero reason for me to touch javascript and I'd rather continue improving my python before jumping over to learn a new language. At the same time though, I actually really love front-end design and UX design, but there's no UI frameworks in Python that seem popular enough to use or get into, whereas HTMX has some sort of following (for now...).

I know once I start going deeper into front end stuff that eventually I'll be forced to move over to a JS framework, but it's not my current or immediate career interests so 🤷‍♀️.

Most importantly (and always open for alternatives here) is the entire front end ecosystem is just so goddamn terrifying for an idiot like me who learned to code by copy-pasting python. Every one of my attempts to get into front end dev has faced me with this:

Haystack posted:

That being said, gently caress learning modern javascript frameworks. I had to scratch-build a drop-in shopping cart as a Vue application, and holy gently caress is was that a lot of goddamn layers to learn and evaluate and configure. Just to bitch a bit, I had to:

Setup a new IDE with nodejs and whatnot , guessing the correct language features to target along the way. gently caress you, node, I hate you. Commonjs can go burn in hell.

Get Vite set up and configured. This was after I tried Parcel first and found out that it was so opinionated as to be useless. Vite was decent, comparatively. A lot, mind you, but genuinely decent.

Learn and setup Typescript. Technically optional, but Typescript is nice! Fairly easy to learn, integrates with Vite nicely, makes me code less stupid, and makes my IDE smarter. Thumbs up.

Learn all of the new vanilla javascript paradigms that have cropped up since the jQuery era. loving async, man. Why the hell isn't await a top level keyword? Stop poisoning my functions. I hate it. It beats callback hell, I guess.

Learn Vue (and associated libraries) and actually code the app. Actually fairly pleasant, compared to the above. It took me longer than I'd care to admit to figure out how get a value out of a ref in the same scope.

Sorry, gently caress this. Absolutely no. All of this build system poo poo and webpacks and everythinge else that has been slapped together for front-end is just terrifying to me. Absolute respect for folks who do this for a living, honestly, its impressive, but I'm just too stupid for this. If my workplace was all Gitpod'd and VM'd up with decent infra that set this all up for me, sure, but there's just way too many choices and footguns. I have an arts-degree for gently caress sakes 😭.

Ima Computer posted:

Just don't use bootstrap - use Tailwind with DaisyUI instead

I was comparing bootstrap and tailwind+daisyUI but my understanding is that the latter is more of a framework to let you build your own components, while bootstrap already just has a bunch of default components ready to use just by throwing it into your HTML more or less. I don't want to reinvent the wheel, I'd rather use components and widgets designed by much smarter people than ever create my own.

edit: okay I definitely did not read enough into DaisyUI, as it does in fact appear to be a component library. Scratch what I said above, thanks for flagging will definitely check it out.

Haystack posted:

HTMX seems fine for document-driven sorts of webpages that need some light UI elements,. However, it doesn't do any of the heavy state management and reactivity that modern javascript frameworks offer and will probably get in the way if you end up needing that down the line.

Yup absolutely. I'm a data analyst, and I'm looking at it as a way to slap a front-end CRUD on to some legacy SQL databases and existing REST APIs. I don't have real any state management other than a boolean column in a table labelled "iswhatever". Any state I need to manage is in the database like god intended.

Oysters Autobio fucked around with this message at 23:17 on Dec 20, 2023

# ? Dec 20, 2023 13:16

Combat Pretzel: Jun 23, 2004; No, seriously... what kurds?!

So signals in React via @preact/signals-react, that good?

Can we expect this kind of stuff to land in React proper eventually? Whenever they actually do another release (lol)?

# ? Dec 20, 2023 14:29

HaB: Jan 5, 2001; What are the odds?

Oysters Autobio posted:

Sorry, gently caress this. Absolutely no. All of this build system poo poo and webpacks and everythinge else that has been slapped together for front-end is just terrifying to me. Absolute respect for folks who do this for a living, honestly, its impressive, but I'm just too stupid for this. If my workplace was all Gitpod'd and VM'd up with decent infra that set this all up for me, sure, but there's just way too many choices and footguns. I have an arts-degree for gently caress sakes 😭.

I get that, but that is stuff you do once a project and never touch again. Plus with Vite, 95% of that poo poo is done for you, you just pick options on the menu.

code:

yarn create vite my-vue-app --template vue

and there you go, a base vue project with everything setup - a dev server, a script to build for production.

Don't get me wrong, I have been working in primarily frontend for a over a decade now, and Modern Javascript Development is still pretty poo poo, but it is nowhere near as bad as it was, particularly with regard to "too many choices and footguns". Still plenty of rope to hang yourself, but I wouldn't say it has any more pitfalls than any other language - python included.

The node ecosystem is a lot less Wild West-y as it used to be, and as long as you stick to things with an actual track record / developer community, you will be fine.

Hadn't heard of HTMX until this very discussion, so I took a look. Ew. Not for me. But hey - it if looks like your jam, go for it. I'm just saying, Javascript is no longer the nightmare it is still purported to be.

# ? Dec 20, 2023 14:39

kedo: Nov 27, 2007

Oysters Autobio posted:

Unironically yes. This is the sole reason I'm interested in HTMX.

I do python and mainly data analysis / data science stuff, there is zero reason for me to touch javascript and I'd rather continue improving my python before jumping over to learn a new language. At the same time though, I actually really love front-end design and UX design, but there's no UI frameworks in Python that seem popular enough to use or get into, whereas HTMX has some sort of following (for now...).

I know once I start going deeper into front end stuff that eventually I'll be forced to move over to a JS framework, but it's not my current or immediate career interests so 🤷‍♀️.

See, I totally understand this perspective because I am also not always terribly interested in picking up a brand new language/framework for a one-off project, but Javascript is foundational to the web these days.

To me HTMX feels a lot like someone said, "I'm a construction worker but I only know how to use hammers. I use hammers to hit things, and I don't want to have to learn how to saw things, or drill things, or glue things, so I made this hammer that can saw and drill and glue. It doesn't do any of them well, and it was a convoluted process to make it and actually required that I shoehorn a saw and drill and glue bottle onto my hammer, but at least now I can (poorly!) saw and drill and glue things by simply whacking them with my hammer!"

If you're being inexorably drawn towards front-end dev (escape now!), you don't have to go the full npm/framework route to start. In fact you shouldn't. This is still a perfectly acceptable way to build a simple site:

code:

/project-dir
  index.html
  styles.css
  main.js

# ? Dec 20, 2023 16:20

Oysters Autobio: Mar 13, 2017

kedo posted:

See, I totally understand this perspective because I am also not always terribly interested in picking up a brand new language/framework for a one-off project, but Javascript is foundational to the web these days.

To me HTMX feels a lot like someone said, "I'm a construction worker but I only know how to use hammers. I use hammers to hit things, and I don't want to have to learn how to saw things, or drill things, or glue things, so I made this hammer that can saw and drill and glue. It doesn't do any of them well, and it was a convoluted process to make it and actually required that I shoehorn a saw and drill and glue bottle onto my hammer, but at least now I can (poorly!) saw and drill and glue things by simply whacking them with my hammer!"

If you're being inexorably drawn towards front-end dev (escape now!), you don't have to go the full npm/framework route to start. In fact you shouldn't. This is still a perfectly acceptable way to build a simple site:
code:
/project-dir
  index.html
  styles.css
  main.js

Eh, I think HTMX is more like "I'm not a construction worker looking to make a commercial build, I just want to build a shed that has functionality but I want to be able to just use simple 4x4s, hammer and nails because I don't need pneumatic drills, lifts, electrical, plumbing etc. that a professional construction worker would need to consider."

As much as I "like" front-end dev, thats just an interest but not one I am interested in making a career out of. To create my own internal app or something shouldn't require all these build packs and setups and clunky frameworks, just let me write the logic in a language I know (python) and template out the UI.

I know JS is foundational to the web, but HTMX' popularity (even if temporary) probably still shows that there's a market for non-pros that want to dabble in front end work but dont want to learn JS. Other domains seem to really give flexibility and "bring your own tools" except for front end development, but I might be conflating how flexible other domains truly are.

Oysters Autobio fucked around with this message at 23:29 on Dec 20, 2023

# ? Dec 20, 2023 23:25

Adbot: ADBOT LOVES YOU

# ? Jun 3, 2024 09:56

huhu: Feb 24, 2006

I've got a video stored in IndexedDB, split into Blobs. If I pull the video out all at once and merge the blobs together, and play it, everything works fine.

If I pull out the video blob by blob, I can play the first blob but none of the other blobs play.

I feel like I'm not quite sure the correct question to ask here but my hunch is that there's something to do with the blob's header data only existing on the first blob but not the other blobs. Is that correct?

# ? Dec 21, 2023 01:11

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »