Hacker News Reader

> you can, but please, don't

I think this is a bit short-sighted. While building a framework from scratch is certainly not for everyone, there's definitely value in building one. You say things like `you have to maintain your poorly cobbled-together "framework"` but when you think about it, this was true of authors of major frameworks at some point as well.

Remember when React added id's to every single DOM element? Or when Ember was dog slow? Framework authors and maintainers learn lessons over time and with each project iteration they become more valuable due to their skillsets.

> If someone DOES pick it up after you, (the poor bastards), they are going to be bothering you day and night, or go insane after 2 weeks

Again going back to skillsets: this is part of what makes large OSS project developers desirable: they've been through the process of passing-the-baton and they know the importance of things like documentation, maintainability, etc and can take concrete steps to further goals in those areas.

Turbolinks evolved from Pjax (4 yrs old) and is part of Ruby on Rails (11 yrs old). Not only does it respect back/reload out of the box, but it also supports native. Its as mature as it is supported as it is powerful.

It really just works - drop it into a project and you instantly have a SPA. Its far from a framework - its API has less surface area than even React. The above comment couldn't apply less to Turbolinks.

The only true caveat necessary is that it's written in CoffeeScript. :P

The only true caveat is you can’t have multiple dynamic elements per view.

It allows you to do partial updates, but indeed it doesn’t support view transitions out of the box. :/ That said, the native wrappers offer built-in transitions, and you could probably hack web transitions with some modding and a component library.

I like your optimism, but I would like to remind (scare) you:

If you decide to put your effort into customizing the framework, you increase your risk of building

> [...] your poorly cobbled-together "framework" for the next 2, 3, or more years. If anything changes and pages stop working "right", you get to pick up the pieces. Yes, "you", because since your framework is something that you pieced together, there are no "tutorials" nor stack overflow questions nor manuals to refer to.

This is easy to do in Rails on your own. Turbolinks is irrelevant to this.

Just to be pedantic: pjax is nearly 7 years old. https://github.com/defunkt/jquery-pjax/commit/3efcc3c968c18c...

Turbolinks is not a front-end framework. It is a library that has been in Rails for ~5 years. And before that, pjax did basically the same exact thing. This is a pretty battle-tested way of building web applications.

GitLab removed TurboLinks from their site not that long ago. It was the source of a lot of bugs, crufty code, and flakey tests. If you have any JavaScript that modifies the DOM or ever plan to don’t use TurboLinks.

Shopify went back to Turbolinks: https://shopifyengineering.myshopify.com/blogs/engineering/r...

That article is from 2014, the golden age of TurboLinks. As far as I can tell they are not using it on their main site or any of their white labeled sites anymore.

https://github.com/shopify-graveyard/turbolinks/

They forked: https://github.com/Shopify/turbograft to add partial page replacements. It was slated to be merged in TurboLinks 3 but that canned in favour of version 5.

Their new Polaris components are using React though: https://github.com/shopify/polaris

> GitLab removed TurboLinks from their site not that long ago. It was the source of a lot of bugs, crufty code, and flakey tests.

An anecdote is not data.

> Turbolinks.clearCache() Removes all entries from the Turbolinks page cache. Call this when state has changed on the server that may affect cached pages.

https://github.com/turbolinks/turbolinks#turbolinksclearcach...

This is a nightmare. You will eventually miss a cache invalidation and break browser navigation or invalidate the cache so aggressively that TurboLinks is serving no purpose.

You don't need lots of negative testimonials to see that managing your own client side cache with JavaScript is a bad idea.

Haven't had any problems with this in 2 years in production. It also works fine for Basecamp.

I think at this point it really depends on the type of app, the browsers supported, and exactly what you mean by "without a framework." The sentiment you're expressing, although true to an extent, sounds like something I would have said 10 years ago.

It's VERY rare, almost unheard-of, to find any front-ends these days that are just HTML, CSS, and Javascript. That wasn't the case 10 years ago. IMO we don't know what a modern app would be like without a framework because it's just not done anymore. Even this post here uses Turbolinks, a framework.

It's also rare these days (in my experience anyway) that clients will ask for things that are simply not possible with HTML, CSS, and JS. Website design has started to get very same-y, and both HTML and CSS have gone through huge upgrades. Depending on the requirements you might be able to pull off a modern-looking design with just the basics.

Browser compatibility remains a problem, but most JS tools called "frameworks" don't exist to solve that one, but mostly to help structure large amounts of JS code. These tools simply did not exist at all back then, because people just didn't write that much front-end code. On SPAs, a lot of the code is only there to reinvent things the browser and the back-end could be doing.

If I was starting a new project I would probably go very light on the tooling.

Another factor is that we’re seeing the continued rise of massive front end frameworks at the same time that the native JavaScript environment is becoming faster and easier to use. There’s a non-trivial number of sites where the easiest thing to maintain will be standard JS/CSS rather than whatever was in vogue a few years before.

This is also of interest from the performance angle: frameworks take on a lot of expense maintaining certain levels of magic, convenience, and general applicability which has its benefits but also makes it easier to miss or fix problems. The first time I tried React on a serious project, the coworker who’d been hyperventilating about how fast the virtual DOM would be was surprised to learn that it was something like 40,000 times slower and that there was no easy way to fix it (innerHTML updates on rows in a large table when textContent was sufficient).

The last time I did a fresh project I ended up using just ES6 + SCSS and found it to be quite pleasantly rewarding. So many of the old tedious points have gone away with flexbox / grids, ES6 classes and arrow functions, querySelectorAll and the newer array methods, fetch vs. xhr, etc.