Javascript questions which don't deserve their own thread.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

fsif: Jul 18, 2003

roomforthetuna posted:

but I don't really see any firm reason to not use a table for layout.

There are tons of reasons. With flexbox and grid, it�s easier to re-order elements, it�s easier to program responsive sizes, your markup is more semantically correct, and there�s far less boilerplate in your template files.

# ¿ Mar 10, 2021 05:02

Adbot: ADBOT LOVES YOU

# ¿ May 10, 2024 21:37

fsif: Jul 18, 2003

roomforthetuna posted:

Edit: an actual reason to use new CSS poo poo though, is that if you do that people will think you're good at this stuff, whereas if you use a table for the exact same outcome, people will think you're a grognard dinosaur.

Listen, I hate to be so blunt, but you don�t fundamentally understand the flexbox and grid specs and you don�t appear to have much experience in the way of developing a contemporary web layout.

Tables are a horrible tool for responsive layouts. The columns don�t wrap. If you�re dead set on using tables for a responsive design, you literally need to make a new table�complete with duplicate content�for any new configuration of columns. Even in the pre-flexbox days, developers moved past tables and hacked things together with utility libraries like bootstrap and used floats and clearfixes.

A table is semantically incorrect for layouts because it signifies tabular data. The markup of a grid and a table look nothing alike. You can almost certainly make whatever layout you�ve devised via a table in flexbox.

Items being re-ordered on a different device size happens on every site/app of moderate size I�ve developed for at least the past five years.

Much smarter minds than either of us have spent years creating these specs for the express purpose of addressing the shortcomings of the old specs. The idea that you�ve outsmarted them with a seven cell table is absurd on its face (and, again, incorrect).

Listen to your designers.

# ¿ Mar 10, 2021 07:52

fsif: Jul 18, 2003

I'd probably also question the necessity of a mobile version in the first place. That doesn't look like the type of form I'd ever sit in bed and lazily complete.

If your client insists that there's some use case where they're maybe out in the field and need to complete the form on a phone, I'd maybe see if it was feasible to have a condensed version with fewer fields that could be completed later on a desktop. Can't imagine completing a form with 200 fields on my phone.

# ¿ Mar 10, 2021 15:59

fsif: Jul 18, 2003

Guess I have to ask: why are you structuring the video clips this way? At first blush, that sounds like a recipe for disaster.

You'd be forcing the user to load a larger video than they need and building out a complicated, bespoke scrubber/video player that will need to accept a set of sort of non-standard parameters.

# ¿ Mar 16, 2021 19:16

fsif: Jul 18, 2003

SurgicalOntologist posted:

Because generating literally thousands of clips in the backend (most of them overlapping, some nearly identical) is expensive and takes a long time.

We transcode our videos to a chunked streaming format which allows us to avoid loading the whole video (although it might try to load the rest of the video, it doesn't load the earlier part). Anways all the clips are from the same longer video so once that's loaded I would hope it's cached for any clips, although I don't know the low-level details.

We're only at the POC stage and it seems to work pretty well, minus the scrubber thing. I think it solves more problems than it creates, but we'll be able to validate that soon enough.

Gotcha. Yeah, obviously you know your project better than I do so take what I say with whatever appropriate amount of salt.

BUT I'd just caution that the solution of "rolling your own" scrubber might not be that easy. There's no native way to do it with Vime as far as I can tell. If your team is comfortable ditching Vime and want to use a low-level <video> tag to program it, there are still a lot of responsive and accessibility hurdles you'll want to make sure to clear. Also don't know if your chunking solution is in some ways dependent on Vime.

Should also note that in my (not particularly robust, but still existent!) experience with trying to pause a longer video at a certain spot to bring about an artificial end, the native JavaScript events weren't that precise. The clip would stop within a 1+ second range.

So you know, totally unsolicited and underinformed opinion here, but in the abstract a project like this could end up being one where you end up spending more developers and technical debt than you do just running the servers, heh.

# ¿ Mar 16, 2021 21:13

fsif: Jul 18, 2003

TengenNewsEditor posted:

Am I looking at this all wrong?

Yeah I think so. Django and React aren't really that comparable of frameworks/libraries and they set out to solve different problems. My sense is that if you'd prefer to work on the view layer in Python, you're probably not the type of developer that React would appeal to.

The issue with props drilling/lifting up state is a commonly identified pain point. If a React app has some appreciable level of complexity, developers usually install a state management library like Redux or zustand.

# ¿ Apr 5, 2021 15:06

fsif: Jul 18, 2003

TengenNewsEditor posted:

I don't want to use django since this app shouldn't require an ORM. My point is if I need to use a state manager or normalize/flatten my state application wide, am I even getting any benefit from using React over a heavy ORM framework anymore?

I assume so? You're getting all of the normal benefits of React and something like zustand or the aforementioned native Context API take about thirty minutes to learn and are much lighter weight than an ORM framework. They will give you a global state object, which is what I think you're looking for.

# ¿ Apr 5, 2021 15:58

fsif: Jul 18, 2003

TengenNewsEditor posted:

React seems like it ought to work best as a View only framework

That's�out of the box�all React has purported to be. It's narrow in scope and extendable by design. If you don't like cobbling together third party libraries for things like state management, routing, or server side rendering, you can either choose a more fleshed out React starter pack like Next.js, or choose a different, more opinionated JavaScript framework like Vue.

# ¿ Apr 5, 2021 18:32

fsif: Jul 18, 2003

Yeah and I still use axios. Just used to it.

# ¿ Apr 7, 2021 18:27

fsif: Jul 18, 2003

Very particular question here, but might as well take a stab at it: has anyone here attempted to implement page transitions in Next.js by using GreenSock?

Best I can tell people generally use Framer Motion over GreenSock here (being that the former is declarative), but I already have gsap installed as a dependency for a canvas-based API and I�m trying to assess the feasibility of foregoing adding a second 30+ KB gzipped animation library.

# ¿ Jun 13, 2021 04:01

fsif: Jul 18, 2003

Ytlaya posted:

There's something a coworker did that I think is unnecessary, but I want to double-check that I'm not going crazy here (since these coworkers are generally more competent than me at most programming tasks, but I'm starting to wonder if they might lack some really basic javascript/html stuff).

Basically the guy in question put some controls for a feature inside of a form element, but the form element does nothing and is never submitted (and as far as I can tell never will be). All functionality is just controlled by the JS and the only submission is an AJAX request (whose parameters are also just pulled from the html using JS). Putting stuff inside of a form that is never being submitted doesn't make sense, right?

I believe you'd want to keep the form element there for semantic/screen reader reasons.

# ¿ Oct 7, 2021 12:42

fsif: Jul 18, 2003

Ape Fist posted:

I have no loving idea what Vite is but the blurb on the site looks like some 'Im pretending to be solve a problem I created' just like graphQL

...

I hate to be that loving guy but as time goes by I increasingly just think 'I don't like Angular' means 'I don't understand it',

Hmm.

# ¿ Feb 19, 2022 01:42

fsif: Jul 18, 2003

Not trying to hate, I get the allure of knowing what you know and then never having learn new stuff again.

But aren't you guys ever worried about, like, losing your jobs? And then becoming unemployable? I would never consider hiring a dev in 2022 that wasn't ES6 fluent.

Is there just enough legacy Angular work out there to last?

# ¿ Feb 21, 2022 01:08

fsif: Jul 18, 2003

Bruegels Fuckbooks posted:

If I need to learn a framework to do a job or work on a new project, I'll do it, and I'll learn that poo poo better than the people who actually like the framework and advocate for it,

Considering your last post suggested that code bases needed to be rewritten when React hooks were released, I'm skeptical.

I had to collaborate with a developer at another company on a project about six months ago who I suspect would echo the same sentiments the last several folks on this page have. He needed to use React for the first time and he ended up being less productive than our junior developer, even as we purposely steered him towards projects he felt like he'd be better equipped to handle. Plus, you know, his code ended up being a complete mess and I had to spend an hour or so everyday helping him troubleshoot.

For all this hand wringing about silly coding noobs chasing "the new hotness," the tech mentioned in the last series of posts (React, ES6, flexbox) has been dominant and/or standard for the better part of a decade now.

# ¿ Feb 21, 2022 13:30

fsif: Jul 18, 2003

Osmosisch posted:

Modern Javascript is pretty good.

That said, I would heartily recommend using Typescript from the get-go if at all possible, since its typing lets you avoid a lot of really irritating pitfalls caused by Javascript's loose typing and enables automated refactoring.

Disagree about the Typescript from the get go. I'm not sure the benefits of TS really outweigh its added complexity unless until someone already has a pretty good handle on JavaScript. Plus, if they're learning JS in order to interact with already existing automation software, they're probably not going to be able to put much of that TS knowledge to use anyway.

# ¿ Oct 19, 2022 03:36

fsif: Jul 18, 2003

That wasn't intended as an anti-TypeScript comment (though I do think it's overprescribed by its evangelists) but more a suggestion for someone new to JavaScript. It's hard enough to learn JS; piling on a bunch of TS tooling and type errors and conventions right at the onset of learning, especially to interact with a non-TypeScript tool, feels unnecessarily arduous.

# ¿ Oct 19, 2022 20:13

fsif: Jul 18, 2003

Recently collaborated with a developer that used no semicolons. It was fine. Code readability is exactly the same.

# ¿ Nov 23, 2022 14:06

fsif: Jul 18, 2003

Bruegels Fuckbooks posted:

semicolonless javascript is fine except when it's not. the problem is there are edge cases and they suck - like https://stackoverflow.com/questions/2846283/what-are-the-rules-for-javascripts-automatic-semicolon-insertion-asi. i don't want to have to learn these rules when people can just put the loving semicolons where they ought to go.

This never came up and we have a linter that formats on save anyway.

MrMoo posted:

It�s not when you see a line with a semicolon at the start, it�s like �you typoed here bud.�

I don't know what this sentence means.

# ¿ Nov 23, 2022 16:27

fsif: Jul 18, 2003

go play outside Skyler posted:

Might not be a popular opinion but as someone who's done a lot of everything web, a lot of embedded, a lot of Java, Kotlin and Swift, I'll say this: in 2022 it doesn't really matter if you barely know how HTML and CSS work anymore.

I'm curious about your rationale here because this strikes me as a baffling take. Are you only talking about creating private apps that look like garbage and don't care about accessibility?

# ¿ Dec 30, 2022 13:51

fsif: Jul 18, 2003

Yeah that can work for a hobby project or maybe an internal company tool (which tbf I assume the OP is building) but it won't get you too far past that.

# ¿ Dec 30, 2022 15:49

fsif: Jul 18, 2003

Jabor posted:

It's actually the opposite - the larger the project, the more you need to know the component library being used, and the less you need to care about minutiae of HTML and CSS.

Once you get large teams of people all working on the same project, you literally have to componentize - if you want to be at all productive, you can't have people loving around with CSS and inadvertently changing parts that aren't the thing they're directly working on. Once you have a componentized UI, only the developers actually creating the components need to care about HTML and CSS - everyone else can use the components as-is and can put all their effort into caring about how those components are composed together and wired up to the data you're wanting to display in them.

That's just� absolutely not correct. Even enterprise companies with coherently developed design systems (of which there aren't many!) can't rely on a set of several dozen components that are never updated and only ever used in extremely prescribed patterns. You're going to reach edge cases, new business logic, updated brand guidelines, entirely new UI, etc that will dictate that you will, at some point, need to create or edit new HTML or CSS.

And I don't even know how you'd begin to understand the nuances of said component library without a strong foundation in HTML/CSS in the first place!

# ¿ Dec 30, 2022 16:28

fsif: Jul 18, 2003

Jabor posted:

I am literally talking from experience here.

Yes, someone needs to understand HTML and CSS to write and update the component libraries. It does not need to be you, the developer doing a higher-level task like adding a "track package" button to gmail or putting the view count widget next to the other counters in the twitter UI.

If your literal experience has you still talking about floats then I have to assume said literal experience is fairly limited and/or completely out of date.

I can promise you the developer tasked with deploying template changes to Gmail knows HTML and CSS.

fsif fucked around with this message at 17:15 on Dec 30, 2022

# ¿ Dec 30, 2022 17:13

fsif: Jul 18, 2003

Zustand has kind of become the de facto standard over context, I think.

# ¿ Jan 28, 2023 14:23

fsif: Jul 18, 2003

I can't speak for your colleague's concerns in particular, but a lot of the work I do in my day-to-day are short-term web projects/experiences that don't need to be maintained by large teams of developers over many years. For these projects, I'm not certain that the extra time spent writing types and debugging type errors is always offset by the time saved by seeing errors in your IDE or better IntelliSense. I can't sell these clients on their project having even one fewer feature in exchange for a tidier codebase.

On top of that, a lot of the projects I work on, too, can on short-notice have a number of different developers with different experience levels hopping on. It's not only a barrier for intern and junior level developers; a number of the great creative tech folks I work with (think WebGL developers) outright refuse to use it because of how it messes with their workflows.

# ¿ Jan 18, 2024 04:07

fsif: Jul 18, 2003

Okay so as the resident TypeScript hater* (I enjoy using it, I just don't think it's right for every project), one thing I have noticed recently-ish is something of a shift in tone from several prominent TS evangelists.

Here's Theo lecturing developers that they're only feeling unproductive with TS because they're using it wrong. It should never block the build step! Except it should on main, the most important build step. Simply create your own CI/CD pipeline configuration that treats preview and production branches differently. And also, feel free to just kind of ignore all the red squigglies until the end, then I guess you have to go back and address them then? And don't put the type in separate files, just kind of start using `as` to make things simpler (but don't use `any`).
https://www.youtube.com/watch?v=Xl02L1jy53c

And then here's Scott Tolinski and Wes Bos saying they ship with type errors and it's NBD, they'll go back and fix them later?
https://www.tiktok.com/embed/7304021566386343210

Seems like we're kind of reaching a point where developers are talking about how in real world practice, they're finding ways to modify their workflows to start selectively ignoring TypeScript.

# ¿ Jan 18, 2024 18:09

fsif: Jul 18, 2003

Harriet Carker posted:

Thanks for all the great advice everyone. I'm feeling some hardcore imposter syndrome with this guy because he seems like he knows what he's talking about but I don't quite understand, and I'm a little worried about pushing back and being totally off-base.

We have a standard React app with a webpack bundler. I mentioned we could slowly introduce TS into new components without having to touch the old ones until we want to/have time, but he says introducing TS is all-or-nothing because:

Can anyone help me maybe understand what he means? I've never run into this issue and I'm super unclear, but I don't feel confident enough to engage in the discussion.

My best professional advice is that if the person is more senior than you are and you're not feeling comfortable enough to refute their arguments without asking for help on the Internet, you're probably best off just following their lead.

# ¿ Jan 18, 2024 18:23

fsif: Jul 18, 2003

fuf posted:

Is this kind of thing normal or have I gone completely insane?

Probably closer to the "completely insane" side of that spectrum.

Why do you want to do all of your state management via routing? From my vantage point, it seems like a comically clunky way to do what you're trying to do.

# ¿ Feb 8, 2024 15:14

Adbot: ADBOT LOVES YOU

# ¿ May 10, 2024 21:37

fsif: Jul 18, 2003

fuf posted:

I dunno I just kept reading loads of stuff about how the thing to do in NextJS is put the state in the URL!

The last build of the app (React and zustand, then React and preact signals) had a lot of state stuff that was like currentCategoryId, currentCardId, currentFilter, etc. etc. and it seemed like this would be a good alternative to that.

The other thing the old app did was retrieve all the cards from the db on page load and then just store them in state as a massive array. Maybe this is fine but it didn't feel great. With the NextJS version I wanted to see if I could just store the currently selected card IDs in client state (using something like zustand because I know I can't do this bit with the url) and then get the rest of the card data from the DB only when required.

I guess I don't understand why the ergonomics of storing all of your state via routing is preferable over just using zustand.

I've never personally heard of anyone suggesting they use Next.js's routes as a replacement for a more conventional state management tool. The theoretical advantage of it would be, I guess, being able to share your instance of an app via a URL? But I'd still prefer using query params. Just doesn't seem like you'd want to leverage routing unless you really want to make distinct pages; doesn't make sense to me to use it to track the state of a game/app.

# ¿ Feb 9, 2024 00:06

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.