Since then we've gotten: position: sticky — which is like fixed but only "fixes" itself once its Y offset is satisfied. Updating the bookmarklet to also check for that, in addition to position: fixed would help modernize it a bit.
"No, don't finally release the top-secret files that have had a huge impact on our culture and have led to decades of confusion, distrust in government, and wild conspiracy theories."
And no one is saying that… not even the comment you’re replying to.
It makes a good point though, there’s so much going on in the executive branch right now. Much of it is destructive imo. This is a great distraction for most Americans who aren’t very tuned into politics in general.
Comments decrying or dismissing the disclosure to the public of long-hoarded information is saying that, IMO, and that's the joke. It sounds like a point no reasonable person would make. "there's too much going on right now for this long-awaited transparency" has got to be the silliest thing I've heard on HN in a while.
Something can be highly anticipated and utterly inconsequential at the same time. (See Star Wars Episode 1 as a primary example)
These assassinations were tragic and criminal and shocking at the time, but one has to be Gen X or older to have any emotional connection to them. To the rest of us, it’s just a chapter in our history books that’ll get a new paragraph or two appended now.
To be frank, there are far more important things here than the JFK conspiracy. I am glad it’s being released, but it’s okay to have issues around the context in which it’s being released. It’s clear with the stack of other executive orders that this is intended as a distraction.
In the meanwhile, we have things like the equal employment opportunity act of 1972 being repealed.
If you think that last one is a good thing then I see why you’re being reactive.
> In the meanwhile, we have things like the equal employment opportunity act of 1972 being repealed.
This isn't true. Executive Order 11246 got repealed, which people have lately been calling the Equal Employment Opportunity Act of 1965 even though that was never its name. The Equal Employment Opportunity Act of 1972 is still the law of the land and Trump has made no attempt to repeal it.
jQuery got the Nickelback treatment. Except I really did enjoy using jQuery, and only moved on because "the industry" was and I didn't want to be left behind.
Looking back now, we all were lead down a path of needless complexity. Even thought I'd never use jQuery or jQueryUI professionally now, I still have a voice in the back of my mind that will pop up every now and then to say "well, if it's not gonna be complex or long-lived..." when something calls for a quick UI.
I feel this way about Bootstrap and maybe now am old enough that I don't care if it upsets other developers.
Something like bootstrap seems so ludicrously non-complex that I don't think anyone competent should be getting upset with you for its use.
I mean, OK fine, go ahead and fanboy/girl Vue/React/(Needless complexity api) whatever. But really? They get upset looking through code for an HTML5/bootstrap page? Something's not right there. That's when you start suspecting they can only work in one api, and likely don't even really understand css.
I agree. To me, TWBS is just a collection of intuitive components that have been tested vigorously. They also function in a way that way people are used to because of their lineage. That they can be styled in a way that makes them not look stock...ices the cakes.
jQueryUI does something different and they are not mutually replaceable. JQuery does not do what tailwind does. And tailwind does not do what jQuery does.
JQueryUI is also in maintenance state, basically a retired project.
The first syllable of Asperger sounds like “ass”, and the mom was making a pun based on that fact (pointing out that her son’s Asperger’s made him an ass).
I'm in love, I didn't know I wanted this, and now here it is. With an explanation from the author that touched on things I was feeling but couldn't quite but into words. To ice the cake, saved the file to disk and ran it with WiFi off, just to see. Sure enough, it's all in there, self-contained with no fetched dependencies.
One caveat being that in the file:// protocol URL params don't work e.g. ?app=c53f8e9f-4b7a-4315-bb8a-f6557f6be30b
This is fixed by running a local webserver, which isn't a huge deal. I'd be happy to learn of an easier way.
I'm also a single file .html app distribution technology enthusiast.
Query string parameters totally work from file://
I built an online sandbox that lets you create them. To prove it, you can navigate here [1], then click the "Download self-contained .html" item on the hamburger menu.
I also like single-file offline web applications, I'm hoping they become more popular with the FileSystem/FileWriter APIs now available in Chromiums (waiting on Safari/Firefox still however).
Only thing missing really is a CLI interface. I wonder if there's a way to make HTML files executable on the command line, pass through arguments as qs params.
The amount of times I make a little nodeJS app to do something with a set of files, the webserver bit seems so overkill sometimes..
You could literally run the Golang compiler in your browser if you wanted to (emphasis on in your browser—not deferring to a server to do the heavy lifting) without any of that stuff.
A lot of the stuff that people think they need Chrome's proposed filesystem APIs for are not actually things they need.
Every mainstream browser accepts directories for both type=file inputs and for drag-and-drop, and that's been the case for years. So that's a non-issue. That aside, the next thing people pretend they need it for is so their app foo.html won't fail when it tries to read and write to or from ~/.foo and /etc/foo and anywhere else the author chooses, whenever they want. But apps can and should be rewritten not to expect that kind of ambient capability. The fact that in-browsernapps can't do that stuff is a good thing. There's usually nothing stopping the author from refactoring their program to either output a single binary file or .txt or whatever the main thing is that the program is supposed to output, or if the purpose is to write out multiple assets, then output a composite file format like ZIP or tar. I mean owing to its history and the context when it was created, the ZIP format already supports archives spanning multiple volumes/files. And that gets you automatic support for file versioning for free! It's the exact same version control strategy that Git uses and proved is viable: full-content snapshots—the difference being if you're doing ZIP, the opportunity to also use DEFLATE is natural and right there.
> Only thing missing really is a CLI interface.
If you want people to be able to use it from the command-line, write your app as a polyglot file foo.htm so that anyone can double click to open in their browser if they want to or run it as `nodejs foo.htm` since NodeJS doesn't care about file names but browsers do (for any files loaded from disk). If you want to "pass through arguments as [query string] params", then you're opening it in the browser and not really providing a command-line interface so there's very little difference between having them type the arguments out in their shell before pressing Enter or typing them into the app when it's open in the browser.
Again this is one of those things where nothing's stopping anyone from doing it right now today. They're just not doing it. As the Book Overflow guys said in a recent episode (the review of Wolfram's book on ChatGPT)—all the pieces are there. Or to borrow a turn of phrase from Raskin that gets down to the truth of the mess we're in[1], "none of this is necessary; it is merely customary"[2].
You can do a lot of things by dragging folders onto file inputs, but it is somewhat rubbish for user experience with the friction of getting files in and out of your app. Obviously it depends on what you want to do, but it seems a limiting factor. Allowing HTML application permanent permissions to file system without user input makes apps a lot more useful and portable.
Recently. I wanted to organize around a thousand short videos. I looked into software and the solutions were really integrated, media library etc. MacOS has tagging in the filesystem, but that ties me to an operating system, and didn't give me the explore related function. I wanted something that could let me browser a folder with added metadata, explore related clips etc.
After looking at all the options I could find, I realized it was easier to just build myself a little Node.JS app using sqlite for metadata, it worked great. I plugged in local ollama and whisper for transcriptions and automatic tagging, which worked suprisingly well. It's annoying needing to run a server for such a simple app, packaging it is just so heavy ... and I thought, it's really not that far off being something I could do in a single HTML file, it was pretty much just the filesystem access - then my app/content is just a folder that does what I want to on any platform without installations or configuration.
Thanks for linking the Joe Armstrong lecture, I've watched half and its wonderful.
> it is somewhat rubbish for user experience with the friction of getting files in and out of your app
It's not worse, generally, than the average experience of using a NodeJS program that won't run because the dependencies didn't install correctly or it's the wrong version of the runtime, or... (cf Armstrong; or, to borrow a saying by Ousterhout (with a small tweak): the greatest improvement to a program of all is when it goes from not-working to working).
The two worst rough edges for file saving for browser-based apps are:
- if you consider, say, a paint program that you're using to work on an image, it can't implement the ordinary save behavior where some keyboard shortcut or menu items saves (overwrites) the current file you're working on; to do the same in the browser requires the user to do the equivalent of a Save As every time (instead of a Save)—i.e. complete with a prompt to double check that the user really wants to overwrite the previous file
- some browsers have changed the default download behavior so it automatically saves to a downloads directory without asking the user and allowing them to change the path/filename with a conventional filepicker; this setting has to be changed by the user themselves to get the old, circa 2005 browser download behavior
These are both issues that can be fixed and don't require something as expansive as Chrome's filesystem API proposal.
re alternative options to your NodeJS-powered video tagging application server: check out <https://redbean.dev/>
I agree, file access via upload/download concept is friction on the user experience. I'd love to see serverless offline HTML applications with permission based file system access, because you can do so much very quickly in the browser with access to GPU, bluetooth, USB even, but I'm not holding my breath because of the security implications
Redbean looks good, I didn't know about the APE format, but unfortunately doesn't solve the file system access problem without presumably rewriting a backend in Lua. Docker, reluctantly, is better than nothing.
I suspect Justine will eventually do what the Cloudflare Workers team did, which is after having originally only supported Lua, to start supporting JS (albeit via quickjs in the redbean case, rather than V8) and then see wild uptake.
Yeah slingcode is very cool! It is like a platform/IDE for apps similar to tiddlywiki.
unfortunately it is not maintained anymore so I posted it here with the hope of finding some similar project from the community :) Or use it as a motivation to release a similar project
From where I'm standing, it looks like when Dorsey was CEO, leftist accounts got more leniency and were more likely to not be banned after being reported for offenses—be them legitimate or not; this was the opposite for accounts on the other end of the spectrum. When Musk took over, this phenomenon was completely and totally inverted. IMO.
While I tend to agree with your sentiment, this particular project resurrects bricked-by-corporate e-waste—I'd call that a win.
Plus, let's have fun while we can. On the next planet, cameras will be recyclable, limited to 12 holographic shots, and wrapped in humble cardboard. You'll have to take it to the local colony druggist for developing. Perhaps you'll browse Earth Imports section while you wait.
I would hope that we eject our ewaste into our star in a sustainable way.
The model says I'm being too speculative about our future and that we should tackle ewaste better right now. The model is usually right.
Appreciate the comment. I guess every little bit helps. Maybe I'm becoming a bit of a hater. The last project I commented on in this way had much less utility.
That mistake is that it's not true. Altman has earned a name for himself in the truth-telling/transparency department. He wasn't briefly sacked for his fashion sense.
In the article they quote Marc Fagel, who previously served as the regional director for the SEC's office in San Francisco:
"Misstating the qualifications of executives is something the SEC takes seriously,"
I accidentally corrected someones use of a word on here and got downvoted so hard I was scared to comment for months. I guess what I'm saying is I'm surprised this very honest comment from hours ago never went grey. to be clear: I am just surprised.
