HN user
Nice work! I have a no-dependencies project with somewhat similar goals in frameable/el[0], which takes more inspiration from Vue in its interface.
WebComponents give us so much, but just not quite enough to be usable on their own without a little bit more on top. Reactivity with observable store and templating with event binding are the big missing pieces.
The main reason is that they're too low-level to use directly.
They do a lot, but stop just short of being useful without something of a framework on top. I tried hard to use them directly, but found that it was untenable without sensible template interpolation, and without helpers for event binding.
Here's my shot at the smallest possible "framework" atop Web Components that make them workable (and even enjoyable) as an application developer:
https://github.com/dchester/yhtml
It's just ~10 SLOC, admittedly dense, but which make a world of difference in terms of usability. With that in place, now you can write markup in a style not too dissimilar from React or Vue, like...
<button @click="increment">${this.count}</button>
If we could get something in this direction adopted into the spec, it would open up a lot of use cases for Web Components that it just can't address as-is.
Nice writeup. We're working on a framework with similar goals, here: https://github.com/frameable/el
Reactivity, composability, templates, etc with no dependencies, in ~150 SLOC.
Agreed that investing in standards is always a good bet. But at the same time, we have so many web frameworks in part because what is spec'd in plain JavaScript/HTML/CSS is not quite high-level enough to be really be a productive foundation just on its own. Going all the way back to raw `Document.createElement` will come with its own special pain.
With the WebComponents movement though, we are getting ever closer to being able to rely on native browser functionality for a good share of what frameworks set out to do. We're not all the way to bliss without frameworks, but for what it's worth here is my 481-byte library to support template interpolation with event binding in order to make WebComponents pretty workable mostly as-is: https://github.com/dchester/yhtml
I also sometimes enjoy this approach of starting from absolutely nothing.
Instead of taking the path of starting with DOM manipulation and then going to a framework as necessary, I've kept really trying to make raw web components work, but kept finding that I wanted just a little bit more.
I managed to get the more I wanted -- sensible template interpolation with event binding -- boiled down to a tag function in 481 bytes / 12 lines of (dense) source code, which I feel like is small enough that you can copy/paste it around and not feel to bad about it. It's here if anyone cares to look: https://github.com/dchester/yhtml
We have used Automerge a bunch, but found that there is a threshold where beyond a given document size, performance gets exponentially worse, until even trivial updates take many seconds' worth of CPU. That is often how it works when the document end state is exclusively the sum of all the edits that have ever happened.
Our answer was to reimplement the Automerge API with different mechanics underneath that allows for a "snapshots + recent changes" paradigm, instead of "the doc is the sum of all changes". That way performance doesn't have to degrade over time as changes accumulate.
Project is here: https://github.com/frameable/pigeon, with some benchmarks: https://github.com/frameable/pigeon/wiki/Benchmarks in the wiki...
We wrote about our journey[0] to sanity after Tailwind:
The answer is to do it all in strategic moderation: Use a subset of tailwind just for spacing and layout and revel in simple things being simple. Use modular CSS for UI patterns and revel in the readability of your HTML and visual consistency of your UI. And then use custom scoped CSS where required, and revel in interesting things being only as hard as need be, without ruining everything else along the way.
[0] https://frameable.com/company/tech/how-we-found-sanity-in-a-...
This sounds cool. We wrote a git-based CMS[0] that is a little different. It has a nice-enough UI for creating and editing markdown documents, which are stored in git. And then it has a JSON API so that your main site can fetch the content and style / format however it likes. Users log in with OAuth or local passwords and their edits end up as git commits that are attributed to them.
We built El[0] with the goal of making a minimal framework for building web apps. As a data point, it has a built-in observable store, reactive templates, scoped subset of scss, no dependencies, and can almost fit in a single network packet.
I could have chosen to rebuild the entire UI as a template string as a function of state, but instead, it is ultimately more performant to create these DOM helper methods and modify what I want.
I like the effort, but this is basically admitting defeat. Just naively using template strings and re-rendering the whole app on every change of state _is_ too slow, and so the author falls back instead to rendering via a series of bespoke methods that mix logic and template strings and DOM methods all interspersed. It still has all the shortcomings of 00's-era PHP, or piles of jQuery.
It is possible to do one step better than this still with vanilla js, if you use Web Components / custom elements. That way you can have each type of custom element (todo-app, todo-list, todo-item, etc) have its own render function using template strings, and you can still sneak in custom optimizations (like direct DOM insertion when adding and item to a long list instead of re-rendering).
But in the end, it's just so wonderful to be able to have reactive state and efficiently render your app from the state, and forget about all the rest.
We developed El.js[1] with all of this in mind, to be as little as possible on top of vanilla js and web components, to get the reactivity and efficient rendering.
We developed El to be as minimal as possible, while still solving the problem of keeping state and interface in sync:
https://github.com/frameable/el
It's just ~150 lines / 2kb, and leverages existing browser functionality to accomplish most of the hard parts. Has observability, reactive templates, scoped CSS, no need for a build process, etc.
Hey! This project started as a few lines of code that we copy/pasted around to get us reactivity on top of raw Web Components here and there. As we have used it for more intensive internal dashboards and other projects, it has evolved into a nice little alternative to React / Vue / lit-element.
There's a starter repo here if you want to try it out: https://github.com/frameable/el-starter
Frameable | Remote GMT-4 | https://frameable.com/careers
We build next-generation virtual spaces for working together. Tech stack is WebRTC, Node, Vue, WebSockets.
We are hiring for many positions, but especially interested in augmenting our WebRTC capacity, both human and technical. We run our own fleet of mediasoup-powered SFUs, and are working on all sorts of fun and hard problems:
- Large scale testing with 1500+ participants in a call using real headless chromiums
- Voice detection and noise cancellation with wasm/tensorflow
- Being robust to so, so many shenanigans introduced by corporate "adaptive firewalls"
- Geographically distributed TURN servers
- Connection quality scoring and analytics in mediasoup
More on this position here: https://frameable.com/company/careers/streaming-media-engine...
Also hiring for other positions as well including a designer, full-stack engineers, and a QA engineer. It's fun stuff and we are a ambitious, scrappy, delightful team. Come join us!
We built this collaborative wordle game during a hackathon and it turned out to be kind of fun. It's a new word each day, and you can have up to seven people on your team.
For what it's worth, the tech stack is Node / WebSockets / Vue.
Yes, it is true that with this approach, you have to make sure not to edit the text independently from its metadata.
The purpose of an agile process is ultimately to "de-risk your investment" as much as possible.
This idea really rings true to me. Tight iteration/feedback loops are key. Each cycle should introduce value -- either in the form solving user pain points, or providing product learnings on the way to solving user pain points.
Yes, in the end it might amount to more overhead each cycle, than if the team had put their head down and focused purely on producing. But: you end up where you actually want to be! And despite however confident you were at the outset, where you want to be is probably different than where you thought you wanted to be. With Agile you get to learn that part along the way.
Organizing by effort/value has been magical for us. Whether it's working thorugh a punchlist for a product nearing launch, or whether it's proioritizing initiatives for the upcoming quarter -- looking through the lens of what is easy/valuable, hard/valuable, etc, really puts things in perspective.
The easy/valuable stuff is obvious, just do it! The hard/useless stuff is obvious too, just let it be. And then the more important decisions come around which hard/valuable stuff to do.
Either way, all that is much clearer when laid out visually...
We currently support meetings on Google Meet, Microsoft Teams, Zoom, Whereby, team.video, Skype, BlueJeans, GoToMeeting, and Cisco Webex
I think there _is_ support for Webex, even though there's no logo there above the fold.
Here you go! Yeah, I've used a bunch of CM tools over the years, and it always seems like you're learning a DSL of one sort or another, just to have it translate into the bash that you already know.
We put this library together at https://team.video after struggling with "button explosion" in previous projects, where we ended up with an endless sea of subtly different button implementations.
Sometimes the differences were totally legitimate and justified for the use case, and other times it was easy to just not remember or realize that the permutation we wanted had already been painstakingly crafted elsewhere.
When we took a systematic approach to catalog how we were using buttons, we settled on that yes, we really do want a lot of options, depending on the scale of the interaction, how much emphasis we wanted to put on the choice, etc -- but not the infinite flexibility (and so low reusability) that comes with a free-for-all.
So this has really worked well for us after settling on this approach. How have others dealt with the trade-offs here?
Nice, that is a cool concept. Part of the motivation with tragopan was to see if using native scrolling could be a more natural fit especially on mobile, versus the more common way of using transform/translate.
On BigPicture, two bits of feedback for what it's worth:
- Maybe try `user-select: none` while a user is panning? Otherwise I end up inadvertently selecting text sometimes when I try to pan around, especially in Firefox
- I couldn't figure out how to make a given bit of text bigger or smaller, like the demo shows is obviously possible. I did make it happen a few times but then couldn't understand what steps had actually led to the change... Maybe some instructions on that, or just a floating toolbar could help (even though the toolbar-less aesthetic and approach is otherwise pretty nice!)
We use this library on https://team.video for panning and zooming around in screenshares.
It can be really useful if you have situation where a colleague is sharing their hi-res screen, when meanwhile you're on a laptop with a lower-res screen, and you want to zoom in on their terminal or some part of the screenshare so that the text there can be easier to read.
My son had another event this morning -- this time a treasure hunt over Google Meet. There were 16 wonderful, jubilant kids on the call, but only 9 would show on the screen at any given time, which seemed such a shame.
We should really expect to be able to see everyone on the call, in Kindergarten calls, and in meetings at work too. We humans are so well tuned to read each others' facial expressions that we have no problem recognizing reactions/sentiments in small video feeds of our friends and colleagues, even at avatar-size resolutions.
Internally, we've done some tests/prototyping where it's completely workable to have 100+ feeds on the screen all at once, even with some "hero" space reserved for the couple of most recent active speakers.
If you want to host your own, ntf is a good open source option: http://code.shutterstock.com/ntf
If you're building REST APIs with Express and MySQL, check out this project I'm working on called Epilogue: https://github.com/dchester/epilogue
With Epilogue, once you define your models (with Sequelize), from there it's easy to get basic CRUD functionality and endpoints in a few lines of code.