This had to do with leaking privacy sensitive information such as visited links by reading back pixels from a rendered <a>. They fixed this with a concept they call "read-back-allowed rendering"
161 karma · joined July 2, 2020
- 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
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
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!
badge.textContent = count > 99? '99+' : count
badge.classList.toggle('show', count > 0)
paper.classList.toggle('show', count > 0)
fire.classList.toggle('show', count > 99)
Anyway nice demo. Bi-directional is already quite powerful!
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.
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).
In general I prefer a better language over an involved javascript framework that does not look like js anymore.
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.
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.
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.
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.
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)