16 ms·

What a grumpy comment. - Two of the best developers I know are completely self-taught. - I'd argue there have been so many front-end frameworks not for the sa

What a grumpy comment. - Two of the best developers I know are completely self-taught. - I'd argue there have been so many front-end frameworks not for the sake of novelty because the web platform itself was incomplete and stagnated. (And also blew a huge opportunity with the APIs for web components.) - Now that the platform is evolving and innovating again, more and more things are moving out of the frameworks and back into the platform. Javascript has massively improved. - Some amazing and complex engineering happens in the frontend space because of the constraints and the need to eek performance out of everywhere you can. You can't just throw more servers at the problem. - Experiences vary, but I've been on more projects delayed by over-engineering the backend than the frontend.

zer8k 3y ago
> Now that the platform is evolving and innovating again, more and more things are moving out of the frameworks and back into the platform. Javascript has massively improved. A language so good you need to write another language that compiles into that language to make it tolerable. > Some amazing and complex engineering happens in the frontend space because of the constraints and the need to eek performance out of everywhere you can. You can't just throw more servers at the problem. I'm not sure about this opinion. Most websites are slow as all get out and require me to download the world to even get working. > Experiences vary, but I've been on more projects delayed by over-engineering the backend than the frontend. As a person on the backend I can tell you your definition of "overengineering" is ignoring the fact we have to deal with frontend cowboys all the time. When SEVs happen it's us on trial almost universally. Just the absolutely bonkers states a frontend can accidentally end up in despite good testing is enough to warrant "overengineering" to try to support it. We had an opportunity to kill javascript and instead we embraced it. We deserve what we get.
- claytongulick 3y ago
  > A language so good you need to write another language that compiles into that language to make it tolerable If static typing is your thing, I guess. It's not for everyone. > We had an opportunity to kill javascript and instead we embraced it. We deserve what we get. Some of us quite enjoy the language.
- The_Colonel 3y ago
  > A language so good you need to write another language that compiles into that language to make it tolerable. Some people need it to make it tolerable. That happens on every platform. You have Java and Kotlin/Scala/Groovy ... Microsoft even created F# to its C# ... > We had an opportunity to kill javascript and instead we embraced it. We deserve what we get. You mean VBScript? Or what other opportunity you mean? I often get the sense that JS haters last saw the language in 1999. Modern JavaScript is a very nice scripting language. Succint, elegant, functional. Its major omission is the lack of static typing, but JSDoc and WebStorm make it tolerable.
claytongulick 3y ago
> And also blew a huge opportunity with the APIs for web components How? I really don't understand this sentiment. The web components API is a gajillion times less complex to me than, for example, react. Coupled with a light weight rendering library like lit-html, a basic component takes seconds. - Make a class that inherits HTMLElement - Create a rendering template in connectedCallback using your favorite templating/rendering library. - Add class properties that call render() when they're changed. The cognitive load is a fraction of what's needed for frameworks like angular or react.
- troupo 3y ago
  > The web components API is a gajillion times less complex to me than, for example, react. And then you go on to list multiple complex things: - Create a rendering template in connectedCallback using your favorite templating/rendering library. So you need to bind together a connectedCallback and some rendering library - Add class properties that call render() when they're changed. So you have to manually wire class properties to manually call render. In comparison, React alreayd handles all of that for you. > The cognitive load is a fraction of what's needed for frameworks like angular or react. Since you mentioned lit-html, that "lightweight rendering library" has all the "cognitive load" of React, and is getting more complex
  - claytongulick 3y ago
    > So you need to bind together a connectedCallback and some rendering library It's no different than jsx, you just get to pick whatever you want. I honestly believe that 90% of the dislike for WC comes from the name "connectedCallback". If they'd named it "onCreate" or something, everyone would be using it. It's named that because it's the lifecycle method for when a component becomes connected to the DOM, so it's technically correct - a component can be created and function without being connected to the DOM. But people really hate that name for some reason. It's all the same stuff. You have to do all the same things regardless of framework. You declare a template somewhere, you define the props that will cause a render on change, and you keep track of the internal state of the component. With React or angular or vue or whatever, you still have to do all this, you just incur the cost of a massive framework too. > So you have to manually wire class properties to manually call render. Yeah, 1 line of code. And in exchange you get to avoid a whole framework, get much better performance and have real control over your component's render cycle. Also, you still have to do this with react, it's just a different syntax. > Since you mentioned lit-html, that "lightweight rendering library" has all the "cognitive load" of React, and is getting more complex Huh? Lit-html is simpler than handlebars. Are you confusing it with LitElement?

zer8k 3y ago

> Now that the platform is evolving and innovating again, more and more things are moving out of the frameworks and back into the platform. Javascript has massively improved. A language so good you need to write another language that compiles into that language to make it tolerable. > Some amazing and complex engineering happens in the frontend space because of the constraints and the need to eek performance out of everywhere you can. You can't just throw more servers at the problem. I'm not sure about this opinion. Most websites are slow as all get out and require me to download the world to even get working. > Experiences vary, but I've been on more projects delayed by over-engineering the backend than the frontend. As a person on the backend I can tell you your definition of "overengineering" is ignoring the fact we have to deal with frontend cowboys all the time. When SEVs happen it's us on trial almost universally. Just the absolutely bonkers states a frontend can accidentally end up in despite good testing is enough to warrant "overengineering" to try to support it. We had an opportunity to kill javascript and instead we embraced it. We deserve what we get.

claytongulick 3y ago
> A language so good you need to write another language that compiles into that language to make it tolerable If static typing is your thing, I guess. It's not for everyone. > We had an opportunity to kill javascript and instead we embraced it. We deserve what we get. Some of us quite enjoy the language.
The_Colonel 3y ago
> A language so good you need to write another language that compiles into that language to make it tolerable. Some people need it to make it tolerable. That happens on every platform. You have Java and Kotlin/Scala/Groovy ... Microsoft even created F# to its C# ... > We had an opportunity to kill javascript and instead we embraced it. We deserve what we get. You mean VBScript? Or what other opportunity you mean? I often get the sense that JS haters last saw the language in 1999. Modern JavaScript is a very nice scripting language. Succint, elegant, functional. Its major omission is the lack of static typing, but JSDoc and WebStorm make it tolerable.

claytongulick 3y ago

> And also blew a huge opportunity with the APIs for web components How? I really don't understand this sentiment. The web components API is a gajillion times less complex to me than, for example, react. Coupled with a light weight rendering library like lit-html, a basic component takes seconds. - Make a class that inherits HTMLElement - Create a rendering template in connectedCallback using your favorite templating/rendering library. - Add class properties that call render() when they're changed. The cognitive load is a fraction of what's needed for frameworks like angular or react.

troupo 3y ago
> The web components API is a gajillion times less complex to me than, for example, react. And then you go on to list multiple complex things: - Create a rendering template in connectedCallback using your favorite templating/rendering library. So you need to bind together a connectedCallback and some rendering library - Add class properties that call render() when they're changed. So you have to manually wire class properties to manually call render. In comparison, React alreayd handles all of that for you. > The cognitive load is a fraction of what's needed for frameworks like angular or react. Since you mentioned lit-html, that "lightweight rendering library" has all the "cognitive load" of React, and is getting more complex
- claytongulick 3y ago
  > So you need to bind together a connectedCallback and some rendering library It's no different than jsx, you just get to pick whatever you want. I honestly believe that 90% of the dislike for WC comes from the name "connectedCallback". If they'd named it "onCreate" or something, everyone would be using it. It's named that because it's the lifecycle method for when a component becomes connected to the DOM, so it's technically correct - a component can be created and function without being connected to the DOM. But people really hate that name for some reason. It's all the same stuff. You have to do all the same things regardless of framework. You declare a template somewhere, you define the props that will cause a render on change, and you keep track of the internal state of the component. With React or angular or vue or whatever, you still have to do all this, you just incur the cost of a massive framework too. > So you have to manually wire class properties to manually call render. Yeah, 1 line of code. And in exchange you get to avoid a whole framework, get much better performance and have real control over your component's render cycle. Also, you still have to do this with react, it's just a different syntax. > Since you mentioned lit-html, that "lightweight rendering library" has all the "cognitive load" of React, and is getting more complex Huh? Lit-html is simpler than handlebars. Are you confusing it with LitElement?