Was just going to post hyperapp. We just dropped it directly into our JS framework, using it for stateful stuff in our applications (mainly reg/login forms/balances widgets/game modals at the minute). Stupidly simple, been really good so far, first few components making use of it just went into production.
We have a set of sites using a JS framework we built to sit on top of a C# CMS; we looked at existing frameworks, but nothing really fit (we’ve just stripped the final legacy bits using Backbone/Marionette out). It’s ok, very few deps bar the aforementioned hyperapp, and with that we’ll probably just use the idea as a base and rewrite it to fit better. We have a second set of sites that are SPAs. Main dev was core Marionette team member, so use a derived framework built off that. All the front ends are switching to using web components over the coming year, we’ve had zero issues with the stuff currently leveraging them that we have in prod.
Oh the BDFL person is much more likeable for Elm, it is not him, but literally just many in the community, a lot of them come from Haskell, which is a very… also hostile community, so it has just leaked over.
For note, Unpoly and Intercooler are very similar, they do things by marking the document up, Unpoly is a bit older, however it requires jQuery, Intercooler is newer and its jQuery requirement is being slowly removed. Intercooler is a touch more useful for server-to-client calls, barely, and Unpoly has a few other additional features that Intercooler does not, just because it has been around longer, however you can emulate those in Intercooler easily enough. Intercooler had a couple of issues with lifetime management that has not been resolved yet, those issues are resolved in Intercooler via its significantly more advanced hook system, that allows you to register lifecycle events on added/removed DOM nodes, while also having a more powerful API to insert DOM nodes via it. I use Drab to make Unpoly calls on the client to handle all registration, basically I replaced the jQuery usage in Drab with Unpoly, which was pretty easy to do as Drab is pretty extendable.
Drab is made by someone on these forums, it is just a server-to-client and client-to-server communication interface that uses Phoenix channels, makes it trivial to send HTML to specific places on the client and more, its quite nice, pretty new still, but easy to flesh out. It really needs a set of hooks so you can call lifecycle events on the client though (which I’m just doing manually currently). ^.^
Although I would typically consider myself a ‘full stack’ developer, the bulk of my work is back end and devops. At my current employer, I basically don’t touch the front end, which is done with ext.js (using the full sencha suite of tools, or at least the applicable ones).
For personal projects I’ve reverted to using straight server rendered when possible, since phoenix doesn’t punish me for doing so. When I do need more, Vue has been the tool of choice for me, but I’m not totally sold. I like how it works better than angular, ember, and react; but I would prefer a more cohesive ‘package’ like ember or angular. I’m not thrilled with webpack, which seems needed to use Vue well, but that could be just my lack of understanding.
I’ve been looking at Elm, and want to like it more, but there still seems to be a lot of friction for doing anything ‘real’ with it for me, probably when I need to reach outside the core system and integrate with js libraries.
Facebook’s Reason has a dependency on Bucklescript.
Reason compiles to OCaml, which is then run through Bucklescript to output Javascript. Compilation using Reason is a bit slower because it is not quite as regular a language as OCaml, thus slower to parse, but still faster than about any other transpiler. ^.^
I’ve also been considering Drab, but not tried it yet… Since I’m sending HTML over websockets and updating the DOM myself in app.js, I probably should try it!
However you send new content over, it seems to me that virtual DOM updates could be handled client-side for at least some of the benefit, perhaps with something like diffDOM. Sure, you won’t save on network traffic, but it should help for the rest. Also, it’s probably more scalable to push DOM diffing to the client.
It has a good pattern (TEA), but two things hobble is severely, first is that its API breaks every version, second is that the language itself is extremely limited (especially in regards to JS integration, which as much as they would not like to admit, is important for most people), and also for me it has rather monstrous compile-times…
To be honest probably could of been done with something like react or view but at the moment I haven’t really needed it and everything seems to be working fine.
Having been a part of the Elm community for some time, I guess it can be seen as hostile agains changes outside the current language focus. In general, the Elm Slack is very welcoming and any question is happily answered repeatedly.
When it comes to using Elm for frontend, I’ve only used it for smaller SPA applications like this one https://hakonrossebo.github.io/functional-programming-babelfish/ Having done work in Angular and React, my experience is that Elm is very nice to work with, much easier to do refactoring, and much less mental overhead. I have not been troubled with compile times. For SPA’s there is an ongoing discussion on parent/child communication and amount of boilerplate, but I find the approach I’ve used in my project (link) is working well.
Yeah it is mostly the mailing lists that I’ve been on and its generally only a couple specific very loud people that cause the issues, I’m often not available for real-time slack-like chat. ^.^
I use Elm extensively (plug: http://www.dailydrip.com/topics/elm). I love it so very much. I was already an extremely fast frontend developer, and with Elm I feel ~4x faster than before, the apps are just rock solid (zero runtime bugs in over a year, a couple of small logic bugs that smarter types would have resolved). Refactoring is comically easy - my apps stay a lot more reasonable. In plain-JS or React and friends, I found myself less likely to do a big refactor just because I had no idea what little bugs I might introduce or how long it would take to get through. With Elm I make one part of the intended final change, follow the compiler til it’s happy, and then I’m done and it’s perfect.
