JavaScript stack

[brysonian]

Would it make sense to transition the new site to a more modern set of tools? Neither grunt nor backbone are actively maintained anymore or in popular use. I worry that it makes editing the sites difficult for the uninitiated to use tools that are increasingly difficult to find support for.

[limzykenneth]

I disagree that grunt or backbone are not suit for purpose. Both of them are mature frameworks with still numerous users around the world and it definitely isn't difficult to find support for either of them as both are well documented and have a big community of users behind it.

It's tempting to move to more "modern" set of tools because they are popular now but I would argue unless something is broken (now or soon) or there are enormous benefit to switching, it won't be worth the effort to rewrite the site just for the sake of chasing popularity. That's just what I think.

[brysonian]

"Chasing popularity" is harsh and mischaracterizes and belittles a very real concern. Neither of these tools are actively maintained; with no active development in years. They were a great choice when the site was initially built, but not now, not if the site is being updated. No one starting to learn more advanced JavaScript development toolchains and methodologies in 2018 should be starting here and the p5 site is a wonderful opportunity for users to do just that. Especially for learners who would like to use this as a way to learn modern contemporary web development techniques, these just aren't the right tools anymore.

[limzykenneth]

I just think it is unfair to declare them dead just because they didn't have the commit frequency of current more popular projects despite having over 500,000 downloads from npm every week. Many people are using them and they are very viable tools even for developing new websites.

Diffferent framework serves different purposes and determining whether a tool is right or not based on its commit frequency and not whether is fits the project or not just doesn't feel right to me. I mean if there are obvious flaws to the current framework or obvious benefit to the new one then yes a change would make sense, for example, the main p5.js repo switched from using jshint for linting to eslint for linting because jscs is deprecated and eslint can replace both jscs and jshint plus also enabling prettifying code precommit all with the same rule.

I guess my point is beyond not having a high enough commit frequency, what is wrong with the current tools?

[brysonian]

Again, I don't appreciate the combative tone; disagreement is a feature of community, not a bug.

Curious to pit one metric (commit frequency) vs another (npm downloads) to make a point. Especially when commit frequency is generally considered an indicator of a community's commitment, interest, and thus future lifetime of a project. And when, in this particular case, the npm download stats tilt vastly in favor of other tools. Yes grunt has a healthy 500k, webpack on the other hand a measly 3M, backbone 200k, react only 2M and vue 300k, assemble 9k, gatsby (as an arbitrary SSG) 130k.

But yes absolutely the project should dictate the tools, that's why i indicated some of those above. Some of the needs of this project though are more complex, the project itself has a pedagogical purpose beyond just spitting out a website. Teaching new learners tools that are more likely to be around in a few years, tools that are in wider usage, tools that better contribute to establishing oneself as a web developer. Part of this project is to offer an environment for people to extend their web development skills, some of those people may even want to get a job doing javascript dev. Offering a safe and supportive place to learn tools to further these goals is important.

On the technical side there are a few reasons. For grunt, it's configuration is as obtuse as webpack, without the added benefits of asset bundling, tree shaking, code splitting, and most importantly, browser targeting. Of course these are all achievable through plugins, but why add those dependencies when these should be core tasks? And as for automation, there is nothing Grunt can do that cannot be done with NPM scripts, so why add the complexity?

For backbone, there is the lack of support for es6 syntax, which leads to peculiarly idiosyncratic object based syntax for module definition that doesn't translate well to other contexts. p5 (as well as processing, OF, cinder, Cocoa, Swift, etc) users are familiar with a more method based approach to reasoning about application lifecycles that map better to frameworks like react, angular, or vue. This of course goes both ways, learning one of these frameworks better prepares you for designing programs in OF, cinder, Cocoa, and swift. Also the lack of es6 support means no tree shaking and no code splitting no matter what build tool you are using. JavaScript has changed dramatically since backbone (which incidentally i used for years) was first developed and the fact that the framework doesn't reflect those changes doesn't show maturity but a stubborn conservatism at best, and a flat out disinterest at (a more likely) worst. Assemble is another problem all together, it has failed to live up to what anyone wanted. A SSG that fails to generate static pages for every endpoint is not a useful SSG. Issues like #149 would not be a problem with a better tool, either a tool that mixes static and dynamic data handling, or one that takes a purely static approach.

The title of the issue is unfortunate because it suggests that i'm pushing for a new JS framework, but this isn't at all what I had in mind. As far as the specific technical requirements of the project I think the onus is on anyone to show why pure SSGs like Jekyll, or even more purpose-built tools like GitBook (or an outside option, docusaurus) are not the obvious first choice.

[Zalastax]

I found the tone to be OK. The most important thing to remember is that someone has to make and review all the changes. Unless there are big road-blocks in the current setup, there should be a big caution in making big architectural changes. Status quo is a powerful force.

I think this could be easily resolved in one way or the other if we took a look at core values of p5.js-website, which I can't find. Are they the same as for p5.js?

[limzykenneth]

I'm sorry if I've come across as agressive or too combative, as you mentioned disagreement is a feature not a bug and I greatly appreciate your input.

Citing numbers is just to illustrate that the projects are not dead/obselete by any means, I believe they are perfectly valid tools (even if I don't always use them myself) and shouldn't be dismissed just because they are deemed less "modern".

I don't want to come across opposed to switching out anything, I just want to make clear that the reason anything is switched out and chosen is because of potential benefits and not perceived popularity. As such yes I very much appreciate your argument on grunt being obtuse while not offering much value on its own, while I may argue that's just grunt's design choices and it works for those who are familiar with it, I actually agree with the point made which is why I don't usually use them for my own project. The same more or less goes for backbone and assemble.

How about this? We can come up with potential solution/frameworks combination etc of modernizing the website codebase and solving hard to solve bugs while having a clear plan of how we may proceed, for example: completely rewriting the website from scratch is obviously going to take a lot of effort that we may not be able to spare at the moment but switching out maybe grunt for webpack is something we can investigate before trying something else.

[brysonian]

Thanks @limzykenneth. I totally agree that novelty shouldn't drive decisions about a project. I think your proposed solution sounds great. I can start experimenting with a webpack and npm script config and see if that simplifies things. I think an iterative approach with an end goal of simplification is great.

[lmccart]

Hey thanks for this discussion everyone. @Zalastax the principles are the same as p5.js generally -- but even those aren't totally clear, we are in the process of documenting design guidelines more clearly. @limzykenneth I hear your concern, and I think the iterative/simplification approach sounds like a good balance here.

To elaborate, my general preference is to try to put off a rewrite of the entire site because this is difficult for me to do right now time-wise. I also feel that there are certain parts of the website that are somewhat hacky and I'd love to have more eyes on them. There are likely better solutions that I just couldn't think of. In general, I see incremental updates to tools as a way to push that further off into the future. If @brysonian has some energy to put into this work, I'd say it's very welcome. We can look at the proposed tools and updates and weigh the benefits of updating against the potential larger structural changes they would require.