I found ClojureScript worth it a few years ago. I’ve written two frontend apps (desktop-style interactive single-page applications meant for longer sessions) of reasonable size in ClojureScript. There’s a lot of non-glue code there (in fact mostly non-glue code, given the interactivity and statefulness of the applications).
Very little language and library churn has made maintaining them very straightforward really, and I won’t be rewriting them any time soon. Being able to use DataScript nearly made the choice worth it on it’s own!
The reason I’m mostly using TypeScript these days (for new things & backend code) is that it’s just too helpful for typing the data structures and reducing the "how many things do I have to keep in my head" burden. My TypeScript (like my ClojureScript) is mostly just functions and data structures (avoiding classes, inheritance, etc), and I avoid using any of the more complicated TypeScript features as much as possible.
It’s kind of heretical, but if Clojure had a well-adopted gradual structural type system (essentially what TypeScript has done for JavaScript) then I would find it hard to not pick Clojure for most things.
I can see why Clojure is seen that way ("advanced", "powerful"), but a big piece of it’s design is Rich Hickey’s view that "we can make the same software we're making today with dramatically simpler stuff."
Learning Clojure has made working in other languages much harder for me - pretty much all of my Clojure programming is functions plus transforming data structures (mostly maps). So few concepts to keep in your head!
The majority of my work is in TypeScript these days, and I always write the most Clojure-y TypeScript I can manage.
The rules engine direction is definitely an interesting one, hopefully there’s more exploration into that in the future.
For my needs now I actually wrote something pretty hacky[1] to get a 'reactive' version of DataScript’s Entity API.
As Nikita mentions in the article, I’ve found that most of the time I don’t really need queries in the UI, and so the entity API ends up fitting quite well – except that it’s non-reactive.
The `reactive-entity` library implements a reactive version of (most of?) the entity API, so you can pass entities in/through components, and then the components only re-render when the attributes accessed within those components change (including attributes accessed on other entities through refs).
Loads of room for improvement but I’ve used it successfully in a couple of projects.
Not sure which model you have, but I have the MA750i. Really pleased with them.
Used to have VSonic GR07s, but the cable became broken. The build quality on the MA750i seems much better, so I’m not expecting the same outcome for these.
Using Markdown means no constraint on what software you use to edit your posts, which is really nice.
Another advantage to using a static site generator is your blog will be (generally) fast to load, secure, and it will be really easy to find somewhere to host it for a low cost (or even for free).
I completely agree with this. I am working on a web application at the moment, and the server is very minimal. It just handles supplies a JSON-returning REST API, the index page, and some WebSockets stuff.
Doing things this way is quite nice, and forces separation between the client application and the server application. It makes the web application just a client, on an equal footing with any other client (iOS app, Android app, desktop application etc).
Thanks a lot for the feedback, I really appreciate it.
I should have probably made it clear that this is really only a little side project, with the aim being to make back the small amount it costs me to run. Sorry for the confusion.
I wanted to differentiate it from Chess.com by making it simple, which is what I didn’t like about Chess.com. With that in mind, it is designed primarily for casual players.
I strongly agree with your thoughts on the signing up process, and I’ll definitely work on that.
Thanks again for your feedback, it's given me a lot to think about.
Not trying to be negative, as I haven't used elementary for any real amount of time yet, but: whenever I glance at the 'e' icon it reminds me of a negative action sign. Like a 'No right turn' road sign, or something similar. Not a problem once you're used to it, I suppose.
You should definitely check out Rework by 37signals. Although not in-depth, it definitely makes you think about the value of some of the more traditional notions.
I found ClojureScript worth it a few years ago. I’ve written two frontend apps (desktop-style interactive single-page applications meant for longer sessions) of reasonable size in ClojureScript. There’s a lot of non-glue code there (in fact mostly non-glue code, given the interactivity and statefulness of the applications).
Very little language and library churn has made maintaining them very straightforward really, and I won’t be rewriting them any time soon. Being able to use DataScript nearly made the choice worth it on it’s own!
The reason I’m mostly using TypeScript these days (for new things & backend code) is that it’s just too helpful for typing the data structures and reducing the "how many things do I have to keep in my head" burden. My TypeScript (like my ClojureScript) is mostly just functions and data structures (avoiding classes, inheritance, etc), and I avoid using any of the more complicated TypeScript features as much as possible.
It’s kind of heretical, but if Clojure had a well-adopted gradual structural type system (essentially what TypeScript has done for JavaScript) then I would find it hard to not pick Clojure for most things.