Ok. Let's address your points one-by-one. 1. Tables are ok to display but what do you do when you have to display responsive data? Resort to JS to calculate offsets instead of using flexbox? 2. Do you think that we should use HTML forms too? It can do some things but if a person is building a SPA then it's best to not lean onto HTML. 3. I tend to avoid writing CSS and instead resort to CSS framework that has some things covered for me. They're trying to be modular by design. Do you think that using one is a good idea? This point sounds like you try to invent your own framework.

What do you mean by "responsive data"?

I don't remember who but somebody told me to not use tables to make webpage grid layouts. I prefer to use less tools and flexbox allows to be maximally flexible (wrap some elements or position them without calculating pixels). I'm not a front-end guy but I think that tables shouldn't be used at all except if they're really small (5x5 or something). So maybe you found a good thing for tables -- easy and copy-able. But if they screw up layout then it's not a good tradeoff.

Page layouts != data tables. Flexbox has its limitations that make it less suitable for data display, so it's not a strictly better tool. Different things for different purposes. > I'm not a front-end guy but I think that tables shouldn't be used at all except if they're really small This is plain wrong when tables are used for plain data.

> if a person is building a SPA then it's best to not lean onto HTML. This is also wrong. It all depend on what exactly you're building. It being an SPA is completely irrelevant. E.g. you still can (and should, to ensure compatibility with other tools such as screen readers and autofilling extensions/apps) use HTML forms in an SPA - you just prevent the default handling of its submit event to avoid page refresh.

HTML is a lot more expressive than people give it credit for, and I think a lot of people miss how capable it is because the popularity of static website generators and CMSes means Markdown is often the way people "write" HTML, and Markdown exposes an extremely limited subset of HTML's features.

https://html.energy/

It's also relatively easy to understand and tweak yourself even for non-programmers once you understand it a bit, as evidenced by the delightfully amateurish self-authored web design of the early 2000s which has been slowly replaced by an endless procession of blue, white, and gray rectangles because we convinced everyone that writing websites is too complicated to be left to non-professionals and the web ossified around what software engineers think is good instead The fact that linktree exists is a total indictment of the way the web has gone, an entire "platform" for the sole purpose of letting you collect and update a list of links to things

I'd say it depends. The users that copy/paste data in/out are probably business. So that's a business app. Then it means it does not need to look good, but has to work well and be flexible. For more end-user stuff, you might benefit from things looking nicer, while being less flexible.

What became painfully obvious for me lately is that if you use scss (“sass”) because you don’t understand css, you can end up with very hairy selectors. If the only thing you had was plain-old css, they would stick out much more.

Checkout "classless css" libs too

I want to address some of the concerns and inputs: Tables: I'm not advocating for controlling the overall layout with tables. Grid and flexbox are more suitable for that. The keyword here is "data". Tables are the most structured way to display it, which is why interop with other applications is so seamless. If your data isn't table structured there are better options. Tables are also generally responsive enough. They are best used in desktop views (mouse and keyboard, large screen). For small screens one can either compress the table or resort to other elements. The more lightweight and open/dynamic element is the description list (dl/dt/dd tags). I'm not aware of any interop with those (anyone?), but I use them regularly when I want more control over the layout. If your data is (or can be) table structured, use tables! Forms: HTML forms are another great example of something you can lean into heavily. Even when writing SPAs. Note that: • React lets you use "uncontrolled" forms. You can lean into the standard events to dispatch state changes. • FormData just works • form elements have native validation that can easily be extended (customvalidity), interop with CSS included, accessible by default • native input types interop very nicely with the OS, including mobile and are accessible by default. • form elements can be left empty (without children), input elements can refer to which form they belong via the form attribute, which lets you lay them out freely (think: upload form inputs, search etc. embedded into a larger form screen etc.) • lightweight "SPA/Ajax" libraries like htmx lean heavily into forms by default and extend them with more HTTP verbs (it's a shame that this isn't standardized yet...) CSS: I use CSS frameworks and preprocessors too. But plain CSS has gotten so much better than I plan to ditch SCSS in the near future when CSS nesting is done. Heavily nesting CSS selectors is a recipe for creating a mess, but not having nesting at all can be quite cumbersome too. Component based CSS frameworks like, SemanticUI, Bulma, (MUI) and Bootstrap etc. are nice and convenient if you don't implement a bespoke design. Otherwise: huge PITA. They are like the ORMs of frontend development. If you stay within their happy path: good, otherwise: run! Tailwind is great to encode a design system and move from there. Also the default config is well thought out so it can be used instead of component based frameworks. But ultimately, if you lean heavily into the CSS cascade (and use a little preprocessing for nesting selectors) you can "invent your own framework" just fine for bespoke designs but without the friction that a framework imposes.

#C04V4LQF6V7 might be of interest, it embeds the Small Clojure Interpreter into emacs as a native-compiled module so it can evaluate Clojure code

thanks for recommendation!

with Elisp approaching the 50 year mark, I wouldn't be too afraid 😄 lately GPT is helping me with some Elisping (even though I've written my fair share - 1000+ commits over 10y), it smooths out the occasional time-wasters like figuring out a regex.

not an interpreter, but a compiler: https://github.com/borkdude/clj2el at this point just a toy project