radex

Thanks for the chuckle :D And of course you use nixos :]

That could be interesting! Curious: are you taking about a plain object spread, or are you talking about JSX spreads? The latter has more overhead. Also, which JS engine?

BTW. I recently measured the spread operator in a microbenchmark. Interestingly, while the native spread was faster on Hermes and JSC, it was slower on V8/Chrome, and it's faster there to use `Object.assign()`, i.e.:

['@babel/plugin-proposal-object-rest-spread', { loose: true, useBuiltIns: true }]

Appreciated!

Thanks! There's a preliminary PR with a discussion here: https://github.com/facebook/hermes/pull/933 (and broader context here: https://github.com/facebook/hermes/issues/811 ). But we'll see if there's any interest on Hermes' side to merging it. They definitely want to improve the parser, but it's unclear to me if they want to take on the simdjson/simdutf dependencies.

Browser-based apps have use cases even when you reject PWAs generally as a replacement for native apps. Trying out a new tool quickly, or short-term when using a tool with a customer, in enterprise where you can't install native tools, etc...

IndexedDB is a joke of a database. Yes, it can store data, and you can create a very simple index, so it's _technically_ a database… But its ability to express queries is borderline useless for all but simplest use cases, it's slow, and it's very inconvenient to use. So solutions exist that range from giving IDB a simpler, more modern API, all the way to using IDB as a dumb storage medium to a fast in-memory database.

You can use multiple tabs but to have more than one write to the DB and not be overwritten relies on (online) sync.

The problem is that Watermelon assumes a consistent view of the entire database, so you can't have multiple writers - at least not without synchronous notifications from IndexedDB (not a thing), leader election (cannot be made reliable), or some design sacrifices. To be reconsidered in the future...

IndexedDB is a _bad_ API, and making many small read/write operations on it is absurdly slow. This is one of the reasons why WatermelonDB on web only uses IDB as a dumb storage medium but actually does all the database'y things in memory. You won't reasonably scale to gigabytes this way, but for most PWAs this is plenty enough and MUCH faster in practice. Certainly far faster than network.

You’re not wrong

not very familiar with apollo, but I don't see why not. But just be aware that Watermelon works best as a full local database copy (that synchronizes with the server), not just a cache.

No, Watermelon is a local app database. But you can plug it into a sync engine to synchronize with the server (and then from the server to another device) — it's up to you

It's possible, but Watermelon is specifically designed to be a local database, not meant to run on a server.

Not familiar with either Gun or Vue. I'll look into the former, and as for the latter — Watermelon does not actually depend on React. If one can supply a way to hook an RxJS observable into Vue (a la higher order components in React), it should work perfectly fine. Pull requests welcome!

See: https://news.ycombinator.com/item?id=17960347

Sync is mostly there, but undocumented :/ Coming soon…

That's a fair description, yeah!

I'll be really curious to hear your feedback on GH if you try it. We've been using it internally in dev for a year, but we've just released this as open source, so there's probably a ton to improve on.

Yes! Planning to release a few helper functions and document exactly what the procedure is to synchronize with a server. Internally, we know it works.

It's easy to be cynical on HN, but to the best of my knowledge, no other solution for React Native checks all the boxes we need.

And it's not like reinventing the wheel (it still uses SQLite), more like inventing better suspenders for the whole undercarriage ;)

A mobile app database. It can probably scale to hundreds of thousands too, but very few apps and very few users of such apps would actually have THAT much data.

The point is that most current solutions for React Native apps start being super slow when you get to 1000s, or have other issues (like using SQLite directly doesn't give you observability)

Yep, if you can support some (relatively basic) queries, and CRUD operations, you can plug in essentially any database, and bridge on any platform. Think Electron, SQLite on native macOS, heck, you could use Realm as the underlying database if you so preferred...

Agreed! IDB is simpler in some ways, but having a real relational database is a lot better for many advanced applications — and also can be more easily used for porting to different platforms, since you can run SQLite on any native platform

I'm not an expert at Realm, so I might get some details wrong, but briefly:

- You can't run Realm on the web (not as a database, offline), but you can with Watermelon

- Realm is _a_ database, Watermelon is a more universal database framework that can be backed by any underlying database via an adapter

- Realm is more than just a database, it's also a whole app development platform. And it's designed to sync with a proprietary Realm cloud service. Watermelon is just a local database, but it tracks changes in the database so you can plug it in and synchronize with an arbitrary backend

- I heard that Realm (on React Native at least) doesn't perform super well when you get to many thousands/tens of thousands of records, but i haven't tested it yet myself, so take it with a grain of salt. Watermelon always does lazy loading so it doesn't really affect performance how many records total there are.

Yeah :/ There used to be this thing called Web SQL (which really… was SQLite)… but… people didn't like it and it didn't catch on. So on the web, Watermelon uses LokiJS, which isn't perfect, but still works well.

SQLite gives you just the "data fetching" part. But if you're building a React/RN app, you probably also want everything to be automatically observable.

For example, if you have a todo app, and you mark a task as done, you'd want the task component to re-render, the list to re-render (put the task at the bottom), and update the right counters (the counter of all tasks, and a counter of all tasks in ta project), etc. I hope you're getting the point.

Watermelon is an observable abstraction on top of SQLite (or an arbitrary database), so that you can connect data to components and have them update automatically

The requirement is to speak Polish. You're right, that's what we should've put there. (In practice, though, it's extremely rare that someone speaking Polish wouldn't be a native.)

No, that's not what I meant. Everything is relative, though — if you live in a crazy expensive place like San Francisco, yeah, it's not gonna work.

Yeah, it's weird to put it this way. The thing though is: the whole dev team at our company speaks Polish, so it would be very uncomfortable to be the only person who doesn't.

JavaScript developer at Nozbe | Poland or anywhere (we're remote!)

We're looking for talented programmers who are passionate about building amazing applications and are great at front-end development (all Javascript-related). It is necessary that:

  * You love programming and newest technologies
  * JavaScript, CSS3, HTML5 are your best friends
  * You have developed mobile web apps
  * You want to work from home and can be very independent
  * You know English very well so you can read and comment in this language
  * You are willing to learn and develop all the time
  * You have good communication skills
  * You are open-minded, honest and friendly
  * You can write clear and intelligible code documentation
  * You must be Polish (our core team is Polish)

  * Know server-side programming languages
  * Have some experience in using Node-Webkit
  * Have worked on mobile apps development using the PhoneGap technology
  * Have already developed mobile apps for Windows Phone, Windows RT and Blackberry
  * Have any experience with native app development for Android or Windows
  * Have worked on the project managed according to agile SCRUM methodology
  * Have used Git for code management
  * Having read the book by David Allen "Getting Things Done" is a bonus, too :-)

  * No office - everybody works from home the way they want, at the time they want
  * Great team - we all communicate over the internet and actually like each other :-)
  * Regular "Company wide meetings" - we spend a few days in some cool place together having fun and getting to know each other in real life - and the company pays for everything :-)
  * Competitive salary - you don't need to move to a bigger city or another country to earn more, you can earn a good salary by working for a Polish-based global company
  * Growth - Michael Sliwinski - our founder and CEO is focused on growth and he wants all of us to grow and be better and love what we do.

If you think you're the candidate for the job, send us your CV along with your nickname on GitHub. Tell us what you did in the past and what you're working on and what is your favorite part of being a programmer.

It'd be great having you on board!

More info: http://nozbe.com/jobs/

Absolutely!

[blatant self-promotion and links to all of my apps]

Oh and the thing that impressed me is that it's not just the typical BS-filled self-help book. The Power of Habit appears to be very well-researched and doesn't promise wonders, just shows you how habits work and how you can influence them.