5 ms·

Agreed. I remember in 2012 we joked that if you used enough Javascript you could get the Web in 2012 up to the level that VisualBasic 1.0 offered back in 1991.

Agreed. I remember in 2012 we joked that if you used enough Javascript you could get the Web in 2012 up to the level that VisualBasic 1.0 offered back in 1991. But we were certain that in 10 years, by 2022, we'd up to the level offered by VisualBasic 6.0, which would have been amazing, because VisualBasic 6.0 had been amazing. I've been stunned by the lack of progress. The major browser companies/projects have largely stopped innovating. The period from 1993 to maybe 2010 or 2015 was very fluid, and HTML and CSS expanded quickly, but after a certain point the attitude seemed to be "We don't need to fix HTML because we can fix it with Javascript." Which is sort of true, but it is clunky. It would be much better to simply add more to HTML. At a minimum, every form element offered by VisualBasic should have eventually been added to HTML. What is the hold up? Why isn't this happening? It's shocking, but there are still no calendars in HTML. Every calendar has to be custom built with CSS and Javascript. You'd think in the year 2024 we'd have every possible time element added to HTML, with easy customization options. I'm baffled this hasn't happened yet. What will it take to get the major browser companies/projects to start adding more to HTML?

freeone3000 3y ago
Input type=“date” was added and is supported in HTML5, no js required. Same with time!
- crooked-v 3y ago
  ...which is great as long as you don't need a calendar on the page itself, or a calendar that shows two months instead of one, or a calendar where you can display information on dates or block selection of certain dates, or a calendar you can add any CSS styling to, or... you get the idea.
  - clipsy 3y ago
    What browser do you use? You can test `input type="date"` here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... -- I've tested every up-to-date browser I have on my laptop and phone and they all display a proper calendar-style date picker.
    - wild_egg 3y ago
      _date picker_, yes. Calendar display? No native options. The person you're replying to is talking about displaying event data to users which always requires building custom components or pulling in libraries which do
      - deleted 3y ago
        [deleted]
      - bombcar 3y ago
        Which is hilarious because it can display a calendar for date picking; but cannot display a calendar.
        smaudet 3y ago
        Likely because the element authors didn't want to overload the existing input semantics. You are talking about <calendar /> not <input type="date" />. Its the same semantic issue that lead to <button /> and <input type="button" />, with different functionality/support in different browser(s), and why we have auto-fill libraries that eventually became javascript component libraries, got rolled into development frameworks and turned into hyper-adware... Its "hilarious" but an "input" that does nothing but show an input calendar is arguably better. Otherwise, you're not writing (semantic) html, you're writing <insert ui framework>.
yen223 3y ago
> What is the hold up? Why isn't this happening? One of the problems, and arguably one of its strengths, with the modern web is that there's no single "entity" that owns everything. A large part of why this isn't happening is that there are too many parties involved in the web - browser implementers, standards maintainers, and web developers. If you want to introduce a new feature to the web standard, it's not enough to convince one browser implementer to add it - web devs can't use a feature that only one browser supports! You need to convince the standards body to adopt it, and to convince browser implementers (plural) to support it, and this takes a lot of time and coordination effort. In the case of Visual Basic, you just need to get some PM in Microsoft to add it, and it'll be added.
- actionfromafar 3y ago
  Is it Apple and Google?
marcus_holmes 3y ago
I think Web Components was seen as the fix for this; that (in the same way VB4 did) we'd have packages of standard components as building blocks for UIs. So rather than each browser implementing a calendar defined in HTML, you'd use a third-party library Web Component that implemented a calendar. Which is happening. You can get a Web Component calendar, and they mostly work. I just don't think it's taking off as "the way" for doing web UI (yet). This might change, I guess. But probably not. I think the big difference from the VB days is design. In the old days, we dev monkeys would design UIs by slapping together controls in a form. Which is why they all looked the same, and while they worked well they didn't exactly inspire. Now in Web Dev we have designers as the first step, and every designer designs their UI differently. You can't slap together a UI and call it done. Well, you can, and I do, but everyone thinks the result is ugly and needs a designer to make it usable - we've moved the bar of acceptable aesthetics to the point where this VB way of creating UIs doesn't work any more.
- smaudet 3y ago
  You hit the nail on the head (well, half) - design is an incredibly tricky problem. Mostly because it at its core is the process of adding constraints, and once you've added those its far harder to un-add them. That's why CSS was so janky for so long - there were design paradigms (tables, box model, flex box, etc) and once they were there, you hoped they worked and you hoped that your specific design didn't break one of its core assumptions, leading to large amounts of work-around code that was either slow or exhibited constant random bugs in different versions of browsers... The other half of the nail was backwards compatibility. Unfortunately you can't have web components and your stuff working on 20 year old devices. So any new design/paradigm etc. served to splinter the ecosystem (your stuff only works on this browser, that device, our operating system). Graceful degradation sort-of would have provided a work around, but it would have done so by shifting the workload onto the provider (please make sure your calendar works, in these browser, and also has fallback implementations as a clock that doesn't break your back-end code because they entered hours as farsi, test on on these 40 browsers and also target moving backends). So instead we invented polyfills as a way of "automatically" back-filling for a lot of stuff. Unfortunately, you can't do much about the Web Component calendar. The design paradigm that once existed doesn't support it without a lot of busy work, even if newer browsers could natively implement one and never load a line of javascript or any of your shitty thousand line long html layout code... I don't think its a completely lost cause, HTMX + Web Components seems like our best path forward so far. Right now, a lot of people who've written millions of lines in non-html frameworks like React and the like are very reluctant to give up their codebase(s), however terrible they might be. It is unfortunately, the result of someone somewhere making a design decision that added constraints, now causing headaches and difficulties un-adding those constraints...

freeone3000 3y ago

Input type=“date” was added and is supported in HTML5, no js required. Same with time!

crooked-v 3y ago
...which is great as long as you don't need a calendar on the page itself, or a calendar that shows two months instead of one, or a calendar where you can display information on dates or block selection of certain dates, or a calendar you can add any CSS styling to, or... you get the idea.
- clipsy 3y ago
  What browser do you use? You can test `input type="date"` here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... -- I've tested every up-to-date browser I have on my laptop and phone and they all display a proper calendar-style date picker.
  - wild_egg 3y ago
    _date picker_, yes. Calendar display? No native options. The person you're replying to is talking about displaying event data to users which always requires building custom components or pulling in libraries which do
    - deleted 3y ago
      [deleted]
    - bombcar 3y ago
      Which is hilarious because it can display a calendar for date picking; but cannot display a calendar.
      - smaudet 3y ago
        Likely because the element authors didn't want to overload the existing input semantics. You are talking about <calendar /> not <input type="date" />. Its the same semantic issue that lead to <button /> and <input type="button" />, with different functionality/support in different browser(s), and why we have auto-fill libraries that eventually became javascript component libraries, got rolled into development frameworks and turned into hyper-adware... Its "hilarious" but an "input" that does nothing but show an input calendar is arguably better. Otherwise, you're not writing (semantic) html, you're writing <insert ui framework>.

yen223 3y ago

> What is the hold up? Why isn't this happening? One of the problems, and arguably one of its strengths, with the modern web is that there's no single "entity" that owns everything. A large part of why this isn't happening is that there are too many parties involved in the web - browser implementers, standards maintainers, and web developers. If you want to introduce a new feature to the web standard, it's not enough to convince one browser implementer to add it - web devs can't use a feature that only one browser supports! You need to convince the standards body to adopt it, and to convince browser implementers (plural) to support it, and this takes a lot of time and coordination effort. In the case of Visual Basic, you just need to get some PM in Microsoft to add it, and it'll be added.

actionfromafar 3y ago
Is it Apple and Google?

marcus_holmes 3y ago

I think Web Components was seen as the fix for this; that (in the same way VB4 did) we'd have packages of standard components as building blocks for UIs. So rather than each browser implementing a calendar defined in HTML, you'd use a third-party library Web Component that implemented a calendar. Which is happening. You can get a Web Component calendar, and they mostly work. I just don't think it's taking off as "the way" for doing web UI (yet). This might change, I guess. But probably not. I think the big difference from the VB days is design. In the old days, we dev monkeys would design UIs by slapping together controls in a form. Which is why they all looked the same, and while they worked well they didn't exactly inspire. Now in Web Dev we have designers as the first step, and every designer designs their UI differently. You can't slap together a UI and call it done. Well, you can, and I do, but everyone thinks the result is ugly and needs a designer to make it usable - we've moved the bar of acceptable aesthetics to the point where this VB way of creating UIs doesn't work any more.

smaudet 3y ago
You hit the nail on the head (well, half) - design is an incredibly tricky problem. Mostly because it at its core is the process of adding constraints, and once you've added those its far harder to un-add them. That's why CSS was so janky for so long - there were design paradigms (tables, box model, flex box, etc) and once they were there, you hoped they worked and you hoped that your specific design didn't break one of its core assumptions, leading to large amounts of work-around code that was either slow or exhibited constant random bugs in different versions of browsers... The other half of the nail was backwards compatibility. Unfortunately you can't have web components and your stuff working on 20 year old devices. So any new design/paradigm etc. served to splinter the ecosystem (your stuff only works on this browser, that device, our operating system). Graceful degradation sort-of would have provided a work around, but it would have done so by shifting the workload onto the provider (please make sure your calendar works, in these browser, and also has fallback implementations as a clock that doesn't break your back-end code because they entered hours as farsi, test on on these 40 browsers and also target moving backends). So instead we invented polyfills as a way of "automatically" back-filling for a lot of stuff. Unfortunately, you can't do much about the Web Component calendar. The design paradigm that once existed doesn't support it without a lot of busy work, even if newer browsers could natively implement one and never load a line of javascript or any of your shitty thousand line long html layout code... I don't think its a completely lost cause, HTMX + Web Components seems like our best path forward so far. Right now, a lot of people who've written millions of lines in non-html frameworks like React and the like are very reluctant to give up their codebase(s), however terrible they might be. It is unfortunately, the result of someone somewhere making a design decision that added constraints, now causing headaches and difficulties un-adding those constraints...