5 ms·

I know they are trying to promote their own Front-End Framework (while trying to pretend that it isn't one), but with regards to the question on the title, my e

I know they are trying to promote their own Front-End Framework (while trying to pretend that it isn't one), but with regards to the question on the title, my experience is: you can, but please, don't. It actually isn't THAT hard, but what will happen is that you'll end up reinventing the wheel badly, and you'll be chasing bugs and fixing platform inconsistencies for months. It won't be optimized and it won't work in some random obscure browser, or under some random platform (and there's always THAT user that just happens to have that browser/platform combo... Murphy's Law spares no one). Also remember: YOU have to maintain 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. 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. In conclusion, just grab something that works for you and is reasonably well supported (and looks like it will REMAIN supported in the future) and use that. Don't fall into the "NIH syndrome" trap.

the_gastropod 9y ago
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.
- deckar01 9y ago
  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.
  - pbreit 9y ago
    Shopify went back to Turbolinks: https://shopifyengineering.myshopify.com/blogs/engineering/rebuilding-the-shopify-admin-improving-developer-productivity-by-deleting-28-000-lines-of-javascript https://shopifyengineering.myshopify.com/blogs/engineering/r...
    - deckar01 9y ago
      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/ https://github.com/shopify-graveyard/turbolinks/
      - Rafert 9y ago
        They forked: https://github.com/Shopify/turbograft 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 https://github.com/shopify/polaris
  - owens99 9y ago
    > 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.
    - deckar01 9y ago
      > 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#turbolinksclearcache 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.
      - owens99 9y ago
        Haven't had any problems with this in 2 years in production. It also works fine for Basecamp.
lhorie 9y ago
> 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.
tboyd47 9y ago
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.
- acdha 9y ago
  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.
bruncun 9y ago
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
- dcwca 9y ago
  The only true caveat is you can’t have multiple dynamic elements per view.
  - bruncun 9y ago
    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.
    - jwandborg 9y ago
      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.
  - owens99 9y ago
    This is easy to do in Rails on your own. Turbolinks is irrelevant to this.
- the_gastropod 9y ago
  Just to be pedantic: pjax is nearly 7 years old. https://github.com/defunkt/jquery-pjax/commit/3efcc3c968c18c4deeb27a1bab1b7306ca4b6e99 https://github.com/defunkt/jquery-pjax/commit/3efcc3c968c18c...

the_gastropod 9y ago

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.

deckar01 9y ago
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.
- pbreit 9y ago
  Shopify went back to Turbolinks: https://shopifyengineering.myshopify.com/blogs/engineering/rebuilding-the-shopify-admin-improving-developer-productivity-by-deleting-28-000-lines-of-javascript https://shopifyengineering.myshopify.com/blogs/engineering/r...
  - deckar01 9y ago
    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/ https://github.com/shopify-graveyard/turbolinks/
    - Rafert 9y ago
      They forked: https://github.com/Shopify/turbograft 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 https://github.com/shopify/polaris
- owens99 9y ago
  > 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.
  - deckar01 9y ago
    > 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#turbolinksclearcache 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.
    - owens99 9y ago
      Haven't had any problems with this in 2 years in production. It also works fine for Basecamp.

lhorie 9y ago

> 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.

tboyd47 9y ago

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.

acdha 9y ago
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.

bruncun 9y ago

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

dcwca 9y ago
The only true caveat is you can’t have multiple dynamic elements per view.
- bruncun 9y ago
  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.
  - jwandborg 9y ago
    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.
- owens99 9y ago
  This is easy to do in Rails on your own. Turbolinks is irrelevant to this.
the_gastropod 9y ago
Just to be pedantic: pjax is nearly 7 years old. https://github.com/defunkt/jquery-pjax/commit/3efcc3c968c18c4deeb27a1bab1b7306ca4b6e99 https://github.com/defunkt/jquery-pjax/commit/3efcc3c968c18c...