lf-non

34 ms·

331.
by lf-non 7y ago
Pretty much all mainstream frontend libraries have moved away from dom based templating (or augmenting dynamic behavior through attributes) for good reason. It simply becomes unmaintainable for anything more complex than basic interactivity
332.
by lf-non 7y ago
Antlr4 supports a javascript target [1] and has parsers for most popular SQL dialects [2] [1] https://github.com/antlr/antlr4/blob/master/doc/javascript-t... [2] https://github.com/a
333.
by lf-non 7y ago
For people who want something similar that is also typescript friendly, I wrote a babel macro that entirely gets compiled away during build. https://github.com/ts-delight/pipe.macro
334.
by lf-non 7y ago
After trying out almost most of the major libraries in the frontend ecosystem I feel that MobX-style observables (in combination with a state-tree abstraction like MST) simply offer the best combination of developer experience and performan
335.
by lf-non 7y ago
Silicon [1] is a similar solution implemented in Rust and can work without browser & Internet. [1] https://github.com/Aloxaf/silicon
336.
by lf-non 7y ago
People who are using solutions like this for slides, please try out pandoc. Pandoc is usually associated with Latex, but in reality its scope is really broad. I have been using it to convert markdown to slides for a while and it works quite
337.
by lf-non 7y ago
top level await doesn't make async operations synchronous. It mostly eliminates the need to have immediately evaluated wrapper async functions that we would have needed so far. (async () => { await foo(); })(); The added benefit
338.
by lf-non 7y ago
Basarat's guide is pretty much the best introductory resource : https://basarat.gitbooks.io/typescript/
339.
by lf-non 7y ago
The biggest advantages of io-ts over the jsonschema based type generation approach is that our data doesn't have to be json and we can handle non-serializable and complex data structures eg. class instances etc. This makes it additiona
340.
by lf-non 7y ago
Availability of recursive-types is a great news for users of libraries like Mobx state tree [1] which heavily lean on inferred & derived types. Circular type references among MST models have so far required quite a bit of ceremony [2] t
341.
by lf-non 7y ago
Yeah, this is something I had hoped for as well. Mobx-state-tree [1] also makes use of generators for asynchronous tasks and typescript's inability to infer types of values returned from a yield is a pain. But fortunately, atleast in t
342.
by lf-non 7y ago
If someone is interested in a similar solution for GraphQL, GRelDAL [1] (authored by me) is an alternative (though it is slightly lower level and requires mapping of data sources through code). Also given support for multiple databases, it
343.
by lf-non 8y ago
People facing similar issues might want to try out GRelDAL [1] (disclaimer: I am the author), a simple node.js library for bridging relational databases to graphql APIs. It supports various strategies for loading associations, including joi
344.
by lf-non 8y ago
InGenR [1] is a similar utility I wrote sometime back. It is similar to cog in that generated code resides alongside the source code. Some differences/advantages are: 1. Generators can be pure JavaScript or declarative dot templates. 2
345.
by lf-non 8y ago
pug is really nice (as is haml). The only reason I bear with the superfluous verbosity of JSX is because it plays well with typescript. The moment you switch to text based templates typesafety goes out of the window. I really wish javascrip
346.
by lf-non 8y ago
io-ts[1] is a great solution for implementing runtime-types. The most interesting feature is that the static type can be "extracted" out of the runtime type so in most cases there is no duplication of information between runtime t
347.
by lf-non 8y ago
Polar looks brilliant. Thanks for creating this and making this open source.
348.
by lf-non 8y ago
Postgraphile [1] is very close to what you are looking for. It is really amazing what modern databases are capable of and at the same time also surprising that most applications in the wild don't use them to the fullest of their capabi
349.
by lf-non 8y ago
This is very interesting. I have been writing a library [1] to bridge relational databases efficiently to GraphQL APIs, and adopted a similar approach towards eliminating the redundancy in the schema definitions. I currently rely on io-ts [
350.
by lf-non 8y ago
From my past C experience I had developed a distaste for clever pre-processors tricks that a lot of people love showing around. However while easing myself into typed languages after multiple years of using ruby and erlang exclusively, I ha
351.
by lf-non 8y ago
Releasing the parser as a standalone library/utility is a cool idea. I'll check into this.
352.
by lf-non 8y ago
This is a blast from the past. Basket notes was my goto note-taking solution for multiple years during college.
353.
by lf-non 8y ago
People who prefer structured outlining (over non linear snippet collections) may find fluid-outliner[1] interesting. After not finding any good signup-free privacy-aware zero-installation solution, which supported both rich text and markdow
354.
by lf-non 8y ago
Purescript by example[1] is the most approachable introduction to Functional programming that I have seen (yet). Even if you don't intend to ever use Purescript itself for application development, the book is worth a read, as an introd
355.
by lf-non 8y ago
Love the concept. But please don't use fonts with ligatures in code snippets on the homepage. Especially when these code examples are actually screenshots which people can't copy. Ligatures may be "obvious" to developers
356.
by lf-non 8y ago
I am not at all contesting the value in the good parts of F#. It was my first foray into a functional language, and I was left seriously impressed. > Do you have specific examples where F# semantics cannot map to JS such that the "8
357.
by lf-non 8y ago
Tangentially relevant: There is a serious and ambitious PR implemeting proper (web-worker style) threading support in Node.js core. https://github.com/nodejs/node/pull/20876
358.
by lf-non 8y ago
> If ocaml gets multicore finished before 20XX, do you think that f# developers who came from outside dotnet could be coaxed to ocaml? I do think that upcoming multicore support in OCaml is very exciting. I am more optimistic that it wil
359.
by lf-non 8y ago
I like F# and believe the author has done an amazing job evolving a functional language on the dot net platform but there are simply too many design choices in F# geared around C# compatibility and limitations of CLR being an object oriente
360.
by lf-non 9y ago
Given that even after a major overhaul, Linkedin's web interface is sub-par wrt. UX as well as performance, I am not sure Linkedin's endorsement really contributes positively towards popularity of Ember.

More ›