3 ms·

Hi All, I use Angular 6 – 10 at work every day @day$job and have used Vue.js for some side projects / school related. Long story short have been looking into s

Hi All, I use Angular 6 – 10 at work every day @day$job and have used Vue.js for some side projects / school related. Long story short have been looking into standard web components for my next side project and FicusJS seems to check all the boxes. Problem is there is almost no information about FicusJS other than what I can find linked off https://webcomponents.dev/new/ https://webcomponents.dev/new/ The other ones in the running are GitHub/Catalyst, AppRun, CanJS or compiler Riot, Stencil, ect… I think I want to stay away from build tools until I can’t Does anyone have any experience with FicusJS? Seems FicusJS uses lit-html in all the examples so maybe start there? Good or bad would love to hear your story. Cheers!

edoceo 6y ago
No experience with Ficus but others. I'd been trying to avoid that ceremony tooling/build step too. But, modern JS I've realized that's wasted effort. Embrace the suck.
- Sn0wCoder 6y ago
  I LOLed. I have had pretty good luck with Vue and jsdelivr. Would not call it speedy, but easy to get students going and runs on Glitch.com
  - edoceo 6y ago
    My current favorite is RiotJS. One can still prototype things w/o ceremony in a single static html page + the tags to prototype
- nicoburns 6y ago
  Have you tried esbuild? It's still a build step, but it: 1. Works more or less out of the box. You'll maybe need to set 5 or 6 CLI arguments but that's it 2. It's super speedy (sub-second in our case)
colordrops 6y ago
The x-element library published by Netflix [1] takes the best features of other web components libraries like Polymer and LitElement, and focuses on a standards based approach, e.g. es6 module loading at runtime, which is done intentionally to avoid a build step. https://github.com/Netflix/x-element https://github.com/Netflix/x-element
- spankalee 6y ago
  There's a chance Netflix will port to x-element to be an extension of LitElement: https://github.com/Netflix/x-element/issues/53 https://github.com/Netflix/x-element/issues/53
- Sn0wCoder 6y ago
  Thanks, going to read-up on x-element.
Fractal_HQ 6y ago
You can make vanilla web components with Svelte, and Svelte has a much better DX than React, Vue, and Angular. It also performs better thanks to the compile step. I highly recommend checking it out!
- eyelidlessness 6y ago
  I think the DX claim is pretty subjective. I find JSX much easier to use than all the others mentioned, and a great deal more flexible. The ease of use being that it’s just JavaScript (or more importantly TypeScript), with some DSL. That means it follows all the other rules of the environment in which it runs, and uses all the same tooling. It also produces a data structure that’s renderer-agnostic, so it’s trivial to adapt to different platforms and build targets.
  - ath92 6y ago
    Well JSX is not really just javascript/typescript - it needs to be transformed first, just throwing a .jsx file into a script tag won't work. It does compile down to just javascript, but the same can be said for svelte. I can see the argument for JSX being more flexible, given that you can store little bits of JSX in js expressions, something you typically cannot do with the other component frameworks. But tools like svelte have their own DX improvements that make things like state management / reactivity arguably a lot easier than React.
    - eyelidlessness 6y ago
      > Well JSX is not really just javascript/typescript Right that’s the DSL part. But TypeScript understands it out of the box, and you can write the same expressions without the DSL by calling the pragma function directly (which I’ll often do for some tooling code that needs to run without a build step). > But tools like svelte have their own DX improvements that make things like state management / reactivity arguably a lot easier than React. Part of the reason I mentioned JSX rather than React. There are great libraries with similar state and reactivity facilities that work with JSX (for example Solid). The cool thing about JSX is that it’s not tightly coupled to any particular implementation.
azangru 6y ago
> Long story short have been looking into standard web components for my next side project and FicusJS seems to check all the boxes. Could you please list the boxes that you were ticking? For example, how many boxes would the following tick: - Preact with htm (tiny, looks very similar to ficus) [0] - LitElement (tiny, very close to native web components) [1] - Svelte (the darling of many since recently) [2] [0] - https://github.com/developit/htm https://github.com/developit/htm [1] - https://lit-element.polymer-project.org/ https://lit-element.polymer-project.org/ [2] - https://svelte.dev/ https://svelte.dev/
- Sn0wCoder 6y ago
  - Great question. The main thing I was looking for was going build-less and the section of Ficus docs kinda sold me on the idea. Seems we still need to use a dev-server to allow native imports like - https://modern-web.dev/docs/dev-server/overview/ - Which would allow testing and builds (if go that route) - Seems that you can use any renderer (uhtml, lit-html,htm, Preact), so what-ever I learn will be useable outside the Ficus eco-system - Event Bus: Use this model in another project and worked well. - Stores: not sold on the whole redux pattern, but want to learn abit more about global stores to update components - Was in analysis paralysis before finding Ficus and the more I learned the more confused on what I should try next. - Mostly needed to make a decision as I want to dabble with Web-Components but seems starting from scratch is too low level so pick something just a tad higher than that. Thanks for helping me understand my own decision.
  - spankalee 6y ago
    I work on LitElement and if you want to use it buildless you can do so with the JavaScript reactive properties API (so you don't need TypeScript or Babel decorators to declare properties) and Chrome 89's support for import maps. Generally, I think an import specifier rewriting dev server like Web Dev Server is the way to go since it'll work with so many other libraries out there.
    - floatboth 6y ago
azangru 6y ago
> I think I want to stay away from build tools until I can’t No typescript then, eh?
- runarberg 6y ago
  You can always annotate your code with JSDoc comments and type check your code with `tsc --noEmit`, i.e. typescript without the build step.
  - eyelidlessness 6y ago
    No strict null checks is kinda a deal breaker tho
- Sn0wCoder 6y ago
  I use TypeScript everyday at work, and love it. No not a requirement for side projects. When they grow to something more change extension to .ts and go from there.
chrisweekly 6y ago
Stencil is the real deal. /$.02 Edit: ... if you're getting serious about standard web components per se.
- Sn0wCoder 6y ago
  I have researched Stencil a few times and agree it seems to be like you say 'the real deal'. In time I might end up there but going to take the long way :)
- runarberg 6y ago
  Question: I’ve done Stencil in the past and quite liked it. I especially liked how helpful the community is on e.g. slack. Now I’m experimenting with lit-element. My initial expression is that it is not as fully fledged out as Stencil is. Do you have any experience with either lit-element or Salesforce’s lightning web components and are able to compare them?
- nraf 6y ago
  Been using Stencil for the past year or so as a way of extending our Angular app with client-specific apps (eventually looking to open this up to clients to upload their own components / apps). Overall it's done a good job but I still find the build system somewhat esoteric (there are a number of different approaches and it took some effort to figure out the right one for our use case). I have noticed development has slowed down over the past couple months: https://github.com/ionic-team/stencil/graphs/commit-activity https://github.com/ionic-team/stencil/graphs/commit-activity Hoping it's more a case of it approaching maturity as opposed to it being neglected...
crazypython 6y ago
Please add enough documentation to use FicusJS without prior knowledge of Web Components! It's very important for adoption as a framework in its own right with web components as one component.

edoceo 6y ago

No experience with Ficus but others. I'd been trying to avoid that ceremony tooling/build step too. But, modern JS I've realized that's wasted effort. Embrace the suck.

Sn0wCoder 6y ago
I LOLed. I have had pretty good luck with Vue and jsdelivr. Would not call it speedy, but easy to get students going and runs on Glitch.com
- edoceo 6y ago
  My current favorite is RiotJS. One can still prototype things w/o ceremony in a single static html page + the tags to prototype
nicoburns 6y ago
Have you tried esbuild? It's still a build step, but it: 1. Works more or less out of the box. You'll maybe need to set 5 or 6 CLI arguments but that's it 2. It's super speedy (sub-second in our case)

colordrops 6y ago

The x-element library published by Netflix [1] takes the best features of other web components libraries like Polymer and LitElement, and focuses on a standards based approach, e.g. es6 module loading at runtime, which is done intentionally to avoid a build step. https://github.com/Netflix/x-element https://github.com/Netflix/x-element

spankalee 6y ago
There's a chance Netflix will port to x-element to be an extension of LitElement: https://github.com/Netflix/x-element/issues/53 https://github.com/Netflix/x-element/issues/53
Sn0wCoder 6y ago
Thanks, going to read-up on x-element.

Fractal_HQ 6y ago

You can make vanilla web components with Svelte, and Svelte has a much better DX than React, Vue, and Angular. It also performs better thanks to the compile step. I highly recommend checking it out!

eyelidlessness 6y ago
I think the DX claim is pretty subjective. I find JSX much easier to use than all the others mentioned, and a great deal more flexible. The ease of use being that it’s just JavaScript (or more importantly TypeScript), with some DSL. That means it follows all the other rules of the environment in which it runs, and uses all the same tooling. It also produces a data structure that’s renderer-agnostic, so it’s trivial to adapt to different platforms and build targets.
- ath92 6y ago
  Well JSX is not really just javascript/typescript - it needs to be transformed first, just throwing a .jsx file into a script tag won't work. It does compile down to just javascript, but the same can be said for svelte. I can see the argument for JSX being more flexible, given that you can store little bits of JSX in js expressions, something you typically cannot do with the other component frameworks. But tools like svelte have their own DX improvements that make things like state management / reactivity arguably a lot easier than React.
  - eyelidlessness 6y ago
    > Well JSX is not really just javascript/typescript Right that’s the DSL part. But TypeScript understands it out of the box, and you can write the same expressions without the DSL by calling the pragma function directly (which I’ll often do for some tooling code that needs to run without a build step). > But tools like svelte have their own DX improvements that make things like state management / reactivity arguably a lot easier than React. Part of the reason I mentioned JSX rather than React. There are great libraries with similar state and reactivity facilities that work with JSX (for example Solid). The cool thing about JSX is that it’s not tightly coupled to any particular implementation.

azangru 6y ago

> Long story short have been looking into standard web components for my next side project and FicusJS seems to check all the boxes. Could you please list the boxes that you were ticking? For example, how many boxes would the following tick: - Preact with htm (tiny, looks very similar to ficus) [0] - LitElement (tiny, very close to native web components) [1] - Svelte (the darling of many since recently) [2] [0] - https://github.com/developit/htm https://github.com/developit/htm [1] - https://lit-element.polymer-project.org/ https://lit-element.polymer-project.org/ [2] - https://svelte.dev/ https://svelte.dev/

Sn0wCoder 6y ago
- Great question. The main thing I was looking for was going build-less and the section of Ficus docs kinda sold me on the idea. Seems we still need to use a dev-server to allow native imports like - https://modern-web.dev/docs/dev-server/overview/ - Which would allow testing and builds (if go that route) - Seems that you can use any renderer (uhtml, lit-html,htm, Preact), so what-ever I learn will be useable outside the Ficus eco-system - Event Bus: Use this model in another project and worked well. - Stores: not sold on the whole redux pattern, but want to learn abit more about global stores to update components - Was in analysis paralysis before finding Ficus and the more I learned the more confused on what I should try next. - Mostly needed to make a decision as I want to dabble with Web-Components but seems starting from scratch is too low level so pick something just a tad higher than that. Thanks for helping me understand my own decision.
- spankalee 6y ago
  I work on LitElement and if you want to use it buildless you can do so with the JavaScript reactive properties API (so you don't need TypeScript or Babel decorators to declare properties) and Chrome 89's support for import maps. Generally, I think an import specifier rewriting dev server like Web Dev Server is the way to go since it'll work with so many other libraries out there.
  - floatboth 6y ago

azangru 6y ago

> I think I want to stay away from build tools until I can’t No typescript then, eh?

runarberg 6y ago
You can always annotate your code with JSDoc comments and type check your code with `tsc --noEmit`, i.e. typescript without the build step.
- eyelidlessness 6y ago
  No strict null checks is kinda a deal breaker tho
Sn0wCoder 6y ago
I use TypeScript everyday at work, and love it. No not a requirement for side projects. When they grow to something more change extension to .ts and go from there.

chrisweekly 6y ago

Stencil is the real deal. /$.02 Edit: ... if you're getting serious about standard web components per se.

Sn0wCoder 6y ago
I have researched Stencil a few times and agree it seems to be like you say 'the real deal'. In time I might end up there but going to take the long way :)
runarberg 6y ago
Question: I’ve done Stencil in the past and quite liked it. I especially liked how helpful the community is on e.g. slack. Now I’m experimenting with lit-element. My initial expression is that it is not as fully fledged out as Stencil is. Do you have any experience with either lit-element or Salesforce’s lightning web components and are able to compare them?
nraf 6y ago
Been using Stencil for the past year or so as a way of extending our Angular app with client-specific apps (eventually looking to open this up to clients to upload their own components / apps). Overall it's done a good job but I still find the build system somewhat esoteric (there are a number of different approaches and it took some effort to figure out the right one for our use case). I have noticed development has slowed down over the past couple months: https://github.com/ionic-team/stencil/graphs/commit-activity https://github.com/ionic-team/stencil/graphs/commit-activity Hoping it's more a case of it approaching maturity as opposed to it being neglected...

crazypython 6y ago

Please add enough documentation to use FicusJS without prior knowledge of Web Components! It's very important for adoption as a framework in its own right with web components as one component.