The Web Design & Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Web Design & Development Megathread

«‹›2 »

Roadie: Jun 30, 2013

In dumb web news, people on the Chrome team are pushing for sharp limits on page resources (2 MB per page in images, 500 kb per page in scripts), throttled limits on CPU usage in JS, or both, which to me seems like a great way to violently murder web games and to push users of business web apps to switch to Firefox to get out of a repeat of UAC hell.

# ¿ Feb 3, 2019 22:01

Adbot: ADBOT LOVES YOU

# ¿ May 17, 2024 16:58

Roadie: Jun 30, 2013

RobertKerans posted:

You talking about GDPR or something different? Cos if it's the former, wtf mate

Some websites are run by idiots who think that a TOS popup completely immunizes them to GDPR when GDPR specifically says you can't do that.

# ¿ Feb 4, 2019 00:14

Roadie: Jun 30, 2013

LifeLynx posted:

Does anyone have any articles - with data, preferably - on why all sites should have a Contact Us page? My sales guys are inexplicably resistant to the idea of a Contact Us page, and I think me pointing out that literally every site on the internet has one won't work.

Well, at a bare minimum, GDPR requires that sites that provides service to literally anyone in Europe at any time ever have a process to handle requests to delete personal data, under threat of fines that scale up to approximately "all of the money you will ever have in your entire life". Which is lower cost: building out a fully automated system to handle this, or just having a contact email somewhere and a boilerplate blurb about sending GDPR requests there?

# ¿ Feb 7, 2019 09:19

Roadie: Jun 30, 2013

Thermopyle posted:

I'm sure this is a solved problem, I just don't ever do the type of work I'm doing right now...

I'm building a static site with maybe 10 different pages, and it sure seems like it would be nice to not have to edit my (for example) title tag on every page when I want to change it.

In (for example) Django, I'd just use template inheritance, but, like I said, I'm building a static site.

What kind of template-based build tools will let me build a static site?

Jekyll exists for exactly this kind of use case.

# ¿ Mar 1, 2019 05:20

Roadie: Jun 30, 2013

Thermopyle posted:

This morning I'm trying to select a styling solution for the React app I started a few days ago.

How do you feel about using styled-components?

It's good, but also use something like rebass so you can just do stuff like <Flex flexDirection="column"> for simple cases.

CSS-in-JS is also a million times easier than other tools I've seen if you ever do dynamic theming stuff.

# ¿ Mar 9, 2019 22:05

Roadie: Jun 30, 2013

Use GraphQL, that way your pagination stuff is part of the settings of the client-side queries.

# ¿ Mar 14, 2019 05:14

Roadie: Jun 30, 2013

prom candy posted:

Use GraphQL because it's sweet and looks good on a resume

Also, it's nice to do literally all data retrieval and handling declaratively so you never have to worry about component lifecycle stuff again.

# ¿ Mar 14, 2019 06:07

Roadie: Jun 30, 2013

Thermopyle posted:

I've got some pngs that contain just single color simple shapes. Anyone come across any good tools for converting these to svgs? The first half dozen google results seem to generate huge bloated files...

If you're on a Mac, try Primitive?

# ¿ Mar 21, 2019 04:53

Roadie: Jun 30, 2013

You may also want to look at a more boutique CMS that can act as like a halfway step between the Wordpress world and a full top-to-bottom-custom site in Django or Rails. One good example is Craft CMS, which manages all the database stuff for you but lets/requires you to write the whole frontend, using templates + custom PHP plugins for any really weird stuff.

# ¿ Apr 6, 2019 02:35

Roadie: Jun 30, 2013

Thermopyle posted:

If someone is asking for it, ask them what they want and explain the difficulty.

Correct.

Heck, it could turn out what they actually want is a JSON file or something.

# ¿ Oct 10, 2019 09:28

Roadie: Jun 30, 2013

Mandatory arbitration means class action lawsuits are now de facto impossible for most people and small businesses.

# ¿ Oct 10, 2019 20:50

Roadie: Jun 30, 2013

NotWearingPants posted:

but I'm not seeing similar cheap all-in-one type hosts for node.js apps

The key thing you're missing here is that PHP is designed around every page access being a one-time script access that's also silently passing stuff through Apache or nginx, while Node servers stay active and handle responses. The latter does not at all lend itself to shared hosting.

NotWearingPants posted:

Netlify and Heroku wipe everything every time you deploy so there's no permanent storage for things like image uploads.

The Node world expects you to have your server separate from your data, using services like S3 for uploads, CDNs like Cloudflare for unchanging static files, or even stuff like PostgreSQL Large Object support. See the gigantic list of Heroku addons, for example.

NotWearingPants posted:

Is there a better way, particularly is there anything like the shared hosting world where I can deploy node.js apps, create unlimited mongoDB databases, limited only by high storage/bandwidth limits, for under $10 a month? And also some basic email hosting would be nice too.

Heroku hobby tier is $7/month fully pro-rated, so that's $0.0000027 per second per instance. Assuming you properly optimize stuff around the server shutting down when inactive and spinning up again on new requests, that's going to be dirt cheap. Adding mLab MongoDB with a max of 496 MB storage is $0/month on top of that.

NotWearingPants posted:

And also some basic email hosting would be nice too.

Any Node hosting that bundles email service is almost certainly junk that should be avoided.

Roadie fucked around with this message at 05:32 on Oct 23, 2019

# ¿ Oct 22, 2019 09:09

Roadie: Jun 30, 2013

Awesome Animals posted:

Now that I use it regularly and switch between different micro services the company I work for maintains, all with different versions of rails, ruby, and Postgres, I find it absolutely critical.

I've always felt like the software world being ridiculously terrible at versioning compatibility like this is 95% of why Docker exists.

# ¿ Oct 23, 2019 05:33

Roadie: Jun 30, 2013

Lumpy posted:

Seems to me the query and state are one level up from where they should be. GoalPage should care about that stuff, not App. If for some reason the whole app does care about that, you could use Context to make common state shared, or keep it in @client in the Apollo store and have queries inside components that care about it (or just have them duplicate the apps useQuery if it is cached)

Yeah, part of the whole reason to use GraphQL is that you can just staple read-only queries to whatever specific UI components are using that data, and it will then (if you have it set up right) debounce all the query stuff globally.

# ¿ Oct 29, 2019 02:51

Roadie: Jun 30, 2013

uncle blog posted:

Me again. I'm getting an error about an uneven amount of hook renders in my app. I'm trying to update my context state in an Apollo based object, when I add the useEffect call to set the state, the errors start happening. "Uncaught Invariant Violation: Rendered more hooks than during the previous render."

This seems to be the offending component:
code:
const GoalList = () => {
    const { loading, error, data } = useQuery(GOAL_LIST_QUERY, {});
    const { selectedGoal, setSelectedGoal } = useContext(
      ServiceOrderContext
    );

    if (loading ... error) ...

    useEffect(() => {
      if (data && data.things) {
        setSelectedGoal(data.things[0].Name, data.things[0].id);
      }
    }, [data]);

    return (
      <React.Fragment>
        {data.contexts.map((goal: any) => {
          return (
            <label>
              <input
                type="radio"
                name="goal.Name"
                value={goal.id}
                key={goal.id}
                checked={selectedGoal.id === goal.id}
              />
              {goal.Name}
            </label>
          );
        })}
      </React.Fragment>
    );
  };

What's in the if statement that you're eliding? You can't skip useEffect with an early return, that will break stuff.

# ¿ Nov 18, 2019 18:44

Roadie: Jun 30, 2013

Der Shovel posted:

The filter:

Use mapping, not loops. Also, put your fetched data in state instead of attaching it to the class instance. Also, don't use imperative calls for synchronously filtered values, just statelessly do it in the render function.

JavaScript code:

render() {
  const filters = howeverYerGettinFilterValuesHere;
  const { fetchedJson } = this.state;

  const filteredJson = fetchedJson
    .filter(
      item =>
        item.minplayers <= filters.players && filters.players <= item.maxplayers
    )
    .filter(
      item =>
        (filters.playingTime === "short" && item.playingtime <= 60) ||
        (filters.playingTime === "medium" && item.playingtime <= 120) ||
        filters.playingTime === "long"
    );

  return (
    <div className="something">
      {filteredJson.map(item => (
        <div key={item.something}>{item.whatever}</div>
      ))}
    </div>
  );
}

Don't worry about optimizing it until you actually notice any problems, and even then your first step should just be to look at memoization based on input values into the filter.

# ¿ Dec 8, 2019 22:11

Roadie: Jun 30, 2013

Der Shovel posted:

Wow, that's cool. I hadn't even thought of putting that junk in the render function. Thanks for the idea!

When in doubt, try to put any and all synchronous operations in the render function top to bottom as straightforward as possible. Once you have it working that way, that's when you consider whether you need helper functions or cached versions of processed data. (If you've written everything else to only re-render when absolutely necessary, you probably don't.)

# ¿ Dec 8, 2019 22:40

Roadie: Jun 30, 2013

To add to this, in modern browser versions there's a dead simple method now built in called fetch that's intended as the standard for the future.

JavaScript code:

function getServerResponseAndDoThing(inputText) {
  // This avoids having to manually escape text for a query param
  const urlParams = new URLSearchParams()
  urlParams.append("input", inputText);

  // This uses the browser builtin fetch, which works in everything but IE
  // [url]https://caniuse.com/#search=fetch[/url]
  fetch('/a-script-on-the-server.php?' + urlParams.toString())
    .then((response) => {
      if (!response.ok) {
        // This goes to the .catch below
        throw response;
      }

      // This is a promise, and its resolved value goes to the .then below
      return response.text();
    })
    .then((htmlFragment) => {
      // Write the returned raw text into the page as an HTML fragment
      document.querySelector('#id-of-a-div-on-the-page').innerHTML =
        '<p>' + htmlFragment + '</p>';
    })
    .catch((error) => {
      console.error('Attempt to fetch script response from server failed:', error);
    });
}

(Disclaimer: This is is all off the top of my head, may not work as exactly as written.)

The magic here is that whatever you're requesting from the server can itself be a PHP script or other dynamic thing that returns JSON data, formatted text, a fragment of HTML, or whatever that you can then manipulate and inject into the page. The "right" way to do this long term would be to look at JSON or XML data (which you can validate and parse for safety, handle error cases by using dummy data instead on the client side, etc) but for something like this a simple PHP script that returns an HTML partial should be fine.

You can pass input using basically anything a form would do, but for search bar style stuff query params like this are the simplest (PHP would just use $_GET for those, the same as a form post).

# ¿ Apr 12, 2020 02:03

Roadie: Jun 30, 2013

JWTs aren't for session data.

Personally, I've never actually seen a case where they're ultimately fundamentally better than just using a session cookie and centralized backend session management running against something with really fast queries.

# ¿ Jul 20, 2020 06:37

Roadie: Jun 30, 2013

go play outside Skyler posted:

I always found it funny that a lot of sites advertise JWTs as a solution to make page loads faster. As was mentioned in the thread, you'll need to implement a blacklist anyways, because stolen JWT = bad. Aside from that, in practice you will also need to fetch additional data about the current logged-in user anyways.

Plus, there's basically zero cases where you should actually be favoring cached data over live updates if you can update it. If the data is so static that it can never update, why is it even in user-side data and not just baked into your HTTP/REST responses?

# ¿ Jul 20, 2020 09:51

Roadie: Jun 30, 2013

Biowarfare posted:

No. No matter how much you gently caress with this you can always just edit the JS client side to always render it, or ignore your checks. This is why you validate server side.

Or, you know, somebody can just do curl calls directly to your backend.

Always assume that Dinkleberg is ready to catch you with your pants down at the worst possible moment.

# ¿ Aug 5, 2020 01:46

Roadie: Jun 30, 2013

fsif posted:

Seems a bit harsh, heh.

Art directors usually work across different media and knowing the rendering capabilities of the third most popular email client is relatively arcane knowledge.

Outlook.com specifically, sure, but knowing that HTML email styling is fundamentally nonstandardized and unreliable is just basic expected knowledge for that kind of thing (and is why bigcorps usually just go for 'HTML table full of proportionally sized images' if they need anything complicated).

# ¿ Aug 18, 2020 21:42

Roadie: Jun 30, 2013

fireraiser posted:

I can't seem to appreciate any other front-end framework's template syntax now after using JSX for a few years. It all looks like yucky old mustache or angular 1.x to me.

I have very little interest in Svelte because I can't use my existing tooling to statically analyze/lint its templating the way I can with JSX, since JSX maps 1-to-1 with JS.

# ¿ Jan 22, 2021 23:02

Roadie: Jun 30, 2013

LifeLynx posted:

Design standards; what requirements do companies give developers? I know major companies have style guides for writing CSS/SASS, Javascript, etc. This company works mostly with Wordpress, so I've already compiled a list of Do Not Use plugins.

For JS and CSS, replace the fiddly how-to-format-code bits of a style guide with just using Prettier instead. Set up dev pipelines so that it automatically runs everywhere, and make everyone set up their editors with Prettier plugins that auto-run on save. It'll get you "good enough" code formatting that's generally readable by everybody, and now nobody ever has to think about the fine details of laying out their code again.

# ¿ Apr 21, 2021 19:06

Roadie: Jun 30, 2013

The getStaticProps stuff also makes it super-easy to get "live-ish" data and all static pages with zero downtime by just setting up a scheduled re-deploy every X hours or whatever sounds reasonable.

# ¿ Apr 23, 2021 07:21

Roadie: Jun 30, 2013

Why get a managed VPS these days? Either get an unmanaged VPS and do it yourself, or do whatever you're doing using PAAS/SAAS offerings and never directly touching paying for a server in the first place.

# ¿ May 7, 2021 01:19

Roadie: Jun 30, 2013

A rough idea of the pieces you'd need for a project like that:

- A database to keep all your data
- A service running 24/7 to monitor and log train activity to the database
- One or more services to handle user authentication, to verify and save user selections, to generate points totals (depending on if you want this last one to happen on the fly and then cache the result, or have it as a scheduled operation the rest is built around), and to supply data to the frontend
- A frontend website with the actual UI for this stuff, connecting to that service or services

Depending on the frameworks you use, you can and probably will want to combine some of these. For example, Rails, Nest.js, and Django are all different frameworks (in different languages) that take various approaches to smoothly handling both frontend UI and backend service functionality in the same project.

The least painful way to start on this kind of thing would be to use a service like Heroku that totally abstracts away most of the management stuff around your services. It's much more expensive at the high end than using a "proper" enterprise setup, but if you ever actually hit that point, you're already dealing with enough money that you can hire a guy to migrate your thing to AWS/GCS for you anyway.

Roadie fucked around with this message at 01:10 on May 28, 2021

# ¿ May 28, 2021 01:04

Roadie: Jun 30, 2013

uncle blog posted:

Is there a rule of thumb for how big a React build should be? Under x megabytes?
I have some json data I want to bundle with it, but don�t want the page to be too slow to load. That�s the main drawback of larger builds, the initial load? They won�t be slower performing based on a meg or two of extra size?

Use dynamic import (assuming your bundler can handle it properly) and build the page with an appropriate loading state while the data isn't ready yet.

# ¿ Nov 16, 2021 18:30

Roadie: Jun 30, 2013

Ima Computer posted:

Here's another example of borders being annoying, even with defined dimensions. A list of items with identical padding where some of the items are highlighted with a border. If you avoid using an actual border, you don't need to worry about adjusting your padding so that the content of each item still lines up: https://jsfiddle.net/uxdaw01L/

Just use a transparent border on the things that aren't highlighted. If you're using css-in-js or the like this even makes things easier because then the only thing you're changing on highlight/selection status is the border color.

# ¿ Dec 12, 2021 00:02

Roadie: Jun 30, 2013

Dominoes posted:

Can you post an example?

Next.js, already mentioned a few posts above, is the obvious one. It's designed to turn as much as possible into static HTML, either at build time or by later rendering pages on demand and caching them across deploy cycles.

# ¿ Dec 24, 2021 01:12

Roadie: Jun 30, 2013

aperfectcirclefan posted:

1. Have people transitioned to Hooks exclusively or is it worth still using Redux?

The answer is "mu", because this isn't an either/or.

# ¿ Jan 10, 2022 19:07

Roadie: Jun 30, 2013

Cory Parsnipson posted:

If I'm using basic/bearer HTTP authorization headers, do I need to make sure I only do it over https? I feel like I can just look at the request headers and pluck out the info otherwise. That's what the random stuff I'm reading on the internet implies, I just want to make sure.

If you're using anything at all, you need to make sure you only do it over https.

# ¿ Apr 7, 2022 10:37

Roadie: Jun 30, 2013

worms butthole guy posted:

Honestly wix and square space do gallery sites stupidly well

# ¿ Jul 26, 2022 20:15

Roadie: Jun 30, 2013

Browsers all actively ignore autocomplete="off" now because banks and the like were abusing it to force people to always manually type passwords.

# ¿ Sep 21, 2022 23:19

Roadie: Jun 30, 2013

Fundamentally it's an attempt to get the best of both worlds, with "It's Just Static HTML" for anything that doesn't need to be interactive (ideally with progressive enhancement functionality using, e.g. old-fashioned forms but there's still a lot of holes in that), client-side handling for interactive elements, and for it to all happen in a single framework, language, and app structure with minimal data going over the wire.

It just all gets really complicated fast because (a) browsers are poo poo and take decades to add even basic UI functionality and (b) UI/UX data flow is inherently really complicated and that gets even worse when you add navigation state to it.

# ¿ Oct 26, 2022 22:42

Roadie: Jun 30, 2013

prom candy posted:

I'm seeing this take a lot over the past few weeks and it's really missing the point. The jump from HTML to PHP was "people want to do dynamic poo poo on the web." The jump to using jQuery/AJAX was "people want to make updates to just part of the page rather than having to do a full HTTP Request/Response cycle for everything." The jump to React/Angular was "people want web applications to feel as snappy as the mobile applications that they've now gotten used to and building those interfaces with jQuery is painful" and now the jump to SSR meta-frameworks is "people still want web applications to feel as snappy as mobile applications but also we want all the benefits of SSR and we don't want to duplicate a bunch of code between client and server."

If you can't tell the difference between what something like Next or Remix or SvelteKit offers vs. PHP I imagine we're working on very different types of projects.

# ¿ Nov 15, 2022 23:34

Roadie: Jun 30, 2013

The whole "www" subdomain concept is unnecessary and obsolete. Just redirect from www to the same path on the the domain for any oldbrains who haven't gotten the message yet.

# ¿ Feb 4, 2023 05:33

Roadie: Jun 30, 2013

Web components suck for a bunch of reasons, but the most obvious one is that they're stuck with string templating for all input and output.

# ¿ Feb 23, 2023 09:39

Roadie: Jun 30, 2013

prom candy posted:

Yeah I am deeply uninterested in what Next 13 and RSC have to offer. It feels like they're adding these layers of complexity. When I was first evaluating FE frameworks I went with React because compared to Angular (and Ember lol) its programming model was clear and simple. It feels like they're getting away from that more and more.

If you don't want the complexity, don't use server components? If you just want to stick to client-side stuff, there's nothing new needed other than the de facto standard around .client.js / import 'client-only';.

The rest of it is complicated because server-rendering specific layers of the component tree and mushing them together with client-rendered components while treating all of it as a single set of nodes for the user and doing it performantly enough that you're still coming out ahead in user experience even after eating the round-trip time is complicated.

# ¿ Mar 3, 2023 10:19

Adbot: ADBOT LOVES YOU

# ¿ May 17, 2024 16:58

Roadie: Jun 30, 2013

GraphQL is good for arbitrary external access APIs because you can effectively trim down payloads on the fly, but if you control both sides of the operation and everything updates in sync it's just unnecessary overhead.

# ¿ Mar 4, 2023 00:54

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Web Design & Development Megathread

«‹›2 »