5 ms·

By using small libraries – components with a dedicated purpose and a small surface area – it becomes possible to pick and mix, to swap parts of our front end st

By using small libraries – components with a dedicated purpose and a small surface area – it becomes possible to pick and mix, to swap parts of our front end stack out if and when they are superceded. This is the problem with front-end dev in a nutshell. Everybody is mixing and matching their own solutions which makes it impossible for an ecosystem of higher level, reusable components to emerge. Compare this to iOS, for instance, where I can go pick and choose from a huge online library of prebuilt components and be fairly confident I can just "pod install" them and go. I'm not a fan of Angular but it was a good thing for there to be something like a de-facto SPA framework standard. I can only imagine how upset business owners that invested heavily in Angular 1 apps are feeling now. If web developers are serious about mounting a challenge to the rising tide of native apps, they need to build some consensus and agree on some durable foundations. In the end elegance and novelty count for nothing if you don't have a healthy, stable ecosystem upon which businesses can depend. It's sad to think that the freedom that makes web dev so appealing may also turn out to be its fatal weakness.

sehr 12y ago
Compare this to iOS, for instance, where I can go pick and choose from a huge online library of prebuilt components and be fairly confident I can just "pod install" them and go I believe this is the one of the main motivators behind web components
- cageface 12y ago
  I haven't built anything non-trivial with web components but I do like where they're going with them in principle. The biggest problem I see with WC is that they require native browser support to really function properly and I'm not sure it's really in Apple's or Microsoft's best interest to support them. AFAIK Apple hasn't made any indication so far that they will support the WC spec.
  - BinaryIdiot 12y ago
    Microsoft already supports some of the WC standard and Apple will as well since it's being put into WebKit. Polymer is a great polyfill though it does have some performance issues (0.5 is much improved at least).
  - Offler 12y ago
    I think the biggest problem with WCs is they are standardizing best practices from 2011/Angular early days. Things have moved on and mutable two-way state that binds to a stateful DOM is no longer state of the art.
- rictic 12y ago
  Having worked with web components over the past few months, yes this. I can mix and match polymer, x-* elements, brick components etc with ease. I don't have to care how a given component is written or what its dependencies are. It's definitely the future.
  - Offler 12y ago
    I can drop a jQuery calendar into a React component with minimum fuss. I think the interoperability issue only comes with components from large frameworks.
    - marknutter 12y ago
      But how easily can someone drop your React component that utilizes jQuery Calendar into their own application?
      - Offler 12y ago
        Very easily if they use ES6 modules and a package manager like jspm that understands ES6 modules. One line install, one line import.
        marknutter 12y ago
        I feel like "very easily" shouldn't be followed immediately by "if they use..." if it's to be taken seriously.
    - mcintyre1994 12y ago
      Honest question - I'm a react newbie and one thing that isn't immediately obvious is how to drop a DOM-manipulating jquery library into a React component. I'm sure I'm missing something really simple here, but do you know anywhere that's documented by any chance?
      - insin 12y ago
        https://github.com/rpflorence/react-training/blob/gh-pages/lessons/05-wrapping-dom-libs.md https://github.com/rpflorence/react-training/blob/gh-pages/l...
wycats 12y ago
This is actually more than just web components. iOS and Android have shared application architecture, tools, and navigation between screens. On the web, we'll never have "one true" solution to these problems, but the animosity towards attempts to provide holistic solutions on par with our native brethren sure isn't helping. If you want to evaluate anew and put together dozens (or hundreds) of tiny modules on every new project, and maintain/evolve that collection over time, fine. But we don't need to tell people that something is deeply wrong if they want a full front-end stack that evolves as the web changes. Nothing is wrong with solutions that track best practices and evolve to incorporate more common problems.
je42 12y ago
What prevents you do a "npm install" ?

sehr 12y ago

Compare this to iOS, for instance, where I can go pick and choose from a huge online library of prebuilt components and be fairly confident I can just "pod install" them and go I believe this is the one of the main motivators behind web components

cageface 12y ago
I haven't built anything non-trivial with web components but I do like where they're going with them in principle. The biggest problem I see with WC is that they require native browser support to really function properly and I'm not sure it's really in Apple's or Microsoft's best interest to support them. AFAIK Apple hasn't made any indication so far that they will support the WC spec.
- BinaryIdiot 12y ago
  Microsoft already supports some of the WC standard and Apple will as well since it's being put into WebKit. Polymer is a great polyfill though it does have some performance issues (0.5 is much improved at least).
- Offler 12y ago
  I think the biggest problem with WCs is they are standardizing best practices from 2011/Angular early days. Things have moved on and mutable two-way state that binds to a stateful DOM is no longer state of the art.
rictic 12y ago
Having worked with web components over the past few months, yes this. I can mix and match polymer, x-* elements, brick components etc with ease. I don't have to care how a given component is written or what its dependencies are. It's definitely the future.
- Offler 12y ago
  I can drop a jQuery calendar into a React component with minimum fuss. I think the interoperability issue only comes with components from large frameworks.
  - marknutter 12y ago
    But how easily can someone drop your React component that utilizes jQuery Calendar into their own application?
    - Offler 12y ago
      Very easily if they use ES6 modules and a package manager like jspm that understands ES6 modules. One line install, one line import.
      - marknutter 12y ago
        I feel like "very easily" shouldn't be followed immediately by "if they use..." if it's to be taken seriously.
  - mcintyre1994 12y ago
    Honest question - I'm a react newbie and one thing that isn't immediately obvious is how to drop a DOM-manipulating jquery library into a React component. I'm sure I'm missing something really simple here, but do you know anywhere that's documented by any chance?
    - insin 12y ago
      https://github.com/rpflorence/react-training/blob/gh-pages/lessons/05-wrapping-dom-libs.md https://github.com/rpflorence/react-training/blob/gh-pages/l...

wycats 12y ago

This is actually more than just web components. iOS and Android have shared application architecture, tools, and navigation between screens. On the web, we'll never have "one true" solution to these problems, but the animosity towards attempts to provide holistic solutions on par with our native brethren sure isn't helping. If you want to evaluate anew and put together dozens (or hundreds) of tiny modules on every new project, and maintain/evolve that collection over time, fine. But we don't need to tell people that something is deeply wrong if they want a full front-end stack that evolves as the web changes. Nothing is wrong with solutions that track best practices and evolve to incorporate more common problems.

je42 12y ago

What prevents you do a "npm install" ?