I've been working on https://stacks.camera - it's an idea about overlaying the previous picture when you're taking a photo so you can create a timelapse or animation.
Most of the challenges are around handling images & rendering, but I've also been playing with Passkey-only authentication which I'm finding really interesting.
It started as a "traditional hack day" with themes, teams etc, but we've morphed it into a more casual get together with random people working on fun stuff. We'd love to get more people involved!
I've been working on this over the last couple of weeks. The idea is that you can can start a session (click the number at the bottom and choose "independent"). Then other devices can subscribe to it (by entering the id as 'other').
I've built it for:
* demos during talks
* workshop/hack sessions
…seems to work okay so far, but I'd love to know what people think.
0: If it meets the guidelines, this might make a good "Show HN", because there is something to play with and want feedback. Guidelines: https://news.ycombinator.com/showhn.html
1: Right now, the page does not pass the 'what is it?' test at a meaningful level. I mean I know I'm looking at some JavaScript and something that looks like it's output, but after reading your comment that's not the important bit.
2: For feedback purposes, I think providing instruction/explanation on the page would be a big improvement. That could be as simple as the explanation you just provided. The implementation could be as minimal as commenting the code or more elaborately an HTML "header".
3: As a tool shared with other people, 'What it is' is the first thing people need to know. So a "product" landing page (could be as simple as text) is probably appropriate. to move instructions out of the implementation. A more elaborate version might have a hyperlink to a code repository...'how to get it' is probably the second piece of infrastructure for a "product".
4: Using Firefox, "back" was broken.
5: It's not clear what javascript functionality is available and what is not. I could create DOM elements but not add them to the output. That's the sort of documentation that a 'product' needs.
Yeah, there is a bit of an overhead with that. Module server - https://github.com/google/module-server seems like quite a good solution. Though I'd agree, for a large number of sites it's far better to bundle them up.
This is a neat idea, however, I ended up avoiding this approach myself on the last big project I did because my personal bugaboo is mixing metadata (requirements) with data (code). Hardcoded dependencies between JS modules leads to front-end spaghetti -- to me it's only a marginal improvement over inline script/style tags. It forces frontend devs to know too much trivia about how the backend/devops code actually makes the sausage.
A JS module or HTML widget should be able to declare what it needs without hardcoding how that dependency gets fulfilled. (eg. if it's loading on a local dev box, do this, in production, do that, running server-side in a Node.JS setting or in a test suite, do this other thing.)
So the system I built allows devs to declare the resources needed by a feature, then the asset management system converts those requirements into LABjs script loader code that gets output -- more of a makefile sort of approach. That means devs can write more general, reusable, testable JS modules (and corresponding HTML templates) that can load through a script loader for better performance, but aren't tied to a particular deployment environment or how the script loader works under the hood.
I wish there was a more natural way for logical components on the page to declare the resources they need without mixing code and metadata. HTML Web Components, for example the [Polymer project](http://www.polymer-project.org/), are possibly a step in the right direction, but I don't think they address intelligently lazy-loading requirements.
We're doing something similar with YepNope that is included in Modernizr but it's not as simple as yours. We ran into problems where if there were multiple elements on the page with that dependency (usually a jquery plugin), only one would end up getting initialized. We ended up coming up with a complicated queuing system that queues up all of the initialization requests when it detects that it is in the process of being loaded, and fires for each in the queue after the dependency is loaded. I'm definitely curious to look into your method in terms of multiple items that need to each be initialized and how this is handled with your context require method or require in general.
Ah, I've not had to deal with sharing between multiple elements yet - I'm kind of hoping that when I do require.js would give quite a solid base for it. YepNope seems like a good choice for this kind of thing, especially that it can bring in css assets too. Would be awesome to bring in all related assets for a element
That's the minus sign on the bottom right - it's for zooming the css list so that it's all in view (it was originally built to see if appended styles were more specific on a page).
thanks. Yeah - it's not as useful as something like css profiler, I built it to work out if there were ways that I could architect my css in a more efficient way.. Though it looked cool, so I threw it online!
