5 ms·

edit - to thank everyone who took time out to explain what's going on - I'm still cynical but it all makes more sense now. I also like to think the ignorant guy

by parksy 6y ago

edit - to thank everyone who took time out to explain what's going on - I'm still cynical but it all makes more sense now. I also like to think the ignorant guy asking the ignorant questions (in this case me) can sometimes be valuable for others who aren't in the club. Previous rant intact below for fun and hijinks. --- As a jaded old web developer I've seen so many frameworks along the way all promising this and that. Can someone who is familiar with this answer me this: Does this framework automatically sort out ARIA standards for me? Like tab ordering and stuff is dealt with automatically? I know it seems I am being lazy but I am just fed up. "FAST is a collection of JavaScript packages centered around web standards, designed to help you efficiently tackle some of the most common challenges in website and application design and development." COOL! (/s) "Have you ever needed a reusable set of UI components that you could drop into your app and have an amazing experience? That's FAST." UNIQUE! (/s) "Have you ever needed to create your own components, and share them across your company, including across groups that use different, incompatible front-end frameworks? That's FAST." <record scratch> Different, incompatible front-end frameworks? So like, this shit is magic that will let me streamline components between my Oceania team's WordPress and my German team's Magento frontends? And I don't have to learn any new paradigm to make this work? I don't have to use their specific, custom HTML in order to leverage it? https://www.fast.design/docs/components/accordion https://www.fast.design/docs/components/accordion SWEET! (/s) Come on. We'd have to re-write everything to use this library specifically, and train our teams. Honestly this is to me just another bunch of shit that will get tacked into projects and have to be known and supported, because some sprightly young thing will convince management this is the panacea to seemingly redundant development work. What's the actual selling point here.

spankalee 6y ago
> Come on. We'd have to re-write everything to use this library specifically That is not how web components work. Web components are just HTML elements, so any framework that can use HTML can use web components. That's what sharing across different, incompatible frameworks means.
- parksy 6y ago
  I honestly don't understand what this definition of "frameworks" means in this exact context and I've been building websites since 1994, survived the XHTML collapse, etc etc... What's the main advantage here? That we have a standardised way of writing HTML markup so that CSS / JS knows how to operate on it? I'm almost certainly coming across as "old man yells at cloud" (lol just realised a pun there) but what would you say is the best resource for me to go and upskill so I can see the actual value in this for me and / or my teams in the future?
  - pupdogg 6y ago
    Lol, love your comment! Funny thing is that there are more people on your side than what this community might tell you! Silence is golden for a reason ;)
    - parksy 6y ago
      I appreciate the support I guess but at the same time I don't understand what you mean by there are an unspecified number of people on my side and that silence is golden - either that means I should be quiet and join the throngs of the self-superior invisible some-jority which I think is condescending to the fine folk here, or it means I personally should be silent and not express my honest confusion, frustration and dismay. That's not going to happen either. I did come out pretty strong in my apprehension but I am serious in wanting to know specifically what the benefit of this is, and I don't really care whether I am making a fool of myself for asking questions lol.
      - dmitriid 6y ago
        Theory: web components provide a standardised component model for the web so that you don't need to rely on frameworks and a bunch of JavaScript to create interchangeable interoperable components that are no different from built-in browser components. Oh, and you can extend existing built-in components with your own behaviours. Reality: - WebComponents is a collection of 4 web standards, one of them is already deprecated, and v0 of another one is also already deprecated. - The standards provide a verbose, error-prone imperative API that leaks implementation details left and right - The API is so bad, that the official stance is "the API is aimed at library and framework developers, and you are not expected to write your components using this API". And if you look at the frameworks, they try to not even compile/transpile down to this API - Since all WebComponents basically have is DOM APIs, the official stance is basically "yeah, they are good for implementing leaf nodes" (that is basic dump components like an simple input field, or a label) because you still need a full-fledged lib/framework for anything else - You cannot extend some (most?) of the built-in components. And even if you can, your custom implementations will not participate in form events, so you have to create workarounds if you want to submit values from your components - They break accessibility - They don't work without JavaScript - They cannot be rendered server-side - They are not strictly HTML, but a subset of it, because you can't provide callbacks for their custom events (you can do onClick, but you cannot do onSomeCustomEvent) - And on the social side of things, their proponents will very rarely acknowledge or discuss these issues in public (even though there are dozens if not hundreds of issues with extensive discussions on GitHub), but will spend not an inconsiderable amount of time and energy bashing non-webcomponent libraries and frameworks
ramon 6y ago
Focus on Web Components and forget Fast you'll see the benefits then and then start looking around at other projects focusing on Web Components. The benefit is that you can have whatever frontend tech stack at your project, someone doing Vue another one in React.. another one in JQuery there's no limits.
- parksy 6y ago
  Thanks I have asked another poster to fill me in because maybe I'm too old school and yelling at kids to get off my lawn. I might have to shut up now for a while until I run away and get back up to speed in this arena. But I have used react, vue, jquery, and my favourite which is just plain old JS and to me this is just generating templates with a different DOM structure and class semantics. IDK it just seems like this is not something I'd want to retrofit but would have to adopt as a standard to see any value long-term over a bunch of projects. Usually I am more measured in my responses but this time I tried to just say what I am thinking (screw my ignorance) so maybe I can learn a thing or two. Thanks for responding.
  - ramon 6y ago
    I'm in the same boat, I still like the plain old vanilla JS I do see the benefits of Typescript and all but I don't know I have been doing JS since I was 10 years old so I guess it's something that comes from my childhood haha. I just love JS in any fashion, it's a love relationship since the beginning and way back then I always saw that there was huge value around JS but never imagined back then that we would get to were we are today, back then Flash was the big deal and it was doing the more advanced functionality in the front-end could never imagined that Shockwave, Flash would all get basically banned due to security. Interesting turn around for JS and the open source nature it has always had since its infancy with the Mozilla Browser.
    - parksy 6y ago
      I started coding BASIC in the late 80s and built websites before CSS and JS was a thing in addition to just coding stuff in whatever language took my fancy to solve whatever whimsical project I had that day, I had a particular affinity for optimising getpixel and putpixel routines in ASM when you could still directly address video memory. On the one hand this is great because programming is in my bones and I know whatever comes along I'll figure out. It's also terrible because sometimes something that looks like a rebranded version of what I already know is actually a fantastic new and easier way of doing things, and it's really easy to miss something great. This just doesn't feel like something great, it just feels like another branded corporate way to structure code that there's dozens of examples of already, it's not an improvement just an alternative, if that makes sense.

by parksy 6y ago

spankalee 6y ago

> Come on. We'd have to re-write everything to use this library specifically That is not how web components work. Web components are just HTML elements, so any framework that can use HTML can use web components. That's what sharing across different, incompatible frameworks means.

parksy 6y ago
I honestly don't understand what this definition of "frameworks" means in this exact context and I've been building websites since 1994, survived the XHTML collapse, etc etc... What's the main advantage here? That we have a standardised way of writing HTML markup so that CSS / JS knows how to operate on it? I'm almost certainly coming across as "old man yells at cloud" (lol just realised a pun there) but what would you say is the best resource for me to go and upskill so I can see the actual value in this for me and / or my teams in the future?
- pupdogg 6y ago
  Lol, love your comment! Funny thing is that there are more people on your side than what this community might tell you! Silence is golden for a reason ;)
  - parksy 6y ago
    I appreciate the support I guess but at the same time I don't understand what you mean by there are an unspecified number of people on my side and that silence is golden - either that means I should be quiet and join the throngs of the self-superior invisible some-jority which I think is condescending to the fine folk here, or it means I personally should be silent and not express my honest confusion, frustration and dismay. That's not going to happen either. I did come out pretty strong in my apprehension but I am serious in wanting to know specifically what the benefit of this is, and I don't really care whether I am making a fool of myself for asking questions lol.
    - dmitriid 6y ago
      Theory: web components provide a standardised component model for the web so that you don't need to rely on frameworks and a bunch of JavaScript to create interchangeable interoperable components that are no different from built-in browser components. Oh, and you can extend existing built-in components with your own behaviours. Reality: - WebComponents is a collection of 4 web standards, one of them is already deprecated, and v0 of another one is also already deprecated. - The standards provide a verbose, error-prone imperative API that leaks implementation details left and right - The API is so bad, that the official stance is "the API is aimed at library and framework developers, and you are not expected to write your components using this API". And if you look at the frameworks, they try to not even compile/transpile down to this API - Since all WebComponents basically have is DOM APIs, the official stance is basically "yeah, they are good for implementing leaf nodes" (that is basic dump components like an simple input field, or a label) because you still need a full-fledged lib/framework for anything else - You cannot extend some (most?) of the built-in components. And even if you can, your custom implementations will not participate in form events, so you have to create workarounds if you want to submit values from your components - They break accessibility - They don't work without JavaScript - They cannot be rendered server-side - They are not strictly HTML, but a subset of it, because you can't provide callbacks for their custom events (you can do onClick, but you cannot do onSomeCustomEvent) - And on the social side of things, their proponents will very rarely acknowledge or discuss these issues in public (even though there are dozens if not hundreds of issues with extensive discussions on GitHub), but will spend not an inconsiderable amount of time and energy bashing non-webcomponent libraries and frameworks

ramon 6y ago

Focus on Web Components and forget Fast you'll see the benefits then and then start looking around at other projects focusing on Web Components. The benefit is that you can have whatever frontend tech stack at your project, someone doing Vue another one in React.. another one in JQuery there's no limits.

parksy 6y ago
Thanks I have asked another poster to fill me in because maybe I'm too old school and yelling at kids to get off my lawn. I might have to shut up now for a while until I run away and get back up to speed in this arena. But I have used react, vue, jquery, and my favourite which is just plain old JS and to me this is just generating templates with a different DOM structure and class semantics. IDK it just seems like this is not something I'd want to retrofit but would have to adopt as a standard to see any value long-term over a bunch of projects. Usually I am more measured in my responses but this time I tried to just say what I am thinking (screw my ignorance) so maybe I can learn a thing or two. Thanks for responding.
- ramon 6y ago
  I'm in the same boat, I still like the plain old vanilla JS I do see the benefits of Typescript and all but I don't know I have been doing JS since I was 10 years old so I guess it's something that comes from my childhood haha. I just love JS in any fashion, it's a love relationship since the beginning and way back then I always saw that there was huge value around JS but never imagined back then that we would get to were we are today, back then Flash was the big deal and it was doing the more advanced functionality in the front-end could never imagined that Shockwave, Flash would all get basically banned due to security. Interesting turn around for JS and the open source nature it has always had since its infancy with the Mozilla Browser.
  - parksy 6y ago
    I started coding BASIC in the late 80s and built websites before CSS and JS was a thing in addition to just coding stuff in whatever language took my fancy to solve whatever whimsical project I had that day, I had a particular affinity for optimising getpixel and putpixel routines in ASM when you could still directly address video memory. On the one hand this is great because programming is in my bones and I know whatever comes along I'll figure out. It's also terrible because sometimes something that looks like a rebranded version of what I already know is actually a fantastic new and easier way of doing things, and it's really easy to miss something great. This just doesn't feel like something great, it just feels like another branded corporate way to structure code that there's dozens of examples of already, it's not an improvement just an alternative, if that makes sense.