Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FicusJS

docs.ficusjs.org

Post reply on HN
Print view View original

61–66 of 66 posts

Re: FicusJS

#61

Post by maga »

roopawl wrote: post #43
spankalee wrote: post #19

Earlier quoted context omitted.

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.

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

Re: FicusJS

#62

Post by nicoburns »

edoceo wrote: post #4
Sn0wCoder wrote: post #2

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/Catal…

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.

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)

Re: FicusJS

#63

Post by [deleted] »

Sn0wCoder wrote: post #46
roopawl wrote: post #42

Earlier quoted context omitted.

These descriptions are helpful for a very focused view of one piece of a project. As somebody who writes lit-element every day, I miss React and Angular like crazy for everything else they solve and provide.

Interesting comment. Hopefully after building something with Ficus I can better appreciate Angular. The biggest issue I have is updating projects. Its fine if you only support 1 application but when you have 2 or 3, they start to end up on different versions and when you get back you have to spend a month updating to the latest versions, instead of adding tangible value to the product. Maybe I am just bitter as start…

[deleted]

Re: FicusJS

#64

Post by nicoburns »

Sn0wCoder wrote: post #46
roopawl wrote: post #42

Earlier quoted context omitted.

These descriptions are helpful for a very focused view of one piece of a project. As somebody who writes lit-element every day, I miss React and Angular like crazy for everything else they solve and provide.

Interesting comment. Hopefully after building something with Ficus I can better appreciate Angular. The biggest issue I have is updating projects. Its fine if you only support 1 application but when you have 2 or 3, they start to end up on different versions and when you get back you have to spend a month updating to the latest versions, instead of adding tangible value to the product. Maybe I am just bitter as start…

Try React. Breaking changes are few and far between, generally very easy to update to (a few hours at most for a medium sized app), and they almost always introduce new "new way" of doing thing at least one release before the old way is removed (if it ever is).

Re: FicusJS

#65

Post by eyelidlessness »

ath92 wrote: post #59
eyelidlessness wrote: post #8

Earlier quoted context omitted.

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 t…

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…

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

Re: FicusJS

#66

Post by roopawl »

spankalee wrote: post #57
roopawl wrote: post #42

Earlier quoted context omitted.

These descriptions are helpful for a very focused view of one piece of a project. As somebody who writes lit-element every day, I miss React and Angular like crazy for everything else they solve and provide.

What exactly do you miss?

Everything, really.

- Battle tested choices for libraries

- Documentation outside of our own (O'reilly books, online courses, etc..)

- SO posts about issues and sticky points

- Patterns for implementation (lack of these is shitty for JR devs. The only place to learn is PR feedback)

- Popular style guides

- IDE plugins

...and many more. Like being able to list POPULAR_LIBRARY_FROM_JOB_DESC on a resume when I can finally leave this job where leadership prioritized the browser's needs over dev comfort and productivity

Also, the advantages of web components and shadow DOM have never shown up. They only make CSS and browser testing more difficult

Post reply on HN