321–330 of 458 posts
Earlier quoted context omitted.
I don't think people realize how CSS3 and HTML5 will do everything they need. And also that no one actually enjoys using a SPA.
That would require accepting that the complexity merchants sold them a lie.
I have never heard of this term before. But I do think it is quite apt. Is this an established concept (can I read more about it somewhere)? Or did you come up with it on the fly?
I don't want to totally neg on web dev. But it does suck donkey balls. I've been doing it for years. From writing raw html,to using scripting langs, frameworks and what not. And the amount of time it takes to do not a lot I figure is just a colossal brain drain. We just went on holiday, and all I wanted to do was look up places to go eat and drink, or visit for the day, and most of the sites sucked. Or were out of da…
Because of this I don't bet on the web because it's really designed to be an app framework now (admittedly the best one) not for being a simple client that sends and receives data (like XMPP, SIP, IRC, SMTP, IMAP and NNTP).
I really want to believe in the semantic web, I really want to believe in the ability of the browser to provide me with good default modules with a good default styling, but for now I just have to accept this is not the case. The fact that I have to think about labeling a input (why is this not an attribute ?), not being sure if I should use it as a wrapper of as a sibling with the `for=` attribute... and this is jus…
(I don't know what tools you use so this isn't a comment directed at you specifically) If web developers spent a fraction of the time required to learn react, tailwind, etc on learning HTML the web would be in a much better spot. There are definitely quirks and rough edges, but if every web devs knew how to get the most out of semantic HTML we'd likely have a lot less JS in the browser, fewer accessibility bugs, and…
For any real application that software engineers are hired to work on, "learning HTML" would do very little. Most high-level front-end engineers do know HTML. There's not that much to know.
The web today is basically a universal desktop client. Apps like Figma, Slack, Airtable, and thousands of others are not really websites, they're hosted applications that have a mind boggling amount of interactivity.
Earlier quoted context omitted.
This is why you wouldn't build "two entirely different versions of the same site", you'd build one version and toggle the tag on and off.
That may not work for a lot of sites that depend on client rendering and don't server-render the full page content Its really easy for this to break and go unnoticed for a while as well. You could run tests against the static version, but I wouldn't be surprised at all to see them "temporarily" disabled because a new feature needs to go live and something is the breaking in the static tests
Products that depend on client-side rendering don't deserve to have regression-free experiences. You are literally doing layout with javascript and wondering why things get funny on edge case clients.
The web is fucked until it becomes truly popular to build vanilla, SSR applications again. I feel like we are almost at the end of the tunnel of client-side hell, but perhaps some aggressive final pushes could help ship the narrative.
The server is fast. Stop doing your layout on the client. Use media queries to address the wide range of viewport dimensions. You can have a responsive website, installable as a PWA on home screen of any mobile device and also as a 4k detailed desktop layout with 0 lines of JS required. All you have to do is stop outsourcing your independence to framework vendors and pick up the MDN bible.
Earlier quoted context omitted.
JS does not 'just work'. This is why a lot of these custom components have bad touch interaction and no accessibility. Take the datepicker; the native mobile version works great, why annoy users with a custom component?
why annoy users with a custom component Because a system you’re developing may have specialized modes. There’s no “today”, “yesterday” or “last week” or “q3” and other suitable shortcuts in standard date/period peekers. Another method is to use a text field which parses itself into a date or a period. E.g. “2-5” means (and/or expands into) 2023-08-02..2023-08-05. “May” means 2023-05-{01..31}. And so on. My users alwa…
The way I see it, so much of the web is a clunky mess precisely because software development today pretends to be engineering while simultaneously being about the bottom-line and little else. No doubt, a great date picker could be developed in JavaScript that would serve everyone's needs, be totally accessible, and not a bowl if soup. So why don't we do it? Why are what should be basic HTML forms on corporate websites difficult to navigate or in some cases fundamentally broken, requiring workarounds? Nobody is interested because solving real problems doesn't carry any of the prestige of building another framework. Who wants to build a date picker that is standards compliant when you could write another web framework, bro? Even if a developer is not trying to build the next React, they're probably spending more time on their toolchain than actually coding. It's gotten so bad that seemingly every company I've joined in the last 6 years needs a bunch of people dedicated to maintaining toolchain and CI crap for the rest of the team.
I love programming, but the web needs to get its head out of its own ass. We're acting like our jobs are more important than the value the software delivers, and more effort is being put into making sites impractical for machines to parse (because muh intellectual properteh!) than in making web components that aren't riddled with bugs.
Earlier quoted context omitted.
I don't think people realize how CSS3 and HTML5 will do everything they need. And also that no one actually enjoys using a SPA.
CSS3 and HTML5 are not meaningful semantic version numbers anymore and haven’t been for over a decade. Both CSS and HTML are considered “living standards” now and no longer use version numbers: https://html.spec.whatwg.org/multipage/introduction.html#is-... ? Nesting in CSS became broadly supported in Chromium and other evergreen browsers a few months ago. This is a feature that developers have had to use inside of s…
Firefox hasn’t shipped it yet. https://caniuse.com/css-nesting shows it landing in 117 next month.
> Even now, it’s not supported by older versions of iOS/mobile Safari which could easily be 15-20% of a large US based websites’ traffic.
Yeah, actual global support is probably still below ⅔—caniuse.com is showing global support at 72.89%, and its methodology is hopelessly broken for mobile browsers (treats all mobile Chrome/Android WebView as the latest version, which is wildly wrong), quite apart from excluding browsers that block the StatCounter script, leading to particularly heavy undercounting of Firefox and general undercounting of more conservative or unusual configurations; so the true numbers on newish features are always much worse than it suggests.
For these sorts of features, if all browsers ship around the same time, you’ll normally want to wait for about another two years before you start depending on it. (When shipped out of sync, it depends—you’ll encounter two-year-old Safari more commonly than six-month-old desktop Chrome, for example.)
Earlier quoted context omitted.
(I don't know what tools you use so this isn't a comment directed at you specifically) If web developers spent a fraction of the time required to learn react, tailwind, etc on learning HTML the web would be in a much better spot. There are definitely quirks and rough edges, but if every web devs knew how to get the most out of semantic HTML we'd likely have a lot less JS in the browser, fewer accessibility bugs, and…
> on learning HTML Anecdote. Was recently freelancing at a web-agency. They build complex web-apps. Lot's of senior and experienced web-devs there: react, mui, typescript, tailwind, and a large host of backend frameworks under the belt. But when I built a quick PoC using ` ` a few lines of JS and some of the elements used in the article (meter, dialog, details) they were flabbergasted. This was a whole team of experi…
These are the people rejecting your job application.
I really want to believe in the semantic web, I really want to believe in the ability of the browser to provide me with good default modules with a good default styling, but for now I just have to accept this is not the case. The fact that I have to think about labeling a input (why is this not an attribute ?), not being sure if I should use it as a wrapper of as a sibling with the `for=` attribute... and this is jus…
For what it's worth, I've found that I almost always want to put the label tag after the input tag. That enables me to select and style the label based on the input state via CSS pseudoclasses.
Earlier quoted context omitted.
>Take the [HTML] datepicker * Lets you enter nonexistent dates like 31/2 * Can and often does accidentally place the user in American-style MM/DD format where it should be European-style DD/MM (I have a replicable case now on that page example). * No ability to force date style by design. So there's no way to fix the above from the server, or to use ISO-style dates. Only way to reliably prevent MM/DD by default is to…
> ...place the user in American-style MM/DD... > No ability to force date style by design. There is datetime-local, date, and time. And there's a lot of control over what is allowed with min-max ranges, steps, etc. The only thing I can imagine to go wrong here, is when a user has their browser set in US-en but when they are not aware of that. Which seems... weird; or at least not a problem a web-dev should solve. > L…
LC_TIME does not work very well with most apps.
And there is a big difference between just throwing an error if a date-time cannot be parsed because of a nonextent date, and communicating it to the user in a nice way, especially without using JS.
Earlier quoted context omitted.
Original Text Grammar checkers are essentially typo checkers and are not context aware to be truly grammar checkers. Context aware grammar checking means the program has to consider each line of text and identify grammar mistakes. As traditional grammar checkers check typos in real time, every mistake you do is flashed in front of you. You have to stop evaluate, fix and continue. This is distracting. My solution is t…
> As traditional grammar checkers check typos in real time, every mistake you do is flashed in front of you. You have to stop evaluate, fix and continue. This is distracting. Or you can disable that feature (or the software entirely) and do a full pass at the end. You’re not forced to do live checking. > Please feel free to give this method a shot for a week. No, thank you. I have no desire to send what I write to th…