marcuswestin

“Please study the material on https://modern-css.com/ and write a skill.md and an AGENTS.md that succinctly utilizes all the content”

Or maybe even! “https://modern-css.com/ is very cool. Could you include a skill.md or Agents.md for this?”

Or! “Please do: https://news.ycombinator.com/item?id=47030502“ =]

</end_snark>

Soundboks 4 sync wirelessly with each other. They’re also battery driven and absurdly loud, so perfect for bringing outdoors or a dance party somewhere.

They just had a 30% sale for the holidays though, so might not be worth getting them at full price

- Deep Work

- Sapiens

Store.js is here to make life easier for all web devs, beginners and pros :) I've concluded that adding an async API in addition to the sync one for access to the more powerful storages makes total sense though! Off the top of my head I'm leaning towards new methods for the async versions, and then probably adding localForage as a new storage.

Thanks for taking the time to make the case!

Bonus points for best use case on the page :)))

Eclectic as it is, I think we should totally consider making it a plugin/storage! If you open an issue with links to the relevant material I'd really appreciate that. Thanks!

Totally! I created an issue to pull this info together: https://github.com/marcuswestin/store.js/issues/189

Check back in coming days for more details.

Store.js will soon have pluggable support for localForage (either by implementing similar functionality in separate storages, or by simply adding a pluggable storage which uses localForage under the hood).

There are a few benefits to using store.js, such as full cross-browser support and useful plugins, but the biggest meaningful value-add over localForage is probably the availability of a synchronous API that allows you to read and write values without callbacks, promises, etc.

In my experience you only want to use asynchronous APIs when you have to, since they add a fair amount of complexity, are a common source of errors, and are harder to debug properly.

But yeah, check back later and you'll likely find that store.js supports the same storages as localForage, in addition to the its other functionality.

I'm genuinely interested in supporting all use cases!

If you create an issue at https://github.com/marcuswestin/store.js and describe your use case in more detail we'll figure out what the right answer is.

Thanks!

I created an issue to investigate viability and usefulness :) https://github.com/marcuswestin/store.js/issues/193

Except when a value has already been stored previously without JSON.stringify (in which case JSON.parse will throw), or you need a default value if unset (e.g `store.get('username', 'anonymous')`, or ... :) But I also see your point that sometimes the very quick and simple solution can be useful!

On the other hand, synchronous interfaces tend to be less error prone and simpler to work with (and more enjoyable...? :)

There is an active issue to add the async indexdb/websql storages to Store.js (https://github.com/marcuswestin/store.js/issues/181) so that they can be used when needed (e.g when you need to store many tends of MGs of data), but for 90% of your use cases the simplicity of the synchronous store.js API may likely save you a meaningful amount of code and callback/Promise/stack trace debuggery :)

I think something like store.js ends up being genuinely useful for anyone building functionality that depends on localStorage. More often than not you find yourself either having to deal with issues that store.js solves for you (E.g not breaking your site in Safari private mode) or requiring extra functionality that already exists as a small store.js plugin. (E.g expiring keys, default values, etc). All of these are things you can of course do without a library, but at that point you're reinventing the wheel a bit and not benefitting from all the automated testing that ensures cross-browser correctness. With that said, I agree there are times when just a quick read/write directly to localStorage can be the right call, but by default I think it comes back to bite you one way or another more often than not :)

Yes, simpleStorage is good too!

I believe store.js addresses all the use cases of simpleStorage, and then some (E.g Safari private mode, etc).

If that's not the case I will make it work for your use case :)

Thank you :)

Hey, I'm not sure what an angular2 version would look like or do. Could you please open an issue with a more detailed description of what you need? I'll help if I can!

Cheers

Created issue: https://github.com/marcuswestin/store.js/issues/183

Will tackle a bit down the road.

Let's create a plugin that automatically does compression!

I believe syncing could live in a plugin! Would you be up for creating an issue and quickly describing your requirements? I'm genuinely interested in supporting every real use case!

Duh, of course! Sorry, 3am and not too sharp in the nut at the time :)

I'm genuinely interested in supporting every needed use case. Off the top of my head, I could see e.g get returning a promise in some cases, or passing an optional callback to get, or having a get.async... Either way - I'll have it in the back of my head and see what can be done.

If you open an issue on GitHub we can continue there. Cheers!

Duh, of course! Sorry, 3am and not too sharp in the nut at the time :)

I'm genuinely interested in supporting every needed use case - would you be up for creating an issue? Either way I'll have it in the back of my head and see what can be done.

Cheers, Marcus

That's really nice to read :) thanks!

Hi! Allowing users to add the plugin behavior they want is the whole idea, so let's do it :)

Could you please open an issue? If you include a short snippet with the rationale for what and why you need it that would help guide the discussion.

Thanks!

You can back it with any storage you want :) See https://github.com/marcuswestin/store.js#write-your-own-stor... for a quick explanation of how you'd do that.

Almost! Except if you want to store objects/arrays/numbers (localStorage only supports strings), or want your site to work in Safari Private mode (where localStorage breaks), or if you have to support legacy environments with old browsers (like many government services), etc etc etc :)

I don't know when WebSQL would be better than other storage alternatives, but yes, you could easily add WebSQL storage :)

The rationale behind the new architecture is to make it trivial to write new backing storages - see https://github.com/marcuswestin/store.js#write-your-own-stor... for a quick explanation of how you'd do that.

This is also true for adding new functionality, which sits "on top of" the storage (and is agnostic to whatever particular storage is being used). Here's a list of plugins that come out of the box: https://github.com/marcuswestin/store.js#list-of-all-plugins, and here is a quick explanation for how you'd write your own plugin: https://github.com/marcuswestin/store.js#write-your-own-plug...

Store.js was originally released on HN in 2010 :) https://news.ycombinator.com/item?id=1468802

It's live on tens of thousands of websites (like cnn.com!) and has seen lots of improvements over the years.

Store.js version 2 is a full revamp with pluggable storage (it will automatically fall back to one that works in every scenario by default), pluggable extra functionality (like expiration, default values, common array/object operations, etc), and fully cross-browser automatic testing using saucelabs.com.

Feel free to ask any questions! I'm going to sleep now, but I'll make sure to answer in the AM.

Cheers!

Hi Matt :)

ASAPP - asapp.com/adventure - NYC ONSITE

Reinventing human computer interaction, starting with customer service.

What do the best software engineers, PhD's in Physics, Mathematics, Computer Science, and industry designers have to do with customer service? Everything.

Our short-term mission is simple: Make customer service awesome for consumers, and cheap for companies.

How? We have found a hidden opportunity. It allows us to reinvent a tool used by every American today, save big American companies hundreds of millions of dollars per company per year, and (most importantly) lay the foundation for revolutionizing all of human-computer interaction in the long term.

Our short term plan lays out concrete steps for radically improving large companies' customer service in the immediate future. This plan stands to create a viable and huge business by itself. However, that was never sufficient to truly intrigue us. We are tackling this problem today because it gives us the three things required for our long term vision of seamless human-machine interaction everywhere: Immense amounts of labeled interaction data (e.g text conversations, voice recordings, etc), world-class NLP expertise, and revenue to fund it all.

More details: https://asapp.com/adventure

I think this is a great and well intended effort.

One of the biggest use cases for Javascript is to manipulate and create DOMs. jQuery solved the manipulation part beautifully, but DOM creation remained a hassle. Lots of templating solutions have been attempted, but none of them seem to hit the sweet spot just right (that's a primary reason why there are so many).

JSX is a novel contender that may be just right - even if it's not, it will hopefully push us as a community towards a better solution by offering a very new approach with its own benefits and problems.

Thanks to the peeps at fb for taking the time and effort to make JSX bigger than just reactjs!

I also said:

(and with all that said, the most important thing to consider is this: what tool will best allow you and your team to build and maintain your intended product?)

I'd defend the statement you quoted like this: all languages are type. Dynamic languages simply have exactly one expression type, "any". Specifying multiple types affords you strictly beneficial abilities. Static type checks is probably the most significant. Performance improvements and highly specific and accurate code editing assistance (e.g auto suggest) can also be significant.

But yes, you're absolutely right. Nothing but sincere effort, lots of practice, and critical thinking can make you a better programmer.

At the same time, a great carpenter becomes even so much better with a properly weighted hammer and an accurate lever.

:)

Go