Hacker News Reader

Comment by Sn0wCoder | Hacker News Reader

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/ 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!

View on HN

> 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

[1] - https://lit-element.polymer-project.org/

[2] - https://svelte.dev/

- 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.

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.

How lightweight is Web Dev Server? Back when the official way to go was still polyserve, I've had to make this:

https://github.com/unrelentingtech/es-module-devserver

which is a tiny middleware that uses regexps to accomplish the task instead of dragging in a JS parser :)

Thanks, will give it try.

I don't think you'll ever get away without a build chain using LitElement. If you are, I think your project is a toy, hobby, or very far from complete

I have been using lit-html for years now, and lit-element for a couple years all in vanilla js for evergreen browsers with the only build step being bundling for production. Here is one of the projects: https://cisterna.app

You may want to take a look at lit-html coupled with ApplicationState [1] (disclaimer, I'm the author of ApplicationState)

https://github.com/claytongulick/applicationstate

How does ApplicationState compare to e.g. https://immerjs.github.io/immer ?

Thanks, will check it out. Bookmarked.

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

There's a chance Netflix will port to x-element to be an extension of LitElement: https://github.com/Netflix/x-element/issues/53

Thanks, going to read-up on x-element.

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.

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

My current favorite is RiotJS. One can still prototype things w/o ceremony in a single static html page + the tags to prototype

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)

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!

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.

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.

> 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.

Last I tried, though, certain kinds of value updates didn't work in WC mode and I had to fall back to non-WC mode to finish :(

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.

> I think I want to stay away from build tools until I can’t

No typescript then, eh?

You can always annotate your code with JSDoc comments and type check your code with `tsc --noEmit`, i.e. typescript without the build step.

No strict null checks is kinda a deal breaker tho

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.

Stencil is the real deal. /$.02

Edit: ... if you're getting serious about standard web components per se.

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 :)

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?

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

Hoping it's more a case of it approaching maturity as opposed to it being neglected...

Reply on news.ycombinator.com