141–150 of 171 posts
[1] https://muki.io
Earlier quoted context omitted.
I feel the analogy is more like: You need to fix a single brick so you buy 72 pallets of bricks, buy a fork lift, 5 cement trucks, buy a garage to park them, try to acquire at least 2 cement factories, hire 4 people to do logistics, someone to do HR, 12 truck drivers and 4 fork lift chauffeurs. Placing the brick is outsourced.
I like that this comment is from “6510”. I loved the old 6502 and did a teeny bit of assembly programming on that back in the day.
I implemented an entire database in VanillaJS: It runs in-production with 10M+ monthly users! https://github.com/amark/gun ~13KB I get a lot of hate for not-using-2ton-framework-of-the-month. But I think prioritizing performance is worth the flack. Seeing repos/articles like this deeply warm my heart, maybe us VanillaJS devs are not alone after all! Does anybody have other favorite VanillaJS projects, that they could…
Cool 3 letter names. Reminds me of the commands in Bloomberg Terminal/some old HCI. I really like how you've built a whole stack of custom tech there. That's my aim too. My work is all Vanilla. I hate to use external frameworks and libraries in the browser, but love to use stuff on npm. I prefer to write something I like to use, rather than use something that exists that I don't like working with. You can see portfol…
I love these type of showcases. It‘s been a wonderful time when simply upload files via SFTP and had a running application. No need of webpack bundles, vendor libraries to achieve a simple functionality that could be solved in a few lines of code ... I really do hope this kind of developer attitude (writing pure VanillaJS) is coming back.
Here's a simple no-framework points calculator for the sport of Powerlifting: https://www.ipfpointscalculator.com/ The page is 11KB, loads in 96ms, and makes three requests to one network, two of which are favicon-related. This turns out to actually matter in practice because many of our users are from countries with extremely slow connections.
My point is mostly: do vanillajs but also understand what api's are actually available for you from the start. There is a lot built into the browser, use it. Usually it already has better performance and accessibility than whatever you would write yourself.
Earlier quoted context omitted.
The function `requestAnimationFrame(update)` on line 191 [1], typically updates at 60 frames per second [2]. When it fires, it re-calls the `update()` function starting on line 184 [3]. As you say though, it's not 100% reliable in terms of speed, but I imagine 90%+ who play the game get a good experience. [1] https://github.com/bradtraversy/vanillawebprojects/blob/mast... [2] https://developer.mozilla.org/en-US/docs/…
True when using a normal monitor, but could be a problem if using a 120Hz monitor or if the previous call didn't finish fast enough. The best is to use the timestamp requestAnimationFrame sends in to the callback to find time-delta since last call >> The number of callbacks is usually 60 times per second, but will generally match the display refresh rate in most web browsers as per W3C recommendation.
Earlier quoted context omitted.
That's nice. I myself did try out one too, as a hobby project to serve as an alternative frontend for a local gym https://varjosport.net/ There's a small flicker as the app generates the HTML which still annoys me but I couldn't bother to write a Lambda to server-side render the HTML every time the data is refreshed. One thing I noticed though was that creating HTML fragments is a major pain in the ass, which I see y…
With styles in components, can you support skinnable components? If so, do you have to accept parameters in the component and modify the component every time you want to change some style to make it fit with your page look and feel?
https://codyhouse.co/blog/post/css-custom-properties-vs-sass...
Earlier quoted context omitted.
There's an irony about posting in a topic about simple, vanilla, no-framework scripting and then linking to a repository with the following unnecessary ancillary files: .gitignore .prettierrc README.md REQUIREMENTS.md manifest.webmanifest package.json tsconfig.json yarn.lock Plus the actual source code is spread over four TypeScript files, JavaScript, CSS, and HTML. This isn't meant as criticism of your code specific…
Right, OP totally should have included the interview question requirements as a commented block at the top of index.html instead of separating it out. It's way too complex as is. And definitely, .gitignore is well known to be responsible for the "complexity of web development." Maybe we should include .gitignore in index.html too?
Earlier quoted context omitted.
Until we rediscover that manually keeping the DOM up-to-date is tedious and error prone for almost any project and switch to a good middle ground such as Preact or React without a build step
I prefer to just refresh the page. Throw away the DOM and render a new one from scratch server-side.
Also, not everyone wants to maintain a server for everything. Static file serving is just way easier sometimes.
Earlier quoted context omitted.
I'm having trouble reasoning about this code, can you show me how it's used?
It creates a function returning a function, where the argument to the first (which is a template) is used as a closure in the second (which takes a dict of values). The last function called in turn creates a function using the Function constructor, which, since it takes a string argument as the function body, allows the expansion of the values dict into variables and thus the population of the template string: applyT…