11 ms·
FicusJS
- Sn0wCoder 6y agoHi 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 agoNo 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 agoI 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 agoMy current favorite is RiotJS. One can still prototype things w/o ceremony in a single static html page + the tags to prototype
- nicoburns 6y agoHave 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 agoThe 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
- Fractal_HQ 6y agoYou 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 agoI 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 agoWell 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 agoI 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 agoYou 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 agoNo strict null checks is kinda a deal breaker tho
- Sn0wCoder 6y agoI 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 agoStencil is the real deal. /$.02 Edit: ... if you're getting serious about standard web components per se.
- Sn0wCoder 6y agoI 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 agoQuestion: 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 agoBeen 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 agoPlease 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.
- ddevault 6y agoOh good. Another one.
- colordrops 6y agoHow is performance compared to something like LitElement, which does bare minimum DOM updates in place? Also, does this have any functionality to support data binding? Passing values down a hierarchy of components and injecting them into the DOM is half the battle with web components.
- floatboth 6y agoThe DOM update mechanism is part of lit-html, not LitElement. This thing allows you to plug any rendered in it seems, but the examples all use lit-html.
- Sn0wCoder 6y agoThis is how I am reading the docs also. Not super obvious depending on how familiar you are with Web Components to begin with.
- colordrops 6y agoI was implying LitHTML in my question, but yes, it's pluggable in LitElement. So I'll rephrase, how does it compare to LitHTML?
- eat_veggies 6y agoInitial impressions: Looks like a relatively new project -- only 59 commits, all by one person, starting from last September. And based on a GitHub search for "ficusjs," it seems that no other projects mention it. It's only a bit over a thousand lines of code, and based on a cursory glance, the code is in pretty good shape. It should be able to fit entirely in your head, and for a lightweight framework, that's a good thing. The API itself reminds me of the good old React.createClass({ ... }) days and I wouldn't be opposed to using it. Overall it looks promising for building an MVP, and shouldn't be horribly difficult to transition to a more complicated framework when needed :)
- shuringai 6y agoand what is the problem with that? "Single guy made a good looking and so far working product in only 59 commits since september" is a different way to present the same facts.
- crazypython 6y agoMinimalist web frameworks are better in my opinion. Less code that can break, less friction between you and DOM.
- tomcam 6y agoDid GP say there was a problem?
- el_dev_hell 6y agoLanguage is so interesting. You read the parent comment and took it as throwing shade. I read the parent comment and took it as pragmatic admiration.
- erklik 6y agoHonestly, I also took it as throwing shade. I had to read the whole thing and realised that GP clearly wasn't throwing shade. I am wondering why I initially thought that. Maybe a mindset of inherently better software created by Teams that's instilled within us these days could be a part of it. Trusting a lone programmer, it's harder because you have to reject the "programming".
- eyelidlessness 6y agoThis does look cool. I wonder if there’s any interest in supporting JSX?
- dan-robertson 6y agoI feel like I could benefit from some sycophants in the comments here as I’m not really sure what exactly this library is for and how it compares to other web frameworks. I haven’t closely kept up with JavaScript frameworks since I stopped regularly writing JavaScript nearly 10 years ago, so maybe there’s no hope for me but reading the comments it seems other people are also asking similar questions. I think my main question is how it differs from (e.g.) react: is the goal to be fast or to have few or different dependencies. Or does it solve different problems to react (or fail to offer solutions to the problems that react was meant to solve)?
- qbasic_forever 6y agoWeb components = build your own custom HTML elements (in a nutshell). Instead of building complex interactive things with <div> <span> etc. and a mess of styling & JS, you ship a JS file and users create in their HTML <date-picker>, <file-open-dialog>, etc. that you defined. React = component-based JS single-page app architecture, using a fully virtual DOM and event system, and a new template language called JSX to greatly simplify the dev experience. React and web components are kinda orthogonal ideas. React gives you a framework for building apps using React's design choices (including breaking your page into small reusable JS components, much like web coomponents allow too). But React goes significantly further and has opinionated choices about how to build your app, how to template your components, etc. Web components just give you a framework-independent way to ship new elements to browsers and users--that's it. You can (in theory) actually make a web component that wraps around a React component if you were really motivated. Why you see so much buzz and mention about web components these days is that browsers have improved _greatly_ since React was brand new. Many of the reasons to reach for a big framework like React have gone away. You don't have to rely on a super complex build system, bundlers, webpack, etc. to ship your JS to users anymore--mainstream browsers have support to import JS modules directly. You don't have to template your components in JSX and add all the baggage and complexity of a build transpilation step--you can use ES6 template literal syntax. And that's where stuff like Ficus appears to fit in. It's for folks who don't want to pull in the complexity of a huge framework like React, but still want to build pages with components instead of a mess of imperative JS, jquery, etc. There's a whole bunch of little micro frameworks like this popping up--check out Haunted for another example. I think a better comparison if you want to research things further would be comparing React with a web component-based framework like lit-element. Lit-element uses web components for its components, but it adds on a lot of opinionated design choices in a similar vein as React. Is one framework 'better' than the other? Well... it entirely depends on your needs and preferences. They're all capable of building great pages and apps, it's kind of like fussing and fighting over the brand of paint that you might use as a painter.
- vardaro 6y agoWhy this over react, vue, or angular?
- runarberg 6y agoNot author, but this looks like a set of three small functions for a) creating web components, b) managing app state, and c) pub/sub event bus. It seems to focus on creating web components first and foremost, and then provides a couple of utilities to interact with them in a application. React, vue, angular, etc. are more fully fledged frameworks for creating apps. None of them focus on standard web components, and all have their own internal component state + structure. I guess you would want this if you need your components to be standard web components, e.g. if they are consumed by a parent app written in a different framework. So maybe a comparison with Stencil[1], lit-element[2], or LWC[3] is more apt. 1: https://stenciljs.com/ https://stenciljs.com/ 2: https://lit-element.polymer-project.org/ https://lit-element.polymer-project.org/ 3: https://lwc.dev/ https://lwc.dev/
- hardwaresofton 6y agoSo I recently got around to writing some code around a similar idea — enabling people to build websites using only components by treating data (the remaining bastion) as web components: Demo page: https://mrman.gitlab.io/services-as-dom-elements/ https://mrman.gitlab.io/services-as-dom-elements/ Blog post describing the idea: https://vadosware.io/post/sade-pattern-services-as-dom-elements/ https://vadosware.io/post/sade-pattern-services-as-dom-eleme...
- Sn0wCoder 6y agoInteresting read. I knew it was possible but think this is the first time seen so many web component libraries used on 1 single page. Bookmarked.
- hardwaresofton 6y agoOh yeah, that was also something that ended up being a nice side effect of the insane amount of yak shaving I did and a nice way to sell the post to r/javascript -- I got a chance to look through the world of native web components and get a feel for most of the popular libraries. I personally think I'll choose lit-element in the future for web components I build, it was by far the best to use and was least-surprise (which I value more and more these days).
- gtm1260 6y agoI was hoping for this to be a project that helps you draw ficuses on websites
- stanislavb 6y agoHere it is the github repo https://github.com/ficusjs/ficusjs https://github.com/ficusjs/ficusjs