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

Cugel the Clever: Apr 5, 2009; I LOVE AMERICA AND CAPITALISM DESPITE BEING POOR AS FUCK. I WILL NEVER RETIRE BUT HERE'S ANOTHER 200$ FOR UKRAINE, SLAVA

Sulla-Marius 88 posted:

Does anybody have a good 'best practices' guide for npm security? i want to check out angular but i also remember the flatmap (flatstream?) fiasco a few months ago and i must suck at googling because i cant find a good, plain retrospective on how to offset npm's inherent security risks

Jake Archibald's most recent blog post addresses the topic, but it's focus is on catching issues and mitigating threats. Bottom line is that there's still way more risk than there are ways to adequately address it. https://jakearchibald.com/2018/when-packages-go-bad/

# ¿ Dec 21, 2018 14:43

Adbot: ADBOT LOVES YOU

# ¿ May 21, 2024 05:29

Cugel the Clever: Apr 5, 2009; I LOVE AMERICA AND CAPITALISM DESPITE BEING POOR AS FUCK. I WILL NEVER RETIRE BUT HERE'S ANOTHER 200$ FOR UKRAINE, SLAVA

If you don't want to roll your own styles, Bootstrap 4 is still a fantastic way to go assuming you don't mind your site looking bootstrappy to anyone in the know. They haven't removed their dependency on jQuery for their scripts, for whatever reason, but you can either leave the scripts out or accept the slightly larger payload.

# ¿ Feb 19, 2019 13:51

Cugel the Clever: Apr 5, 2009; I LOVE AMERICA AND CAPITALISM DESPITE BEING POOR AS FUCK. I WILL NEVER RETIRE BUT HERE'S ANOTHER 200$ FOR UKRAINE, SLAVA

Vincent Valentine posted:

Hey guys I just managed to forget how to open my Dev tools which I do hundreds of times a week to the point of it being pure muscle memory. Took about thirty seconds to get them open.

I forgot how to do this while on a screen share with my boss, bosses boss and the CTO.

Been there. Fortunately, I usually remember to fall back to either F12 or right-click + inspect element relatively quickly.

# ¿ Jan 28, 2020 07:12

Cugel the Clever: Apr 5, 2009; I LOVE AMERICA AND CAPITALISM DESPITE BEING POOR AS FUCK. I WILL NEVER RETIRE BUT HERE'S ANOTHER 200$ FOR UKRAINE, SLAVA

I've had the bad luck of working with designers that were print media focused throughout much of their careers with only a vague grasp that the web is a whole different beast. They've also mysteriously been unable to recognize the need to maintain consistency when iterating on an established foundation. Like, I couldn't put together a particularly compelling design for the life of me, but I can at least recognize that consistent patterns throughout the application reduce cognitive load for the user (and, as an added bonus, are typically faster to develop).

Small sample size, though, and each was open to well-meaning, constructive feedback. Just have to hope they find the time to explore what it means to design for the web a bit further.

# ¿ Feb 2, 2020 00:39

Cugel the Clever: Apr 5, 2009; I LOVE AMERICA AND CAPITALISM DESPITE BEING POOR AS FUCK. I WILL NEVER RETIRE BUT HERE'S ANOTHER 200$ FOR UKRAINE, SLAVA

Stupid question. I've seen a lot of talk about the benefits of dynamic loading, but the examples used are almost always route-based. Is this just because this is the most obvious initial implementation or are there costs that I'm not seeing to going more granular?

For example, I've got five weighty components that may or may not be present on the page at initial load. If I add a loading fallback and handle the error scenario in which they fail to load for any reason, is there anything else I should consider when deciding to make them dynamic imports?

# ¿ May 5, 2020 16:49

Cugel the Clever: Apr 5, 2009; I LOVE AMERICA AND CAPITALISM DESPITE BEING POOR AS FUCK. I WILL NEVER RETIRE BUT HERE'S ANOTHER 200$ FOR UKRAINE, SLAVA

Had a coworker who pronounced www "dubdubdub", which I and my other coworkers never heard before and, coming from any other source, might have enthusiastically adopted for the sake of brevity. Problem was, the guy was a giant rear end and got fired for being such (well, plus being an outright bad front-end dev) and permanently set me against it.

Also pronounced URL "Ural", which was mildly off-putting and my brain always first processed as the mountain range.

Gods, that guy. Only one I know who, on being gently told in an early performance review that he needed improvement, but that the team was there for him along the way, angrily doubled- and tripled-down saying he had years of experience and knew exactly what he was doing.

# ¿ May 8, 2020 14:50

Cugel the Clever: Apr 5, 2009; I LOVE AMERICA AND CAPITALISM DESPITE BEING POOR AS FUCK. I WILL NEVER RETIRE BUT HERE'S ANOTHER 200$ FOR UKRAINE, SLAVA

teen phone cutie posted:

i dunno if this is a hot take or not, but I hate typescript enums. They don't work with intellisense and they feel pointless:

You're expected to just use the enum directly. It's transpiled down to an object, in any case.

TypeScript code:

export enum DISPLAY {
  BOTTOM = "bottom",
}

const doThing = (display: DISPLAY) => {
  if (display === DISPLAY.BOTTOM) {
    // do thing
  }
};

But yeah, string literal types are more succinct and still have mass-rename functionality (at least in the latest TypeScript).

# ¿ Oct 16, 2021 03:07

Cugel the Clever: Apr 5, 2009; I LOVE AMERICA AND CAPITALISM DESPITE BEING POOR AS FUCK. I WILL NEVER RETIRE BUT HERE'S ANOTHER 200$ FOR UKRAINE, SLAVA

I've got a meddlesome problem that I'd love to solve with pure CSS to avoid the need for a janky JS implementation that would have to account for page resize, but a solution eludes me. Basically, I want an image to "fill" the height of a container that gets its height from the other items in it, plus have a specific aspect ratio (1:1; 3:2; etc.)

HTML code:

<div class="container">
  <div class="item item--image">
    <img class="image" src="imageUrl" />
  </div>
  <div class="item">
    <p>Blah</p>
  </div>
</div>

If we lived in a perfect world, I could just specify height: 100% on the .item--image and .image, discarding the image's inherent dimensions and everything would just work. Unfortunately, that doesn't seem to be the world we live in and the img will only accept a height override with an explicit unit value. The only exception I've found is if the .container is display: grid, where .item--image is set to height: 100% and .image set to height: 0 to prevent its inherent sizing and min-height: 100% to take up the container's height. Of course, this doesn't work correctly in at least Firefox, so quite possibly doesn't work in any of the other circumstances. The aspect ratio could be achieved with the new aspect ratio property, but that doesn't work with our browser requirements.

The padding top/bottom trick doesn't work as it defines the height by the width, which is the opposite of what I need.

Cugel the Clever fucked around with this message at 03:48 on Oct 17, 2021

# ¿ Oct 17, 2021 03:46

Cugel the Clever: Apr 5, 2009; I LOVE AMERICA AND CAPITALISM DESPITE BEING POOR AS FUCK. I WILL NEVER RETIRE BUT HERE'S ANOTHER 200$ FOR UKRAINE, SLAVA

So I've solved at least the "fill" part of the equation with flex, but it's non-viable as it's treated as having no width, despite visually appearing to, resulting in the other items in the container potentially overlapping the image div...

And it still doesn't work without aspect-ratio, regardless.

Glitch sandbox and screenshot, if anyone's interested in a brain teaser and loving wonky browser flex/grid behavior:

# ¿ Oct 17, 2021 17:51

Cugel the Clever: Apr 5, 2009; I LOVE AMERICA AND CAPITALISM DESPITE BEING POOR AS FUCK. I WILL NEVER RETIRE BUT HERE'S ANOTHER 200$ FOR UKRAINE, SLAVA

Marak Squires, developer of the popular Faker.js and Colors.js libraries, has apparently continued his downward spiral from allegedly setting his home on fire with possible bombmaking materials back in September to publishing breaking changes for both libraries with weird right-wing Aaron Schwartz conspiracy theories, cries of liberty, and American flags. GitHub and NPM have, understandably, banned him for this and removed the broken versions.

Dude's clearly got some significant mental health issues and is going through a lot right now, so I hope someone will be able to get him the help he needs. Unfortunately, there look to be at least a few folks on social media confusing the above for "evil corporations stepping all over the independent open source developers!!" and trumpeting him striking against the system. There are real discussions to be had about things like supporting open source projects or even the risks of tech giants monopolizing major dev tooling, but hooboy is this incident ever not a rallying cry for that.

JavaScript code:

module.exports = function americanFlag () {
  console.log('LIBERTY LIBERTY LIBERTY'.yellow);
  console.log('LIBERTY LIBERTY LIBERTY'.america);
  console.log('LIBERTY LIBERTY LIBERTY'.yellow);
  let flag = "\
  \
                                 !\
             H|H|H|H|H           H__________________________________\
             H|�|�|�|H           H|* * * * * *|---------------------|\
             H|�|&#8734;|�|H           H| * * * * * |---------------------|\
             H|�|�|�|H           H|* * * * * *|---------------------|\
             H|H|H|H|H           H| * * * * * |---------------------|\
             H|H|H|H|H           H|---------------------------------|\
          ===============        H|---------------------------------|\
            /| _   _ |\          H|---------------------------------|\
            (| O   O |)          H|---------------------------------|\
            /|   U   |\          H-----------------------------------\
             |  \=/  |           H\
              \_..._/            H\
              _|\I/|_            H\
      _______/\| H |/\_______    H\
     /       \ \   / /       \   H\
    |         \ | | /         |  H\
    |          ||o||          |  H\
    |    |     ||o||     |    |  H\
    |    |     ||o||     |    |  H   Carl Pilcher\
  ";

  console.log(flag);

}

I can't find the "homer backing into bushes" emoji right now, but pretend I added it here.

# ¿ Jan 10, 2022 06:18

Cugel the Clever: Apr 5, 2009; I LOVE AMERICA AND CAPITALISM DESPITE BEING POOR AS FUCK. I WILL NEVER RETIRE BUT HERE'S ANOTHER 200$ FOR UKRAINE, SLAVA

A rant:

I'm having a tough time getting a firm idea for how mobile Web Views work and the documentation for both iOS and Android seems piss poor (or expects broader familiarity with mobile development, which I'm awfully lacking in). Basically, I need validate that the rendering engine used by the Web View component on our supported OS versions has a specific modern JS primitive available—if not, have to do some janky poo poo with a third party library with equivalent functionality (but is not a 1:1 polyfill).

The understanding I've arrived at is that iOS Web View makes use of the device's version of Safari, which is pinned to the loving iOS release, for some reason. I guess it's the same on Safari for MacOS? We "officially" support Safari, but it has such low usage and we're so stretched thin we've never given it attention.

On Android, meanwhile, it looks like Android 4.4+ Web View uses Chromium/Chrome on Android, such that it will stay evergreen assuming the user hasn't manually toggled off updates (or installed something that supplants the system web view with FF or something). So theoretically we can impose the burden of keeping up to date just like we do for our web browser support (last X versions of all evergreen browsers).

Thing is, the above assessments aren't from any explicit documentation, just cleaned hodgepodge from miscellaneous, sometimes conflicting sources. I'll need to actually go in and validate the primitive is available before I have any degree of confidence.

# ¿ Jan 13, 2022 04:28

Cugel the Clever: Apr 5, 2009; I LOVE AMERICA AND CAPITALISM DESPITE BEING POOR AS FUCK. I WILL NEVER RETIRE BUT HERE'S ANOTHER 200$ FOR UKRAINE, SLAVA

I've now lost my entire morning attempting to get an iOS 14 simulator installed through xcode. Fucker just stalls out ~66% and nothing I do resolves it.

# ¿ Jan 13, 2022 21:51

Cugel the Clever: Apr 5, 2009; I LOVE AMERICA AND CAPITALISM DESPITE BEING POOR AS FUCK. I WILL NEVER RETIRE BUT HERE'S ANOTHER 200$ FOR UKRAINE, SLAVA

Thanks for the recs. Fifth attempt was the charm and, after being stalled for 30+ minutes at 66%, it finally started (slowly) moving. Maybe it would have done so the other times! Either way, it's utterly mind-boggling to me... is it expected that simulator install takes over an hour with no meaningful user feedback??? Why does the install max out my fans?? Android simulator installations take ten minutes, tops.

This, plus other arcane and poorly documented nonsense, has turned a task that should have taken at most a couple hours into a multiday epic of frustration that I'm still not 100% sure on. While I'm sure that mobile devs experience the same frustration of not knowing the little things that are essential for productive development when trying to get something done on the web, it doesn't make it any less excruciating.

Siguy posted:

Now doing the thing I�ve avoided for years: learning Webpack.

I wanted to experiment with compiling Rust to web assembly (so far a bit disappointing in file size), and getting the wasm file integrated into an old site of mine has been much harder than I expected.

First I tried using parcel because I�d heard it was zero configuration. It was awesome� except web assembly didn�t work.

So then I started working through the webpack getting started tutorial and good lord I feel like this is SO much more complicated than the NPM build scripts I used to use.

I�ve finally got it working but I�m a little stunned that this is the state of the art in build tools. It just feels so hostile and configuration heavy. Every single thing requires another package and four lines in four different places in the webpack.config.is file.

Yeah... Webpack has come a long, long way toward being accessible and taking care of simple things out of the box, but it's still hostile enough that competitors keep popping up.

# ¿ Jan 14, 2022 07:07

Cugel the Clever: Apr 5, 2009; I LOVE AMERICA AND CAPITALISM DESPITE BEING POOR AS FUCK. I WILL NEVER RETIRE BUT HERE'S ANOTHER 200$ FOR UKRAINE, SLAVA

fuf posted:

then typescript complains when I reference post.tags because the Post type created by Prisma doesn't have a "tags" property.

I've only just played around with it briefly, but Prisma should compose the type properly, resulting in post being the exact intersection you've described. What's your schema for the relationship?

# ¿ Mar 9, 2024 18:39

Adbot: ADBOT LOVES YOU

# ¿ May 21, 2024 05:29

Cugel the Clever: Apr 5, 2009; I LOVE AMERICA AND CAPITALISM DESPITE BEING POOR AS FUCK. I WILL NEVER RETIRE BUT HERE'S ANOTHER 200$ FOR UKRAINE, SLAVA

fuf posted:

After playing around a bit more, it looks like I can actually reference preset.tags in the same component as the prisma call, because like you say prisma is composing the right type based on what I've asked for. The issue comes when I try to pass the preset to a child component and reference its tags in there

Oh, I'd mistaken the question for being about the inferred type of the `post` reference not having the included tags prop, rather than properly typing the components they're being passed to. Yeah, I don't think you have an option other than manually creating these intersection types in a common spot if you want to consume them across your application, but I'd be curious if anyone that actually uses Prisma day-to-day has any tips and tricks.

# ¿ Mar 9, 2024 21:01

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