5 ms·

>I’ve hit a point where it just doesn’t seem like the end justifies the means in the vast majority of cases anymore I agree, but the only path forward is to ch

• throwaway0asd 4y ago
  State has nothing to do with the DOM. State is a data feature of your application which is not the DOM. It sounds like you are stuck in some inescapable framework mindset. If you can escape framework insanity state is an easily solved problem and the DOM stops being scary.
• dtx1 4y ago
  Finally someone is saying it openly. The Web is amazing, the softwarestack powering is horrible. Just imagine for a second we were to start from scratch. Imagine an HTML/CSS Spec thats easy enough to implement so that we have multiple independent vendors with competing, correct implementations. Imagine something like web assembly as the basis for scripting those HTML/CSS Engines. Imagine the amount of energy, developer time and bugs we could save with a sane, modern standard that implements all the lessons learned from what came before... One can dream...
• akrymski 4y ago
  I think what we need is a new spec that compiles down to whatever HTML/CSS/JS/WASM is supported by browsers over time. Waiting for browser vendors to agree on a new spec takes far too long. The same thing happens in all of comp-sci: we create a new programming language that compiles to an old language (C to Assembly) because changing the old one takes longer than inventing a new one.
  • dimmke 4y ago
    Ultimately, that's what all these different frameworks actually are though. Look at how many different languages over the years have compiled down to JS? CoffeeScript, TypeScript, Elm. And all the frameworks that have smoothed over the native DOM API: React, Angular, JQuery, too many to list. They all implement these concepts in Javascript. But if we don't standardize and allow browser vendors to implement at a lower level, we will always be taking a speed hit and on the framework treadmill. We need to take what we know works and do it.
    • akrymski 4y ago
      Sort of, but React is not a language. It's a runtime lib. JSX is not really helpful - still writing HTML and CSS. TypeScript has been very useful and successful but it hasn't touched the UI stuff. We need a better alternative to HTML and CSS. With WASM any language can now be compiled to run in the browser, and it's a matter of time until WASM integrates with the DOM as well. This isn't web specific. Desktop UI APIs change frequently too. UI is hard, and only higher level of abstractions can simplify things.
      • dimmke 4y ago
        >Sort of, but React is not a language. It's a runtime lib. JSX is not really helpful - still writing HTML and CSS. TypeScript has been very useful and successful but it hasn't touched the UI stuff. That's my point. The main thing that JSX does is address that you can't do conditional rendering or interpolation with HTML. It's the same with literally all of these other templating languages. Blade, Jade, Handlebars, Mustache, the list goes on and on. Typescript literally exists to address a deficiency in JS. I don't think reinventing the wheel is the answer - it should taking these clear improvements and adding them to the core product. A big part of why technologies become popular is because of how accessible they are to newer or less knowledgable developers. I don't think some new idea would work, we should work with what's already there. I don't think there's any fundamental flaw in HTML, CSS or JS that necessitates a complete replacement. Just adjustments. HTML's purpose is to semantically describe content. I don't see how that is at odds with describing the user interface for software vs. a web page. CSS can lay things out great. It used to be a pain, but flexbox/grids have made it easy now. JS is the most popular language in the world. If we added a "types" mode that just adds the typescript syntax and lets you set a flag for it, it'd be even better. We don't need a new programming language for people to learn. See, that's where we differ. I think HTML and CSS are great. They just need to be improved. >This isn't web specific. Desktop UI APIs change frequently too. UI is hard, and only higher level of abstractions can simplify things. Yeah, and if you look at the popularity of electron apps it's pretty clear that people prefer doing this stuff in HTML/CSS/JS, even with all the hacks than trying to learn platform specific stuff. I'm arguing with tweaks, we could do it AND have it be performant and not a pain in the ass.
• tonightstoast 4y ago
  Please write the blog post. It may be a hard sell but think of it more as a creative conversation with the future of web dev. While you may not get the final answer “correct”, your post will help the community progress a much needed discussion.
  • dimmke 4y ago
    Thanks, and I will. It's at about 3000 words and I have been sitting on it, but I think I am going to just finish it up and release it and see what discussion it generates.
    • jelan 4y ago
      Please share it when you are done!
• robin_reala 4y ago
  Number 3 is the ARIA spec right? You should be using that already if you’re writing accessible applications. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
  • dimmke 4y ago
    Here's what I don't understand about the ARIA spec - and maybe you can help clarify it for me. Why are we using attributes instead of element names? Like take this for example: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/application_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... Did we just give up on using semantic elements? People barely know how to write regular HTML anymore, and the ARIA spec is confusing. I'm glad it exists, but to me it fits into the same category as "Web components" - a bad idea that isn't widely adopted because it sucks.
    • an1sotropy 4y ago
      Can you say more about why "it sucks"? Are there some specific changes you can think of that would have made it a less bad idea?
      • dimmke 4y ago
        1. It's confusing. The fact that there's a "role" attribute that is implicit sometimes and needs to be declared other times and a "aria-XYZ" set of attributes is stupid. The purist HTML take was always "Markup should describe content" - now we're describing content with attributes? 2. It's positioned specifically as being for accessibility. This is bad for several reasons. First, it's not necessary. The entire goal of semantic markup in the first place was to make it so that the content of documents can be read by machines (both screen readers and other systems) - tacking on a special system just for accessibility is basically them giving up on this entirely. Secondly, a lot of people don't care about accessibility. Like I said, in our current system people barely know how to write HTML. Or they write some bastardized version of it in JSX or w/e. You think they're going to learn the intricacies of ARIA? No. The goal should be for HTML to be a language that when written properly is accessible by default. Not just "hey everybody it's cool if you use divs for everything, just make sure screen readers know what it's supposed to be."
• naasking 4y ago
  > Add dynamic interpolation to the HTML spec. This stops every framework from having to invent it's own version of it. Not sure what this means exactly > 2. Update the DOM api to allow data binding/state and improve the Web APIs around routing/history to make SPAs even easier. Something like AlpineJS built-in? > 3. Update the HTML spec to allow for semantically describing user interface elements of software applications. ARIA roles kind of already do this.
  • dimmke 4y ago
    My post will expand on all of this in detail, including addressing ARIA.
• MrStonedOne 4y ago
• sundarurfriend 4y ago
  In practice, any attempt to change these basic specs would be diverted to be to the benefit of Google and its ilk, with the power they have to steer conversations and decisions. It's an accident of history that we ended up with these fairly open and hackable systems as the basis for the Web, and it's at a delicate point where a lot of companies are annoyed that they can't silo and close down more of it. So the unfortunate reality is that any well-intentioned attempt to reform them would be used instead to reshape them for corporate interests, with no guarantee that we even end up with better specs from a developer point of view. The incentives lay in the direction of guaranteeing corporate interests, with users losing more of their freedom to choose how they access and use the Web; the developer concerns will at best be used as a PR front for the press headlines.
• crabmusket 4y ago
  Which of the current JS frontend framework paradigms do you think should be standardised and shipped in browsers? Would you choose a React-like model, or maybe something more Svelte-like? Or something different from either of those two that I'm not aware of? And the follow up question, which is pointed, is: if your proposed solution would look similar to current JS solution X, why would it be better than X? Is the goal removing the build process? Increasing uniformity across the ecosystem?
  • dimmke 4y ago
    Great questions! >Which of the current JS frontend framework paradigms do you think should be standardised and shipped in browsers? The basic concept of "binding" data to a DOM element and having the DOM element update when you update the data instead of having to manually update it. That's something every modern frontend framework does. I think under the hood, the people who actually write the DOM apis would know how to do that in the most performant way possible. I know any native approach would certainly be faster than a Javascript framework. To me the more important part is getting the API surface right. That's the big problem with a lot of these standards updates. They kind of half assedly add a feature that's inconvenient and then nobody uses it. They need to think more like "How can we incentivize people to drop X framework and do it natively?" >if your proposed solution would look similar to current JS solution X, why would it be better than X? It'd almost certainly be faster being built into the native code, but yes the goal is to remove the build process and tooling. But also to bring things back into balance. Right now, most web apps are a big bundle of JavaScript. But with these changes, it'd be several HTML files, JS files, CSS files. In balance again. Each technology has its own place. I think the average skillset of front-end developers would improve massively if they didn't have to do stuff like chase down NPM problems or debug Webpack.
    • Chris_Newton 4y ago
      I appreciate the ambition to reduce the complexity and tooling overheads. Unfortunately, I doubt we could define a sufficiently general API for the kind of functionality you’re talking about. There is too much variety in the applications we now build with web technologies. Maybe we could do it for simple CRUD application UIs that are built using lightly styled forms and tables. To be fair, that might already be a substantial proportion of all web UI development. But the kind of data binding you’re talking about wouldn’t help at all with implementing a word processor, an FPS game or a data-heavy app built around interactive visualisations. A foundation where UIs are built from simple pieces of DOM derived directly from corresponding variables in JS would severely restrict what we could build on top.