5 ms·

Some of these responses… wow. Using modern HTML and CSS will get you pretty far these days. For example, dealing with forms used to be problematic in a few di

• _boffin_ 4y ago
  agreed. it's amazing. Actually just wrote a site a few days back only using HTML, CSS. It's a simple site, but still looks good with only a few hundred lines of CSS. peeps are nuts for thinking that you need javascript and bells and whistles. I did miss SCSS though.
• zoover2020 4y ago
  For personal projects, sure. But good luck writing a medium to large sized app, full of business logic in Vanilla JS. The hate for JS frameworks is usually warranted, in this case I think nuance is missing. It's also not as black and white as people paint it to be, IMO.
  • atoav 4y ago
    In the professional projects I have done the majority would have been possible to do with HTML/CSS/JS. The only reason not do that was that customers typically need some sort of backend and that was back then just simpler to do by other means. But there is quite some projects where you don't even need that. Learning HTML/CSS/JS is a good idea as ultimately any framework or serverside code will interact with some combination of the three. Having a strong grasp of how HTML/CSS/JS work is the perfect foundation for learning something that runs serverside. And you get there by building projects that predominantly lean on the three. Whether they are private or professional, who cares as long as they are cool and someone learns something from it?
  • simion314 4y ago
    My problem is with "magic" frameworks. For example angular hello worls is super duper simple. But then business apps become a giant pile of crap, the eprformance goes to shit and sometimes stuff that should work stops working. The issue is the magic, if use a sane library you can just run the code in debugger step by step and see what happens but with magic stuff you get a giant call stack with garbage that is impoosible to understand. So when I can I rip out magic and replace it with function calls , getters and setters. Maybe is my bad luck that I always have to work on prtojects created by others and all the time this others did it wrong. Nobody can convince me that angularjs1 is a framework designed by competent people with experience in GUIs, maybe the newer version are better if those buys learned on the job what they should have known from the beginning.
    • agentwiggles 4y ago
      Do you feel React is overly magical? React was the first of these web frameworks that I was exposed to. I didn't have a ton of vanilla html/css/js experience when I first encountered React, but the fact that each component just returns some HTML is pretty unmagical to me. You could conceivably just use React (or, JSX really) to organize your app code in a pretty comprehensible way. I guess once you get into all the hooks and contexts and fancier stuff things might start to be a bit magical. But I like it a lot better than Angular, which I agree is very much overly magicked.
  • whostolemyhat 4y ago
    > The hate for JS frameworks is usually warranted It's almost never warranted.
    • mcread 4y ago
      So true, and hating JS is still a dogma that everyone has to assume ..
      • brigandish 4y ago
        You're suggesting that most of those that hate Javascript do so because someone told them they should and not because they've used it? From[1]: > In 2008 Crockford published a book announcing his discovery that Javascript, contrary to prevailing opinion, has good parts. He describes this as "heresy", and as "possibly the first important discovery of the 21st century", noting that it came as a "great surprise to the community of javascript developers, and to the world at large." He attributes the discovery to his having read the ECMAScript Standard, which he says "literally changed my life." He also notes that the specification document is of "extremely poor quality", "hard to read", "hard to understand", and says that the ECMA and the TC39 committee "should be deeply embarrassed". I own that book and I still hate Javascript (it's not the fault of the book). Is there another language with such a book? [1] https://en.wikipedia.org/wiki/Douglas_crockford#Opinions_on_Javascript https://en.wikipedia.org/wiki/Douglas_crockford#Opinions_on_...
        • achenet 4y ago
          C++ I think gets similar hate. Perl maybe, if you end up having to re-read some.
          • brigandish 4y ago
            I've definitely written Perl that someone has cursed at. Probably me!
        • hutzlibu 4y ago
          Well why do you hate javascript? There are many languages that I do not like, but I hate none, so I am curious for the reasons of that strong feeling?
  • austin-cheney 4y ago
    Done: https://github.com/prettydiff/share-file-systems https://github.com/prettydiff/share-file-systems The hate for large frameworks is warranted by their poor performance and bloat while struggling to achieve simple objectives in the most challenging ways.
• alwillis 4y ago
  For layout/design, there’s open props [1]. I like the MDN for quick reference but the actual HTML spec is actually quite well written and has lots of useful examples [2]. [1]: https://open-props.style/ https://open-props.style/ [2]: https://html.spec.whatwg.org/ https://html.spec.whatwg.org/
  • chrismorgan 4y ago
    I don’t like Open Props on technical grounds: it’s pointlessly inefficient, largely an abuse of Custom Properties, to my mind, shipping a completely superfluous layer of indirection to every client, rather than flattening almost all of the properties at compile time as could and should be done. If you’re using something like Sass, you’d use variables for this sort of thing except where you do want to change values dynamically (e.g. different values in light/dark mode). Using Custom Properties for everything is just wasteful if you’re not going to have anything subsequently using the definitions themselves. As an example, on their site, they’re sending about 68/12KB gzipped of styles. Some are already unused and could be removed by straightforward dead code removal. Inlining variables that are set only once and removing their definitions (which incidentally encompasses that dead code removal) reduces it to 40/8KB which will both transfer and evaluate faster. (A further 20% of the styles are also unused and possibly sanely removable.)
  • sdze 4y ago
    Number 1 lags when scrolling on a 2018 MacBook Pro. Not a good advertisement of a product.
    • everythingabili 4y ago
      [2] crashed Chrome 3 times. Mac Monterey.
    • shadeslayer_ 4y ago
      Lags while scrolling on a 2021 MBP as well.
    • aaaaarg 4y ago
      hmmm it's good in my 12+ year old laptop in firefox.
• ZephyrBlu 4y ago
  Netlify forms seems like the perfect product for OP.
• staz 4y ago
  `has()` for form validation really looked interesting but then I saw on their first example in your link that it is not supported in Firefox https://caniuse.com/css-has https://caniuse.com/css-has
  • alwillis 4y ago
    Even without Firefox support, :has() is supported by about 83% of web users, which is pretty good considering it first shipped 8 months ago.
  • TeMPOraL 4y ago
    I dream that one of these days, CSS will get a selector similar to `has()`, but that can target text content, not the structure. E.g. I want to be able to write something like: article a :has_("click here ") to select elements that are otherwise hard or impossible to target. Of course, I don't want to use it on the websites - I want it for userstyles, so I can swiftly and efficiently deal with the insanely bad UX of most of webpages, despite their authors making it hard to fix (often on purpose). That, and I'd like some way to punch through shadow DOM, because as far as I can tell, elements in the shadow DOM cannot be addressed by userstyles at all, which prevents me from fixing annoyances in some webapps (looking at you, Gerrit).
    • zzo38computer 4y ago
      My idea of a better web browser design is some CSS commands which are only available for user styles, including these features (text content, shadow DOM, etc; although, such things might also be useful even if not restricted to user styles) and some others, such as more control over priority, and overriding the meaning of other CSS commands (which are restricted to only being allowed in user styles).
    • chrismorgan 4y ago
      In some contexts, which includes JavaScript and thus user styles, you can use XPath, which interacts with all nodes, not just element nodes like CSS. Your sample selector would be this, if I have understood your intention correctly¹ (that you’re targeting the <a> element, and don’t care if the text “click here ” is an immediate child, or spread across multiple children): //article//a[contains(., "click here ")] The equivalent to document.querySelector in JavaScript: document.evaluate( '//article//a[contains(., "click here ")]', document, null, XPathResult.FIRST_ORDERED_NODE_TYPE, null, ).singleNodeValue And the document.querySelectorAll (which returns a static node list) equivalent would use ORDERED_NODE_SNAPSHOT_TYPE, with .snapshotLength and .snapshotItem(index) on the result object. Yes, this API is written in a very old style, and could do with being wrapped in a more pleasant API. See https://www.w3.org/TR/1999/REC-xpath-19991116/ https://www.w3.org/TR/1999/REC-xpath-19991116/ for the syntax, and https://developer.mozilla.org/en-US/docs/Web/API/Document/evaluate https://developer.mozilla.org/en-US/docs/Web/API/Document/ev... for document.evaluate(). You will sadly not find a great deal of other useful documentation. As for shadow DOM: yeah, you can’t target closed shadow DOMs at all in any way, by design. Fortunately most are open so that it is at least possible to get into them, even if it’s a pain since the normal tools can’t pierce the boundary. —⁂— ¹ If you wanted to only match “click here ” in an immediate child text node of the <a> element, these four work and are equivalent: //article//a[./text()[contains(., "click here ")]] //article//a[text()[contains(., "click here ")]] //article//a[contains(./text(), "click here ")] //article//a[contains(text(), "click here ")] These will be more efficient than the first-used selector. Where CSS is mostly unaffected by selector complexity because it largely evaluates from right to left, XPath is more likely to be doing full traversals, which will benefit from more specific selectors, hence things like prefixing paths with /html/body, or only evaluating in document.body, in order to skip traversing the head altogether, if that will never match; and you can easily imagine that contains(//a/text(), "…"), which selects text nodes that are children of <a> elements and thus has selected nodes that have a trivial string-value, will be faster than contains(//a, "…"), which will need to stringify every <a> element, entailing further traversal and string construction. Mind you, the differences in all this will mostly be very small in practical terms.
• cxr 4y ago
  > Some of these responses… wow. It's pretty amazing, HNers' capacity to read a request that includes a clear, concise (and satisfiable) requirement—no frameworks—and then dozens of respondents write up answers predicated on the use of this or that framework, thus contradicting the entire premise for the question.
  • pipeline_peak 4y ago
    People just love to talk about their favorite stuff... They have the right to post it, but I also have the right to ignore their suggestions
    • aussiesnack 4y ago
      It can be pretty tiresome and there are some topics I just never bother reading because they are inevitably full of humanbot autoresponses. Anything to do with note or mail apps, for example, will be just packed with readers taking their own particular dog for a walk, regardless of its relevance to the topic at hand. Pub bores, the lot of them.
  • alwillis 4y ago
    Exactly.