Follow

Reminder: if you don't use JavaScript, you don't get crashes. And don't need loading screens.

I'm liking this post: dev.to/winduptoy/a-javascript-

And he's got a list of things he wants to be able to do without JS. discuss?

"1. Why can't we have a standard search element that filters a list on the client side (similar to how ng-repeat | filter: worked on Angular)?
2. Wouldn't a standard HTML element for drag-and-drop sorting be awesome?
3. More advanced validation functionality, like comparing equality of two different form fields.
4. The ability to do the modal/checkbox trick above without it feeling like a hack and writing weird CSS."

@alcinnz I've felt for a while that most webapps could be implemented with <form> and reasonable CSS, if that. Client-side scripting is way overused.

@alcinnz Basically what you need for 4 is the ability for an element to toggle the hidden attribute on another element. Maybe a 'shows' and/or 'hides' attribute?

@alexbuzzbee I'd add that I think modals have become a useful and dominant enough UI pattern on The Web (particularly in the form of "lightboxes") that I believe they should be native to HTML.

Maybe there's an attribute on links and buttons for that. Which could also set a side of this element to place it on, or maybe even pull in entire webpages for UIs like Stripe or OpenStack Horizon.

@alcinnz Perhaps add a 'modal' attribute to <button> that opens a modal document iframe-style? Or perhaps a modal element which is given by id?

@alcinnz
Actually, there is already an element for dialogs, lightboxes and modals, but it's still not supported everywhere (ex. It doesn't work on Firefox for android)
<dialog>
developer.mozilla.org/en-US/do
@alexbuzzbee

@ranfdev @alexbuzzbee From what I can tell from that page, this doesn't fully answer the need: how do you open the dialog without JS? But it would be useful to encourage using this element alongside what we were discussing.

@alcinnz
You still need a bit of js to toggle the open attribute of the <dialog>, but at least it should be more accessible than a custom modal.
Maybe they could add a way to connect the value of an attribute (like open="true") to a checkbox's state
@alexbuzzbee

@alcinnz @alexbuzzbee @ranfdev there's nothing wrong with using js, just that some developers are evil.

@tleydxdy I won't shame anyone for using JavaScript, it's the tool we have now.

But I don't think it should have ever been a part of the web. All our standards should have remained declarative for the sake of user-control, accessibility, and ease of authorship. Not to mention security in the face of vulnerabilities like Spectre.

Just so you know where I'm coming from.

@tleydxdy As for the author of the blogpost which this discussion is centered around, he's enjoying stripping out all the JavaScript which was slowing down his service and making it more fragile. And he wishes he could strip out more.

@alcinnz my opinion is that HTML should represent something static and simple, it defines how a page's format. Handling logic using another language (js) is the right choice. The problem that js now causes, is because people are evil, and they'll find a way no matter what. Just look at web assembly, at least you can only obfuscate js.

@tleydxdy I'm confident they wouldn't find a way if we didn't give them Turing Completeness. Which yes, requires great care.

But yes it is worth considering whether creating another language is appropriate for the tasks he (or anyone else) cites. And in the case of triggering modal dialogs to show, it looks to me like just a different presentation of link traversal.

@alcinnz I'm not really talking about the turing completeness of js. but I meant it is just as easy to let people install a plug-in that does what they want, and once it got popular, web browsers will have to include them. btw PowerPoint with links and animation is turing complete.

@tleydxdy Yes, avoiding Turing Completeness can be difficult. And yes, other measures would be necessary to achieve widespread privacy.

But I do wish to explore route of replacing JavaScript. Think of the worthwhileness of that what you will.

@tleydxdy @alcinnz @alexbuzzbee @ranfdev There *is* something wrong with using JS [in documents like HTML] although sometimes we don't have a better choice. As an end-user, allowing Web-wide open Javascript means allowing arbitrary remote code execution [with some limits, but still]. JS, being imperative, not only allows for evil but even makes it difficult to detect. If we ever had a <cryptominer> HTML tag it woukd be easily blocked too.

@alvarezp How is this related to JavaScript being imperative? If we had a declarative language in every web browser, I don't see how things would be any different.

@awe @alvarezp What defines an imperative language is that you're specifying WHAT you want the browser to do, not HOW to do it. Thereby allowing the browser to decide the HOW, or even IF, itself.

@alvarezp Say that web browsers all had their own special Web version of Prolog. We would still be in exactly the same boat with arbitrary remote code execution. The issue isn't whether the language is declarative or imperative, it's fundamentally that we're, by default, downloading and executing whatever program someone asks us to, and that program can do whatever it wants. That is, what matters is the language's expressivity and API surface, not the programming style.

@awe What terms would you use? Can't say "the problem is that JS is code" because HTML and CSS are also code. Can't say "the problem is executable code" because JS is interpreted, not executed. Nitpicking will always find a flaw. That's why I provided an example: a computer can identify and block a hypothetical <cryptominer> tag easily but can't identify if a piece of JS is a cryptominer or not as none of the individual instructions to cryptomine are actually malicious.

@alvarezp @awe I tend to say "Turing-complete", but that tends to sound overly technical even to technical people.

@alcinnz @awe That would be a better term but I read somewhere that CSS was recently proven to be turing-complete so I am also not sure.. Now that I looked at Prolog syntax, I probably should have not used the term "declarative". But the point remains. Have you seen the video about using JS in PDFs? Same principle. I don't have enough knowledge of formal languages and grammars to properly express myself.

@alvarezp @awe I looked into that, and the reality is CSS+HTML was kind-of proven Turing-Complete. The proof relies on humans doing exactly what the machine tells them, which I don't consider a serious threat. User input (specific clicks or key presses) was the clock signal.

Clever idea though!

@alcinnz @awe So, not by itself? That is good. In any case, CSS is much easier to audit and contain. Once I discussed in Twitter about JS and tracking and got the immediate the response: you can get tracked with CSS too. I saw a somewhat unreliable PoC involving CSS selectors for text input content and remote styling for different cases. But a browser can easily just retrieve all the listed CSS resources on page load.

@alvarezp @alcinnz It's worth saying that Turing-completeness is at some level a kind of naive view of the issue (and itself is also a very narrow way of talking about language expressivity). CSS might be "technically" Turing-complete (probably only when you include user interactions), but it's not actually as expressive as JavaScript (esp. including the APIs that are made available to JavaScript programs to interface with the browser).

@alcinnz @alvarezp I think a perfectly reasonable way of talking about the issue is simply as arbitrary code execution. The whole point of something like blocking a <bitcoinminer> tag or something would be that the tag is _not_ arbitrary code, but rather refers to a specific program with specific behavior. It's the restriction of the language to specific behaviors that makes things like HTML and CSS less problematic.

@alcinnz Yes! I like these proposals. I have gone myself through this when working with database-related frontends without JS and also came up with some needs:

1. A multi-column SELECT element.
2. A data grid. As opposed to tables, data grids can't span and allow sorting by columns.
3. Selecting the sort column for this hypothetical datagrid via URL, something like page.html?var=val#anchor##table1.sort=name,asc.
4. A "select all / deselect all" mechanism for forms.

@alcinnz the trick with `#myToggle:checked ~ #myToggledUI` was worth the read alone!

I don't think I can agree that it's "plain and simple" when you have to trick the UI into clicking that checkbox by abusing the `<label>` tag. But I really like it in principle, and I would love to see this formalized in a more intuitive way.

@alcinnz
Interesting read, thanks for sharing.

Remember the times when it was called unobtrusive javascript?
Somehow things have gone a bit downhill since then.

Sign in to participate in the conversation
FLOSS.social

FLOSS.social was launched on 1 April 2018 as a Mastodon instance for people who care about, support, or build Free, Libre, and Open Source Software (FLOSS). Of course, discussions aren't limited to just FLOSS -- let's share our unique interests! English is preferred for maximum conversation opportunities within the FLOSS community, but it is not required. Respect is required, however: Users on FLOSS.social agree to abide by the Contributor Covenant Code of Conduct. This service was installed and is maintained in part by Masto.Host with equipment located at OVH. You can support this instance financially through the Monthly Supporter Program, processed through CommitChange using the free software Houdini Project.