It's interesting to compare the game play and design. My game is written in Elm and open source if anyone is interested. This website has keyboard inputs (y or n) which is a good idea. My game only does click/touch inputs.
- Having a global registry of machines does not scale. Anyone building an app won't want to deal with the name conflicts. Having a `displayName` for debugging is fine but that's all. Having people pass the Machine instance to transitions directly is much more reliable/scalable.
- This [...rest] for event handlers is not good. Put those in a dedicated object because if you don't any new prop you add has the potential to break users. It's also bad because it looks like memory gets merged with those methods, making it likely the keys will conflict in view().
- Find a better name for T, it's confusing with Transition. Since it looks like a simple struct, maybe just have people pass {name, to} as plain data.
- You don't provide a rejected Promise example. I am interested how that works since it is something people tend to overlook.
- How the heck do I test my machines?
- A micro-framework that doesn't mention byte-size? Probably worth adding that statistic. My idea of a micro-framework is one that fits in a tweet.
- Write up how you expect this to be used. I don't think you could use this to build a real app because there's no way compose machines, only switch between them. You'd end up with huge machines because UIs are trees.
If anyone wants the Elm architecture in JavaScript there is Raj: https://jew.ski/raj/
I spent over a year building the framework and a set of libraries around it so that the architecture feels natural to JavaScript developers.
There's only a few of us building apps with it right now, but the stories for doing most anything are covered and as of 2 months ago the framework hit 1.0. It is a safe foundation to build on as I don't plan to ever change it.
Last winter I built an application called Subtweet that built on top of Twitter's Direct Message service, using Twitter's API as much as I could to reduce overhead. It is bittersweet that Twitter is improving DM as it makes Subtweet more and more unnecessary to users, but I am so happy to have all of these features built right in. I saw this shift coming when Twitter added multi-user DMing so I had already written the post mortem if anyone is interested.
If anyone is interested in just scrapping links between webpages with JavaScript, I made Slinky (https://github.com/andrejewski/slinky). The API is simple and easily overridable.
Yes, the guarantees provided by true immutability are not met by "const". I wrote the note loosely using the author's expectations and advantages of immutability, not the exact definition. But thank you for letting me clarify.
Also I just noticed with Go's Unicode support we can write `const π = 3.14..` if we really wanted.
I am completely in support of Haskell and functional languages in general. There are some gaps in Go and definitely some glaring problems. But this comparison also only lists the bad. Go is good for what it was intended for which is concurrent programming and server/web application.
For people who have wanted to try this type of programming out but have not jumped the boat from JavaScript to ClojureScript, I created a little library that mixes Backbone and React in a similar model described in the article: https://github.com/andrejewski/reactbone
It takes away a lot of the data-binding cruft that you find in Backbone.View and works well with React without making you switch languages, design paradigms, or add new libraries. The Backbone component makes it easier to build data hierarchies than with plain JS, but I assume other MVC frameworks could be retrofitted to work with React.
This is not unprofessionalism; it is poor UX. The sensible backlash to the Nickelback feature is that is was set "by default," not that ripping on Nickelback is a humorous, widely accepted activity. This app could have retained that "cleverness" and "easter egg" vibe by keeping the setting but not having it be active by default. With proper UX considered, the backlash in this case could have been avoided.
I have a similar problem, but I'm off by a year. I'm fifteen and have basically run out of any CS-related classes to take at my school. I have shifted into math classes (Calc, Stats) to help me get some "computation" this year at school. Just as someone who was where you are, I'd say don't get discouraged by what your school offers and try to work on your craft outside of school. Depending on how much you have learned about CS and programming, maybe learning more and iterating on some side projects would suffice. It's definitely something that is hard to get over, you're not alone. Keep developing.
Now I'm really going to have to worry about leaving my account open on my devices. They didn't show it but these payments need some type of password protection.
1. Care about the project.
2. Care about the users. Know what the user wants and what is in the best interest of the user.
3. Be able to defend yourself and our product in a battle royal (Accepted).
4. [Because there can be more] Help the technical co-founder anyway you can.
I know of Awwwards.com, but they cater to specifically advancements in the design aspects of the actual site and you have to pay for a submission. The usual go-around is to submit to HN, TechCrunch, maybe the Next Web or Engadget depending on your product. There are boards on Reddit and Digg that attract a similar audience to HN, so it really depends how you want to launch whatever it is you're working on. If you are looking for users I would not recommend coming to HN and similar for your audience, however if you are coming for criticism and maybe some (VC) capital, HN and those listed above can sure meet that goal.
[Edit] I found your site, cafecoders.us and would also recommend getting your SEO in place so it is easier to find you. I was using Google and your Whois lookup came before your actual site did. In fact, this submission is ranked higher. I like the idea and would be willing to help if you ever need it, http://bit.ly/MCnWmq (free).
I agree. As it stands now it would make the most sense to learn JavaScript, then I would learn jQuery if I were you, then move into sockets and node.js. You could then use this one language for the frontend and server-side.
It's interesting to compare the game play and design. My game is written in Elm and open source if anyone is interested. This website has keyboard inputs (y or n) which is a good idea. My game only does click/touch inputs.