Watching web developers react to this change on mastodon has been... interesting to say the least

The syntax is only difficult to read in their example.

I fixed their example here: https://programming.dev/comment/12087783

I'd recommend removing as many variables as possible.

Try getting a single html page to work (no mongoose, no preact, no vite, no tailwind).

If you can't get that to work, then no amount of tinking in preact/vite/tailwind/mongoose will help you.

Once you have a single page running, you can look at the next steps:

For scripting: try plain js, then js + mongoose, then preact + mongoose. If a step fails, rely on the step before it.

For styling: try plain css, then a micro css framework that doesn't require a build step (e.g. https://purecss.io/, https://picocss.com/), then tailwind if you really want to try messing around with vite again.

Oh cool, yeah and you're also using multiple repeating-radial-gradients to generate textured noise.

That's exactly what I was doing while working on a new button style.

Some gradients and some noise sprinkled on top to remove some of the flatness, but while I was experimenting with the noise I happened upon that really cool pattern and thought I'd share it by itself.

Lol, well I could change it, but it was based on the gif at https://quietkit.com/box-breathing/

I think it's because you're not supposed to expand your lungs so much that they feel like they're going to burst.

But if you scroll to the bottom of the css and look at line 69, you can change transform: scale(90%); to transform: scale(100%); to see if you like it better.

There's absolutely a massive internal bias people have where they naturally believe that others develop the same kinds of content, when really it's half working on page based content, and half working on component based content.

• Page developers know that putting their styles in the content itself is a disaster when you want to make a global change.
• Component developers know that putting their styles external to their components is a dx nightmare because developers keep making changes that they think only affects one component when it actually impacts a different component (and that change might not be found until months or years later).

Both are correct.

The real problem is developers thinking that there are only two methods for making styles: external css files, and tailwind/atomic styles in class names.

Component developers should have their styles inside their components, but not inlined in style attributes (like in tailwind).

Component developers should instead place a style tag inside their component that is scoped to just that component.

So let's say you're making an accordion component.

Make your html+js/jsx like you already do, and add an "accordion" class to your component's root element. Now add a style tag in your component with a single selector targetting the .accordion class. Now you can use nesting to style anything in the accordion exactly how you want. Want to style something based on whether an element is open or not? Use an attribute selector. Want to style something based on whether it's child is doing something? Use the :has() selector. etc...

If you're making a widget system, use container queries. If you're making a card system, use subgrid.

There's so many obvious use cases that modern css provides for, so use modern css! and not any of this BEM or tailwind nonsense. Now your css is so much smaller, robust and more maintainable.

Follow up questions:

Q: But I don't know modern CSS

A: Learn, it'll be much better for you in the long run compared to using tailwind, then needing to learn something else once people switch off tailwind for something else.

Q: But wouldn't putting a style tag in every component mean that there's going to be two style tags on the page if I put two of the same component on the page?

A: It'll only do that if you make it do that. Most component based frameworks are already set up to reduce repetition, check your framework's docs. (e.g. react's many css-in-js solutions, web component's :host selector, vue's <style> and <style scoped> elements, SSGs like Eleventy have Asset Bucketing, and even native html is getting it's own solution this year with @scope).

What do you mean by:

There is no way to split a tab into windows in VSCode.

Do you mean, drag a tab out of a window to create a new window? Because if so, you can do that in vscode.

This seems a little meh, people shouldn't be getting taught react or nextjs if they're not proficient enough with JS first.

That just teaches people to reach for frameworks when what they're trying to do could likely be solved in a few lines of code.

Your question:

what things did the LHC discover that have real practical applications right now other than validating some hypothesis

Is really multiple questions:

1. Is doing fundamental research with no application in mind useful?

2. Has the LHC led to practical applications usable today

The answer to question 1 is yes.

There's different types of research programs made to target different goals. Some aim for short or medium term applications, and others are just pure fundamental research.

Just because pure research doesn't have an application in mind, doesn't mean it's not useful. The application isn't the goal, the expansion of our knowledge base is. Everyone who ever thought up of an application for something did so based on their own knowledge base. If the knowledge base never expands, then we run out of applications to think up. This is why pure research is useful.

And all of history supports this:

• The discovers of rays shooting off cathode-ray-tubes in the 1800s were just doing pure research and had no idea it would lead to TVs
• particle accelerator research lead to invention of cat scans
• chemists trying to research heavier elements leading to the discovery of nuclear fission, leading to nuclear power
• electrolysis research lead to the invention of lead (and rechargeable) batteries
• etc...

The answer to question 2 is also yes:

The obvious ones are:

• improved manufacturing processes
• improved supercooled superconductors
• improved large scale vacuum chambers
• Improved data processing
• Trained a new cohort of experienced scientists/engineers/workers/etc (who can now work on new projects outside of the LHC)

It sounds like to me that you've taken your knowledge of your commonly used languages for granted, and assumed a new language would be just as easy. But if you watch a developer who is dipping their toe into that ecosystem for the first time you'll find them making mistakes and running into footguns you didn't know were possible.

Regardless of the language, not having a proper guide leaves devs susceptible to the incorrect blogospam that's out there, where engagement is rewarded over correctness.

Ignore all of the blogospam.

The two things you need to know:

1. C/C++/Java/Go/Python have all gone through changes, growth and churn just like JS.
2. Knowing the history of the ecosystem will go a long way towards helping you. If you understand why things have changed, then you'll know how to ignore the bad advice out there.

Here's my shortened version of number 2.

The beginning:

• JS starts as a scripting language embedded into a browser
• Different browsers try to copy each other but put in their own "features" pulling the language in different directions.
• The amorphous blob that is JS starts to congeal and language standards are solidified. This standard is known as ECMAScript (named for legal reasons). ES1 is the first version, followed by ES2 and ES3, each adding useful features.
• ES3 (released in 1999):
  • This is what you could consider the first long term stable baseline widely supported version of the language, where you can make anything you want.
  • Almost everything you can make in future versions of the language can be backported to ES3.
  • If you want to go by analogy, you can think of ES3 as javascript's C99.

The false start:

• Work starts on ES4 with a massive feature list (including static typing, classes, modules, algebraic data types, generators, embedded xml/xhtml known as JSX/TSX today, etc...). It fails due to political infighting, and for basically being too ambitious in a single version.
  • This sucks up years of progress between released versions.
  • This version is commonly seen as being poisoned by 90's/00's Micro$oft and the dark ages of Internet Explorer
  • But the spirit of ES4 was released spread out over future versions anyway.

The resumption:

• The v8 JS engine is released, making JS really fast and worth programming in. This is used in Chrome and Node.
• ES5 (released in 2009):
  • Adds native json support, reflection, and a strict mode to avoid some footguns with ES3
  • Think of this as C11
  • Some developers being experimenting with a more consise syntax in CoffeeScript that compiles down to ES5.
• 2012: Typescript is released adding an optional and gradual typing system to JS (inspired by C# and ES4) designed for both Humans and Computers.
  • In effect, this brings IDE-style support for JS
• ES6 (released in 2015):
  • With the lessons learned from CoffeeScript, a whole bunch of syntactical sugar is added to make the language more pleasant to write in.
  • With the lessons learned from community made modules, an official module spec is released and added to the language.
    • Known as ESM (EcmaScript Modules)
    • The community starts moving away from unofficial modules (CJS, AMD, UMD)
  • Babel is created to allow any developer to create and share their their own language extensions.
    • The faster feedback cycle from Babel allows for smaller and more frequent language updates.
    • Javascript moves to a yearly release cycle and ES6 is renamed ES2015
• ES2016
  • Adds block scoping as an alternative to hoisting
• ES2017
  • Adds async/await/Promise() syntax sugaring, to make asynchronous programming easier
• ES2018
  • Adds ... (rest/spread operator) syntax sugaring, to make destructuring and variadic functions easier
  • Ryan Dhal (creator of Node) releases his famous 10 Things I Regret About Node.js talk. Announces his intention to create a "modern reset" of Node known as Deno.
• ES2019
  • Minor changes
  • Deno is released
• ES2020
  • Adds ?? Nullish coalescing operator syntax sugaring
• ES2021
  • Adds ??=/&&=/||= Logical assignment syntax sugaring
• ES2022
  • Adds top level await, making asynchronous programming easier
  • Adds private field syntax sugaring
• ES2023
  • Minor changes

The current state of things

• Language-wise

  • Javascript has added a whole bunch of syntactical sugar since 2009 making it really pleasant to code in.
  • Typescript adds some really nice IDE support to Javascript and the vast majority of all libraries and frameworks are written in it giving that IDE support to Javascript developers.
  • Babel allows developers to create their own language extensions, which are frequently put forwards at for other developers to give feedback on. Useful proposals are added to the language on a yearly basis.

• Runtime-wise

  • Node is considered the older slow-moving most-stable release of running JS outside of the browser
    • Think Debian
  • Deno is considered the friendly Node, coming with all the tools a developer needs (linter, bundler, tester, ts support, etc...). In the last 5 years it has reached almost complete feature parity and compatibility with Node.
    • Think Ubuntu
  • Bun is a brand new kid on the block prioritising speed over compatibility.
    • Think nightly linux

• Standard workflow

  • Write in typescript
  • Let your editor check your typescript while you're typing live so you don't need to go through a compile cycle
  • Let your project's stack compile your typescript for you.
    • If you're writing a new project from scratch, Deno will run typescript for you.
    • If you want to build a new stack from scratch with no assistance, use the typescript project itself to check and compile your code into js, or use esbuild to strip out the typescript types to turn your typescript into js. (most developers elect to strip types since your editor/ide should be live checking your typescript anyway allowing you to skip a redundant compile check cycle)
    • If you're using an existing stack, your build tools will compile/strip-out typescript for you.

• Tooling wise

  • Most projects use Vite / rollup / and other "zero-config" tools to build and bundle their applications. Some older projects still use Webpack (which does the same thing, but with a more complicated config file).
  • Everyone uses ESM modules now, almost no one uses the older modules.

For your simple fibonacci example:

1. Create your fibonacci module that exports your fibonacci function
2. Import module
3. Call function in module
4. Pick your endpoint:

• Browser endpoint: Output result in console.log() and see result in browser's console.
• Server-side endpoint: Output result in Deno.serve() and see result in network requests/responses
• CLI endpoint: Output result in console.log() and see result in terminal

I'm curious why people would downvote a request for port forwarding?

I had no popus using uBlock Origin on Firefox