Note: I originally wrote this in 2016, but I re-read it today and it's still super relevant. We're still using Turbolinks with no plans of switchi...
For further actions, you may consider blocking this person and/or reporting abuse
Nice article, thank you for the perspective! I've built two SPAs this year and I'm already tired ahhaha :P
Well, now you have to write an article about the backend :D
I'm happy to write more about it. Anything in particular that you're interested in hearing/reading?
Oh, I would be interested in hearing, how the choice came upon elixir. What was before that? And how was the transition to a functional paradigm? Okay, Elixir is not Haskell 😂 But I assume there were the one or the other hoopla you went through?
Besides: wasn't the site rewritten from x (ruby?) to Go (some years ago)? At least I thought so.
How you made Changelog fast and your pros and cons of using Elixir in the day to day. I have zero experience in it so it's interesting to me to read professional opinions.
You seem to have a balanced view which helps ;-)
Writing an Elixir Webapp right now and I would also love to see some more insights.
As we've chatted about before, dev.to is built similarly and it has been lovely.
Sometimes it would have been easier to go the SPA route, but having done that, I know the feelings are way worse in the other direction.
The thing is, it's now been a couple years since I've even tried writing an SPA, and while some things have improved I think in the ecosystem, a lot of the same pain persists.
changelog.com wonderfully accomplishes its goals.
Late to the party here but I have tried moving to turbolinks and server side rendering on my project. It's just so great and a breath of fresh air to just make server side templates. Then Turbolinks keeping things speedy.
I've been looking into how Changelog has been handling form submissions, specifically validation errors. It looks like you have some custom handling with JavaScript and a couple of the Turbolinks APIs. How has that been working for you? Any notable concerns or pitfalls?
It all works pretty well! As you noticed, there are a few bits we have to twiddle to make Turbolinks follow redirects correctly and stuff like that (which is transparent in Rails because they tightly integrate the two), but nothing too crazy.
Thanks for sharing your experiences. I appreciate that much. Pretty nice article. I've realized one more time while reading, no matter for how long you do development stuff, you constantly have to observe yourself and double check latest decisions, to not succumb to your own desire. Let's give it a shot...
Is there any Turbolinks alternative that more lightweight with less than 10kb?
Yes, htmx which relatively new and the successor of intercooler.js htmx.org/
Trimmings is very lightweight: github.com/postlight/trimmings
Thanks.
As soon as I saw this title, I knew this was the Changelog
I don't know if I should interpret that as a good thing or a bad thing 😜
I've reread that same article on the Changelog site many times before - The Changelog, like dev.to, are examples of the practicality and effectiveness of Turbolinks when it comes to making a fast website and I think it's even more awesome that you've paired it with Phoenix. Also thank you for open-sourcing The Changelog source code - I use it as reference a lot when I build my own Phoenix apps
Happy we could be of some help to you! Thanks for the kind words, Kenneth 🤗