thomasikzelf

+ design looks better then the "minimal" style original

- dish in the top left is not on the menu (why is it there)

-- why is there a malnourished cow on the menu?

++ photos of of the product so you can see what you are gonna get

--- the photos do not match the actual meal

I did some energy price forecasting and my neural network learned the morning evening patterns just from historical data, it worked great. Then I tried adding more information to this like wind and solar (and many more). None of these external factors made any difference while being very important for energy prices. It seems like the market already incorporated all the factors in the price (as they should).

The takeaway might be that historic data of market data might often be enough to make a reasonable prediction. Only external data that nobody else has (used) can make your prediction better then the market.

Making a prediction with same accuracy as the market: easy Making a prediction with more accuracy then the market: very hard

Cool app! I also had some ideas a while ago that I think the current breed of aim trainers are still missing.

In-game practice like the Range, DM, and Team DM still feels like the gold standard to me. I generally only use aim trainers when they offer a noticeably higher return per minute, rather than just teaching me how to get good at aim trainer specific mechanics.

Here are a couple of things I think an aim trainer should have:

- Dynamic difficulty: I feel it works best when trying to keep accuracy relatively high, but fluctuating the target accuracy threshold over time and adjusting difficulty dynamically to match it. That keeps you challenged without breaking form.

- Dynamic scenarios: Instead of picking scenarios manually, I think a trainer should ideally detect what you suck at and launch those directly.

- Habit coaching: It would be awesome if a coach flagged bad habits in real time—like clicking too fast (low accuracy), doing a slow tracking movement instead of a sharp flick (mircoflicks), or using tracking when click timing is needed.

- Biomechanics: Finding the exact "perfect" sensitivity feels less important to me than ensuring your arm and wrist are working together properly, altough this might depend on your aiming style.

- Simplicity: A lot of trainers overwhelm you with numbers and menus. I image a simple "click here to start and follow feedback" workflow with nothing else for the user to learn. Seeing a bunch of numbers is less important to me then just getting better (maybe with a final score).

Valorant-specific focus: Trainers often feel too generic for tactical shooters like Valorant, where angle holding, target reading, and micro-corrections dominate.

I built a small aim trainer to experiment with these ideas myself: https://mousecontrol-thomaswelter-fceff2dbe456668c6bedef32db... (the aim trainer is very basic, only made for myself, fixed sens etc).

- In this tool, difficulty scales dynamically while playing (the parameter in parentheses changes on the fly):

- Angle Hold (enemy speed increases): Practicing holding angles against multiple targets. Holding angles is crucial in Valorant (just look at how Primmie plays).

- Follow (standstill window decreases): Forces active mouse correction and reading the target before shooting. I tend to click too fast, so this forces me to slow down and micro-correct.

- Jiggle (jiggle speed increases): Targets perform tight jiggles. I find players who spam small jiggles really hard to hit, so this directly targets that weakness.

- Micro Flicks (snap distance increases): Micro flicks are easy enough to train in the Range, so I mostly use this mode when I am away from my gaming PC.

- Static (target size decreases): Standard static clicking, but with dynamic scaling as targets shrink.

- Strafe (movement speed increases): Moving targets with limited hit windows. When watching pro DM VODs, most kills are on stationary targets, but hitting moving players is still vital and tricky to isolate in-game.

I am still not very good at Valorant but the aim train ideas are interesting. Let me know what you think!

I have visited factories for work and my experience is the same. There is so much stuff that could easily be automated but is not because it is too expansive for too little value to make a custom one off machine. The big high volume things will be automated but these machines will have 90% success rate and lot's of stuff that needs to be done by hand. You can search for factory tours on youtube to get an idea. Here are two videos, an Amazon warehouse and a Tesla factory. the big heavy stuff is automated but lot's of work is still done by hand. https://www.youtube.com/shorts/-R6cBkza17k https://www.youtube.com/watch?v=45slYC99uUg

It looks like one stole the design from the other, I don't know which one, haha.

Nice, I will be following your posts! I just bought a robot arm myself, the seeed studio B601DM (€1500 6+1 axis), it works great and is open source hardware as well and a bit more solid then the so101. I also opted to not use ros, I don't want to give up control by putting another framework in between. Is your plan to see whats possible right now or do you also have ideas on how to improve sota?

firefox android does not support CSS animation-timeline, and firefox desktop needs layout.css.scroll-driven-animations.enabled. This probably should not be used for any critical features.

You can make some really cool stuff with css scroll animations. I used SVG paths with a scroll animated dash offset to draw an image while scrolling. Zero javascript, it feels so smooth. https://thomaswelter.nl (the background)

The declarative vs imperative example is strange here. Why is the imperative example so convoluted? This is what one could write in js:

  badge.textContent = count > 99? '99+' : count
  badge.classList.toggle('show', count > 0)
  paper.classList.toggle('show', count > 0)
  fire.classList.toggle('show', count > 99)

I was also banned from claude. I created an account and created a single prompt: "Hello, how are you?". After that I was banned. An automated system flagged me as doing something against the ToS.

I recently implemented a Hindley Milner type checker. The algorithm itself is not necessarily super difficult (once you get your head around it ofcourse) but the way it is explained is. It seems like HM is mostly explained by people with a mathematics background that already know the proper notation. I wonder how much overlap there is between people that know the notation and do not know how HM works, probably not much.

Anyway nice demo. Bi-directional is already quite powerful!

Really, that is surprising to hear. There are a couple of differences but most of the syntax looks the same to me, what part do you find alien?

The reskill problem is of similiar difficulty with learning a new framework I think. Especially because the language is rather simple compared to typescript (which is also its strength).

I do understand it is an uphill battle. The whole nobody get's fired for choosing IBM thing. The language is still unproven in the general perception. I do think that when it comes to libraries and frameworks I see a lot of developers choose new unproven stuff, more then they do languages.

Have you seen ReScript? Of course it is not as popular as typescript but it improves on all the bad parts of typescript. You'll get sound types with the pain points of javascript stripped out. Because it compiles to readable javascript you are still in the npm ecosystem.

You don't have to rewrite your whole codebase to start using it. It grows horizontally (you add typed files along the way) compared to typescript which grows vertically (you enable it with Any types).

The point is that we don't have to move back to plain js. We have learned a lot since typescript was created and I think the time has come to slowly move to a better language (and ReScript feels the most like Javascript in that regard).

If Typescript is javascript with types bolted on, Rescript is javascript with types the way it should have been. Sound types with low complexity. https://rescript-lang.org/

You might be using the webgl lines (LINE_STRIP), those are always thin. The other way is to build a mesh that looks like a line (which Three.js also has functions for). select the line type here to see the difference: https://threejs.org/examples/?q=lines#webgl_lines_fat

This looks good! It feels a little bit similiar to ReScript. I like the idea to have nodeMain, browserMain and buildMain. The Roc language had something similiar with platforms and I love that idea!

In general I prefer a better language over an involved javascript framework that does not look like js anymore.

I agree separating your UI into components is important. If React learned us one thing it is that keeping related stuff together is the way to go. Separating into components and keeping your functions as pure as possible gives you 95% of what makes React great! You can read my answer to @iliaznk on how I do this.

cleaning up listeners or cleaning up DOM nodes is rarely needed. Just remove the component element and the browser cleans up automatically.

    <select id=dropdown>
        <option value=a>a</option>
        <option value=b>b</option>
    </select>
    <select id=a style="display: none">...</select>
    <select id=b style="display: none">...</select>
    <script>
        const $ = name => document.querySelector(name)
        $('#dropdown').addEventListener('change', ev => {
            $('#a').style.display = ev.target.value == "a"? "block" : "none"
            $('#b').style.display = ev.target.value == "b"? "block" : "none"
        }
    </script>

    const [showing, setShowing] = useState(null)
    const handleChange = ev => setShowing(ev.target.value)
    let other
    if(showing == "a") other = <select>...</select>
    if(showing == "b") other = <select>...</select>
    return <>
        <select onChange={handleChange}>
            <option value=a>a</option>
            <option value=b>b</option>
        </select>
        {other}
    </>

- The complexities of both of these tiny pieces of code is similiar (I would say)

- React needs to load a big bundle

- React spits out a large stacktrace with react internals if something goes wrong

- React is slower

- React code cannot be easily stepped through with the debugger

- React needs a build step

- React performance is very unpredictable (this is more of a problem with many elements and dynamic code)

Your next question might be what you do once your form grows huge. See my other answer to @iliaznk how I handle that.

I do use abstractions to make my life easier. The main abstraction is a function called tag:

    const tag = (tagName, props, ...children) => {
        const el = document.createElement(tagName)
        for(let k in props) el.setAttribute(k, props[k])
        for(let child of children)
            el.appendChild(typeof child == 'string'? document.createTextNode(child) : child)
        return el
    }

The main advantage I think React brought is breaking the concept of "separation of concerns" (keeping css, html and js in different files even when they change together). Keeping stuff that belongs together in the same file and mostly pure is what gives the most benefit. You don't need complicated frameworks for that.

    const createSpecialButton = text => tag("button", {style: "background: purple"}, text)

I wrote a figma clone (see other comment) with couple of these utility functions. It looks a lot like a regular react project really. Mostly functions (which you might call a component if they return HTML), mostly pure or local state.

If you are writing the same DOM update code in each event handler you can abstract it into a function.

If you go to the React website you need to click "Learn React". A library often does not make you learn new concepts. It is just functions with input and output.

On the first page "Quickstart" all code blocks contain code that contain JSX and call you. They do not even show the part where you need to call render. Copying this code into your codebase will not do anything.

On that same page they also introduce state management with hooks.

On the installation page npm installing react is not mentioned. They suggest using create react app.

Sure you can theoratically use react as a library but I've never seen it and from the website it seems like usage as a library is not the inteded way to use react.

The first sentence "The library for web and native user interfaces" is the only thing pointing to react being able to be used as a library. The rest of it looks like a framework to me.

I don't think this has to be true. If you think of a framework as a piece of code that calls you where you sort of supply it with configuration you could do that when writing vanilla js but you don't have to.

When I write vanilla js I don't have a seperate file called framework.js. There is very little code needed to manage state. Almost all functions in my codebase are doing concrete things.

I build a figma clone for animation (https://moos.app). It is by no means a super large project (I think 40k loc) but is has reasonable frontend complexity. Most stuff is just composed of simple functions. For example routing is just an eventListener on hashchange. For state I am passing around an environment or firing events (the event system is 100 loc). For showing UI there is one convenience function to create HTML elements. Basically tag(tagName, props, ...children) (implementation also 100 loc). Each view is it's own file and manages itself. The object list can contain thousands of items so it uses a virtual list for performance (100 loc).

As you can see most functionality can be implemented in around 100 lines of code. The advantage is that you can build up functions just for your needs. These functions are super easy to understand because they don't have any dependencies and the whole implementation fits on one or two screens. There is very little indirection.

Another advantage is that most code is actually doing something concrete. With frameworks you often have a lot of code that is just pointing to other code, or is boiler plate code to set something up. Not having any boilerplate code also makes stepping through the debugger a lot easier.

The project has no build step in development which also makes debugging easier. It does have a build step in production.

Most people use frameworks to give the code structure. When writing vanillajs you need to bring the structure of the code yourself. This does take some getting used to but I think it is an essential skill for good programmers to have. On top of that many frameworks push you into structure that does not make much sense in my mind (for example seperating the view and the controller if those are always gonna change together).

So to conclude: My advice for building without frameworks is, just start building. Problems will come up and you can tackle those as you go. Do you think you need to use events in your application? A simple implementation is 10 lines of code and can be written in 10 minutes. If it takes me 1 hour to not use a library I will spend that 1 hour. Most frameworks will not bring that much value. Easy things become short and hard things will become impossible. I think most value is actually brought by the language and the basic api's (DOM, CSS, etc)

You should try ReScript. The language has improved a lot recently. If Typescript is javascript with types bolted on then ReScript is javascript redesigned the proper way. The lsp is also surprisingly good. All that while still being in the node eco system.

Writing simple code is also much harder then writing complicated code. If you write some complicated code at the limit of your mental capabilities you can not debug it, but you might also not be smart enough to write the simple code.

I guess this means that one should solve the appropriate problems for a given skill level

ReScript changed their api from data-last to data-first for this reason. Coupled with amazing type inference you will almost always receive correct autocompletions (that are type valid as well). It is a great experience.

It is sometimes still a problem when you define a function without reference to it (because the types are unnkown ofcourse). You will have to add types to it or call the function before implementing it.

There was also a great blogpost about it: https://www.javierchavarri.com/data-first-and-data-last-a-co...

Of course Brett Victor has the essay on his website: https://worrydream.com/refs/Lockhart_2002_-_A_Mathematician'...

It is a great read!

I used the W5100 before with Arduino but I am not sure about "gold standard" quality. I had a lot of issues with random disconnects several times a day with this board. Maybe it's the board, or maybe it's the arduino code or the connection. Or maybe it was my code. I don't know. Eventually I switched to a pi and never had any connection problems anymore.

When it comes to tcp connections linux seems more robust.

I really liked https://webglfundamentals.org/ for learning the webgl api coming from a web background as well. The state diagram was also useful to understand the complicated api. There is also https://webgpufundamentals.org/ for the newer api.

cool demo. I loaded my own codebase to look around in it. I could really see this being added to an IDE to get an overview of a code base (and it also looks good).

It reminds me of the following demo: https://wdobbie.com/pdf/ from this post: https://wdobbie.com/post/gpu-text-rendering-with-vector-text...

Some tips for others (when trying with your own repo): - you need to rename any index.html files and clear the browser cache otherwise it skips that folder - change the value at wb-librarian.js:98 (this.screenCursorY) to a value that better matches the size of your code base