• 2 Posts
  • 39 Comments
Joined 2 years ago
cake
Cake day: June 24th, 2023

help-circle
  • Don’t get me wrong, I’d always choose html over js if I could. My problem with css, and web in general, that it’s too fragmented. It’s like those people who are designing css, html, js and browsers didn’t speak to each other whatsoever. So now there is entire industry of js frameworks to glue all shit together. Like, look at the WebComponents. Which supposed to be native, out of the box replacement. So much effort and they still cannot compete, in some cases they simply do not provide basic features needed to build complex UIs. Next time I can choose stack I’ll probably just go with htmx



  • Don’t know about tailwind but I used styled-components and not going back to vanilla css. CSS seems to be designed to be used with HTML, which did make sense back when it was created. Modern web is 99% JS and components composition which does not work well with Vanilla CSS in terms of class name uniqueness, specificity. Also it easy to dumb shit with CSS, like, I worked in the project where we had a lot of legacy global CSS. We had like dozen CSS styles which were adding margin to <label/>, <p> and so on. I mean no classes, just globally. I’ve been forced to add ‘all: unset’ to basically all my new components just to avoid changing global styles and breaking something else. Do not recommend.









  • I feel like people are complaining about wrong thing. At least for me it’s not a problem that there are different communities. To me problem is same posts. What would be great is to have same posts merged into one post with comments from all its duplicates. This way communities are independent, lemmings don’t get to scroll same copy-pasta and discussion of same thing is visible cross communities/instances. Question is how we define “same” is it carbon copy of post, or same content only? Alternative titles can be shown if content is same but not title.











  • Lysergid@lemmy.mltoProgrammer Humor@programming.devLanguages
    link
    fedilink
    arrow-up
    5
    arrow-down
    1
    ·
    edit-2
    10 months ago

    Library built this way because it supposed to be flexible and provide ground for complex usecases. It can only be flexible if your API works with simple abstractions which you can then compose. It’s not driven by “I need this specific utility for this specific scenario”. That would be zoo you have in JS where you have 10 ways to iterate over array and 9 of them wrong for your scenario.

    Java’s OO is great because they design library with SRP in mind making sure there is few but good ways to do things.

    BufferedReader cannot accept file name because it makes arbitrary reader… well buffered. It’s not BufferedFileReader, even that would accept something like Path or File, not string, because File can be remote file, should Reader now know all possible local and remote protocols and path formats? What else it must do?

    Having it designed the way it is, allows Java to have utilities for various scenarios. Your scenario covered by standard lib too. See Files.readAllLines which, surprise-surprise, built on top of BufferedReader.