Turbolinks and Stimulus are developed behind a wall

A May Of WTFs
1

The growing community of passionate Turbolinks and Stimulus developers is eagerly awaiting the release of the next version of these libraries. The date has been pushed back and now the word is “Fall 2020”.

We can love and appreciate these libraries while also feeling super frustrated that they are not developed in the open.

Being a daily user of them means we’re relying on and evangelizing for these amazing tools that get updated irregularly, when the creators decide to. This is how Microsoft used to release code, but even Microsoft seems to have figured out that community input and engagement are proportionately tied. People will take the library more seriously if they can be more involved in helping to build and document it. It’s that feeling of being on a team vs receiving supply crates if you stand around on the tarmac long enough.

We only get glimpses of exciting new features if someone decides to give them to us. We have to comb through the Hey.com javascript code to get hints about what’s coming. It’s fun if you pretend that it’s a scavenger hunt or a thriller, but it’s hard to argue that it’s great.

This isn’t a statement about what Basecamp “should” do. We benefit from their generosity and they don’t have to do a damn thing that doesn’t suit them. History also suggests that, well, they won’t. :wink: So I’m not trying to boil the ocean.

I do think it’s fair to ask: why the secrecy? Why not develop these amazing tools in the open? Who knows, we might even have some great ideas and great PRs.

I don’t want to take any heat away from the Hey.com launch. You could open the development process and not officially release the libraries until the exact right moment. You’d find nothing but support and appreciation from us.

49 Likes
2

Hear hear! I commented on GH back in Feb about this very issue… I would say it’s perfectly reasonable to work on alpha-level features in-house and file a PR when they’re ready, but for a project to just stall for numerous months at a time without any visible active development is concerning—at least for something which initially came out with a bang like Stimulus. I’m busting my buns to convince clients and peers to steer away from de facto frontend choices like React/Vue, etc. and try more lightweight approaches first, and this doesn’t make my job any easier. :confused:

7 Likes
3

I just want to add on to this that I didn’t even know stimulus was being actively developed. I thought what we had was all we were going to get.

So it’s nice to hear they are developing it somewhere :smile:

3 Likes
4

@joshleblanc Ouch :grimacing:

6

A May of WTFs has been a constructive effort so far. Let’s keep it that way.

12 Likes
7

TL;DR :drum: :drum: :drum: + :zzz: = :cry: :angry: :confused:

Stimulus 1.0 is pretty cool. The issues list is short. I don’t have a problem with Basecamp privately building an improved 2.0 version. They don’t have to give it away, just like GitHub doesn’t have to give away their multi-database, multi-tenant magic. I really appreciate that these companies believe in OSS and share so much.

The…community…is eagerly awaiting… The date has been pushed back

How much of the frustration revolves around this? It does for me.

Communication Timeline (no names; not bashing anyone)

  • We plan to ship them together in the upcoming Stimulus 2.0 release. (Nov 2, 2018)
  • We plan to release these changes soon as version 2.0. (Aug 9, 2019)
    1. And it’s going to be amazing (Sep 29, 2019)
  • Plan is to have TL6 out ~late summer/early fall (May 10, 2020)

Announcing…then nothing…for years. They didn’t owe us…but they promised.

They’re a solid bunch, so we counted on their word, blogged about it, wrote books on it, wrote apps on it. We watched, waited, hoped, wondered, got frustrated, and maybe even a little bit mad at more delays.

They probably have great reasons for delays. A pandemic is sure a good one for the bump to Fall 2020. I don’t fault them for taking care of their employees first or wanting to let Hey! have its moment before sharing the enabling tech. What a cool tech demo!

…but that doesn’t help my project planning or my unmet expectations. Plan B. Maybe it’ll be in my next project. That’s a bummer. :cry:

6 Likes
8

I sounded a bit ranty :sweat_smile: Not promise in the sense of Rails 6.0.x security patches, but years is long to be left hangin’.

9

I forgot to include the current in-flux state of the iOS and Android wrappers for Turbolinks in the topic parent.

Sam’s groundbreaking RailsConf 2016 talk was one of the original reasons I got excited about Turbolinks again. One of the most compelling aspects of his presentation was how he was able to quickly stand-up a native hybrid iOS app using the native framework wrappers.

Unfortunately, Google seems to have fucked things up and as a result, the Android v1 wrapper has been officially deprecated since December 2018.

The problem, as @ansonhoyt points out, is not that Basecamp are superhumans that can bend the Chrome team to their will. If there is a problem, it is that the deprecation notice promises “something in 2019”.

Now, you can wiggle around this with semantic arguments, but at the end of the day you have all of these developers that place their faith in you, and when you don’t follow-up with semi-regular updates - even if it’s just to say that there’s no news and you’re frustrated, too - then of course people will feel feelings. Especially if people are trying to make decisions like “I want the developer happiness DHH talks about on Twitter, but if I tell my employer this will work out and Basecamp doesn’t release an update for two years, I’m going to get fired.”

My current belief is that what’s been under-communicated is what we should expect regarding governance of the project. Basecamp is well within their rights to run this project however they like, but it would help set expectations about the logistics of how this relationship will work if details like a release schedule and whether PRs are encouraged could be addressed up front, like a pre-nup.

I’d also like to stress that there’s a useful difference between transparency and communication. It could very well be that Stimulus is a better library if Sam and Javan are free to build it without constant hectoring from a well-intentioned but time-consuming community. Lots of inventors are best left alone, and we’re lucky to benefit from Sam’s pre-cog level web ecosystem smarts.

If that’s the case, set the scene by telling us, up-front, that this isn’t your typical OSS project and that we’re welcome to sit at the chef’s table. There won’t be a menu but if we’re patient and polite we’ll get to see how the courses come together and the meal will blow our minds.

18 Likes
10

I feel similarly on the subject. I’m particularly interested in some of what David has been writing about regarding the future of this tech, but there’s nothing to show for it. As a junior and amateur developer, it’s a weird place to be in when there’s a variety of old techniques such as .js.erb hanging around, which I don’t know if are still appropriate to use. It feels like how Rails handles JS earned it a stigma in the past, and the team is working to improve it, but nothing is cohesive as of right now. What David has been hyping up seems to be a big piece of this puzzle, but like you pointed out in the OP, everything is behind a wall.

I’m a chemical engineering student who will soon to be graduating and looking for work. I probably won’t start as a software engineer, but I’d love to get into the field at some point. It’s hard to know if I should wait around to see what happens with this stack, or if I should just throw in the towel and learn React/Vue/whatever since they’re popular and just get used to writing API-driven Rails apps.

5 Likes
11

One of the great things about the traditional Rails approach is that the fundamentals have remained pretty stable. Rendering HTML on the server has always been central and that won’t change.

The traditional Rails/Basecamp aproach can be outlined as follows:

  1. Render HTML via Controllers and Views
  2. Speed up page transitions with Turbolinks
  3. Organise specific behaviours with Stimulus
  4. Handle dynamic updates with rails-ujs and ActionCable

This is still a great productive stack, and whilst there might be some changes regarding how page updates are handled, rendering .js.erb is only a part of the package and still valid. Upcoming libraries may provide elegant solutions to page updates, and allow for improved security features (via content security policies), but probably won’t fundamentally change the approach. If you continue with this stack, when the new updates are released, you probably won’t be too far off :slight_smile:

12

Some of these things just are not true, Dom. Roughly in the order you mentioned them:

  • RJS templates were a thing, once
  • love it or hate it, Rails did introduce an API mode
  • UJS is going to be formally deprecated whenever Turbolinks 6 comes out
  • @DHH has stated previously that .js.erb is on the way out
  • remote forms don’t have error handling without the Optimism gem
  • StimulusReflex fundamentally changes how page updates are approached
  • @DHH can’t seem to stop mentioning their top secret new content delivery mechanism

@jacobdaddario is absolutely right to be confused, and unfortunately there appears to be a gag order on anyone working for Basecamp to lay out what we should expect in the months to come or else there would presumably be some information provided by now.

4 Likes
13

@leastbad Let’s keep things constructive, please.

I think it’s reasonable to criticize the lack of transparency around Turbolinks updates. I even agree with you on that! It’d be easier to get my team enthusiastic about non-React technologies if I could lean on The Official Word of Turbolinks to paint a more detailed picture.

However, language like “gag order” is unnecessarily inflammatory. Let’s please respect that everyone working on Rails & adjacent technologies is doing so as a gift to the broader community.

5 Likes
14

I suppose I’m trying to say that the default Rails/Basecamp method for page updates has not required a fundamental shift in mindset. For example:

// rjs (2006)
page[:cart].replace_html :partial => "cart"

is not radically different from:

// js.erb
$('#cart').replaceWith(<%= render :partial => "cart" %>)

The principles are the same: you’re still sending server-rendered HTML over-the-wire.

When API mode was introduced, the default approach didn’t switch to client-rendering.

I agree that the lack of full support for remote form handling is a WTF (particularly given that form_with generates a remote form by default).

Whilst there are planned changes to updating pages, which will affect rails-ujs, that doesn’t invalidate the js.erb approach for now; and if I were to create a new Rails app now, I would try not let the anticipation of something new distract me from being productive with the current tools (I get that this isn’t easy!). I can still markup templates as I’ve always done; I can speed up page loads with Turbolinks; I can organise my behaviours with Stimulus; and I can add a few sprinkles with js.erb responses. Most of that probably won’t change.

I’ve been privileged in that I’ve not had to steer colleagues away from client-rendered alternatives. Transparency over upcoming developments would be nice though (indeed I’ve kept a few Turbolinks PRs up-to-date over the years, wondering if it’s worth it), but I’m trying to offer guidance to those new to Rails development right now—you can still be very productive with the current toolkit.

3 Likes
15

@Betsy_Haibel I’m embarrassed - I take my personal “don’t be a dick” policy pretty seriously and I honestly believe that I was just pointing at the cough absence of commentary that has felt more awkward every day of the two weeks since I first worked up the courage to post this. In the country I live in, a “gag order” is a bonafide legal term that quite literally means a judge restricting information from being public. It’s not considered offensive or inflammatory here. The last thing I want anyone to think is that we don’t appreciate these incredible libraries. That said, it also feels intellectually dishonest to pretend like this is a misunderstanding, and surely we can have discuss that in a respectful way.

I’m happy to apologize and use whatever language you recommend, but it doesn’t change the physical properties of the animal in the room. We’re working so hard to promote and grow the Stimulus + Turbolinks communities on our own steam that when I see a smart newcomer openly ponder whether it’s worth sticking around, my baser instincts kick in.

10 Likes
16

Now it’s November 2020, Hey.com was launched long ago, Rails 6.1 RC1 is out and we’re nearing the release of Ruby 3.0 but still no statement when we can expect the new turbolinks.

To heal Rails it would be required to have this peace of the puzzle included in order to offer developers a cohesive development flow story as an alternative solution to fat javascript frameworks.

This DHH tweet sets expectations high for end of the year season:

17

The radio silence is hard, but a lot has changed since May and frankly, I’d prefer that they take the time they need to do everything right while also taking good care of themselves. DHH himself took time off and to that I say: good for him.

The major exception to the above is that it seems unfortunate that the Android native wrapper for Turbolinks hasn’t received even an updated roadmap, even though Hey has clearly found a viable solution.

2 Likes