-
This is great and very interesting! We need more people working on stuff that really challanges the status quo. Keep it up!
-
Just a heads-up: the app doesn’t seem to be available outside of the US App Store.
-
IIRC this is temporary. Apple pulled a lot of apps from EU app store on GDPR day pending… something. I’m not an iOS developer, so no details
-
-
Detail work on my personal site, namely working on weird viewport size reckoning / scrolling behavior on mobile browsers. Also considering dropping in ServiceWorker caching and friends for offline access / buzzword practice.
-
Just a heads up: it scrolls really weird on iOS. I suppose it might be because of your implementation of the “sticky” header? I can’t look at the code right now, but I’d recommend either making the header sticky using
position: sticky; top: 0, if that is the problem, or using-webkit-overflow-scrolling: touch, which would make it scroll more naturally in its current state.-
-
It feels a lot better now! Another problem, however, is that Safari’s bottom bar obscures the bottom of the page – for example, the submit button on the contact form. If you wait a second at the bottom and try to scroll again, you can reveal it, but it feels a little wonky. If you don’t want to redo the scrolling mehanism, a simple solution might be to just add a small margin at the bottom?
-
-
-
-
johnaj
3 months ago
|
link
| on:
Remote zero-click JavaScript code execution on signal desktop message app
I love Signal, but I don’t always like the tone that the Signal developers have in GitHub issue discussions. No information about whether the bugs apply to Signal, whether they have been fixed or even looked at … and then they just lock the issue, without comment. There might be a good reason, but it doesn’t look great.
Glad to know that this vulnerability has been fixed, though. They’re certainly doing something right :-)
-
-
My personal issues with JavaScript are not with the language itself, but with the fact that a language with which people can do some pretty user-hostile things is automatically executed by my web browser.
99% of the time, I’d settle with a small set of declarative additions to HTML and CSS that would make it possible to build more dynamic webpages, but without any all-purpose imperative language. At the least, it would prevent all JavaScript-aided privacy invasions.
-
99% of the time, I’d settle with a small set of declarative additions to HTML and CSS that would make it possible to build more dynamic webpages, but without any all-purpose imperative language.
My biggest philosophical problem with JS on the Web is that it’s all-or-nothing, rather than incremental. With HTML and CSS, new features can be added and old ones deprecated without too much breakage, and user agents (browsers, crawlers, screen readers, format converters, etc.) can build up incrementally; if some element or style isn’t expected/understood, we can just carry on with the rest and get a reasonable result.
On the other hand, JS comes as big blobs of text and any problem (from programmer error, some feature/API not being present, etc.) causes the whole thing to abort. This is usually worked around by doing almost everything in event handlers, e.g. attached to page load; that way, only the individual handlers crash. Yet this (a) requires manual effort and (b) is very coarse grained.
I think a much nicer approach would be to first make the code’s structure more explicit, rather than relying so heavily on implicit sequencing of effects (my preference would be for s-expressions, but whatever). Second, evaluation would work by rewriting sub-expressions which match known rules; e.g.
(when true x)would becomex,(when false x)would get removed, etc. Interaction, events, etc. could be implemented by “stuck” expressions, e.g.(when (buttonClicked) foo), which can’t be evaluated since we don’t know what(buttonClicked)is; when the button’s clicked,(buttonClicked)gets replaced withtrueand the “handler” gets evaluated. This way, unknown/unexpected expressions would just get ignored, since as far as the interpreter’s concerned they’re just “stuck” (since they match no known rules); evaluation would just carry on with the rest of the structure, including inside those unknown constructs (just like HTML renderers treat unknown elements).I haven’t fleshed this idea out much, but I think such a model feels more “Web-like” than e.g. imperative DOM operations.
-
Interesting ideas! My personal ideas revolve around extending CSS to allow conditional rules and extending HTML with a declarative interface for remote requests. My writings about it were posted here on Lobste.rs a while back, if you’re interested.
-
-
-
Nowadays, I mostly use Windows, but a while back, I was really deep into the Emacs ecosystem, to the point where I considered using it as my window manager. And it was wonderful! If only my operating system were as programmable and discoverable as my text editor.
-
-
No, it’s for a bunch of reasons. Part of it is software that exists nowhere else, like modern PC games. Part of it is the fact that I have Windows 10 Education for free via university, meaning I can disable telemetry :-)
Emacs itself actually works great under the Windows Subsystem for Linux. The only problem I’ve encountered is that magit is slower than on Linux.
-
-
-
This article is wild, and I will need to come back to it to fully appreciate it.
That said, I wonder if dynamic http requests are worth saving. The web is passably-good at serving static HTML, and everything else arguably really shouldn’t be done at all. Javascript is a hack inside a hack inside a hack, which, when used to exploit holes in the specification of HTTP, can be forced to slowly simulate a dynamic interactive UI inside a rich text viewer. It’s like playing Doom by fax machine: it’s cool that it’s possible, but if everybody starts doing it, it quickly becomes horrifying.
-
Hi! I’m the author of the article, but I didn’t see it posted here until recently.
Great points! In an ideal world, I’d agree with you, but I don’t think it is possible to change the way the web is used (even Lobste.rs falls under the “hack” category, as it’s more than a static document). It’s simply too useful. What we can do is change the technology behind it. It’s an area where I personally think declarative programming would really shine.
-
-
-
Last year, ST didn’t support ligatures, and I wanted to try them out. So I went off and used first Atom and then VS Code for a month or two. Best thing I can say about either is that they have quite a vibrant plugin ecosystem. When I decided that code ligatures were actually kind of a dumb idea (and definitely not worth the Electron bloat, MS spyware, and assorted rough edges), I came back to ST3 with new appreciation for its relative simplicity, stability and performance. Now, I see ligature support added in 3.1: ain’t that always the way?
Along the way I met my new favorite console editor, vis. Perhaps someday it will replace my GUI editor entirely.
-
Have you looked at Kakoune? I switched from vis to Kakoune a few months ago; I found Kakoune’s editing commands easier to learn than vis’ structural-regular-expression syntax, and I prefer the way Kakoune supports multiple editor windows that I can manage with my normal window manager, over vis’ (and Vim’s) window-splitting system.
In my spare time I’m working on a GTK+ based front-end for Kakoune, at least partially because I wanted code ligature support in my editor. :)
-
In my spare time I’m working on a GTK+ based front-end for Kakoune, at least partially because I wanted code ligature support in my editor. :)
That sounds like something I’d be interested in. Is there a repository online?
I really like Kakoune. My only problem with it is that it’s missing a good solution for hard word wrapping (like Vin’s gwip or Emacs’ M-q).
-
It’s still quite a work-in-progress, but feel free take a look.
Kakoune does have an “autowrap” plugin that will automatically press Enter for you as you type, but it’s a bit quirky. Currently, I have the following in my
kakrc:# Map the equals key to hard-wrap the selection map global normal = '|par -w$kak_opt_autowrap_column<ret>'Then, re-wrapping the current paragraph is
<a-a>p=. With a bit of effort, you could probably wrap that into an insert-mode mapping for<a-q>. par is a fairly smart third-party rewrapping tool, smarter than coreutils’fmt, but not quite as smart as Vim’s built-in formatting feature.
-
-
-
I said this on HN, but I’ll repeat it here: I don’t think built-in complex data parsing is smart. Leave dates, email addresses, urls, colors, and latitude and longitude (!) to the devs, or maybe move it to a plugin. But including it opens you up to endlessly having to fix something that is orthogonal to your goal: a structured, plain-text notation language.
Also, don’t validate email addresses or urls with regex, please. Most of these examples on Wikipedia don’t work with your regex, and a fair number of the invalid ones do. Just check for a
@and move on if you must.Quoting the creator on Hacker News:
I think this actually strikes a nice balance between “smart” and “dumb”. I agree wholeheartedly about the e-mail address regex, though.
Yeah, I’m glad it’s not magical, but it still feels weird to have them encoded in the current “core” parsers. How is converting a normal string of numbers to a dictionary different than calling “parse_lat_long”? Sure, you get the error message, but there are also instances when you don’t need 6 points of precision which invalidates the whole function. Just make it easily extensible and let users define their own.
Yeah, I agree.
Your point got through loud and clear and I will consider it closely, as all are :) thanks again for bringing it up!
Just in case you haven’t seen it already, here’s my response on HN that at least should explain why I put in non-thoroughly engineered type loaders (even though I myself highly regard thoroughness) https://news.ycombinator.com/item?id=17777113