I'm working on a way to leverage the API into the entry browser and I'm at this point where I realized this could be a very large change. Ten years ago, when I was really building out BotB 2.0 (the current version), there was a lot of emphasis on the site working w/o javascript. There was a big push from certain individuals and I obliged. I would guess over 95% of BotB (excepting the html5 player of course) works with javascript disabled in whatever browser.

So, I was working along and found myself importing handlebars

and suddenly realized the impact it could have. Handlebars is a templating engine. So I'd grab data from the API and populate it into templates and spew those onto the page.

Two ways forward here:

1] using handlebars (or similar) which will be a lot of work upfront but should make development and loading faster

2] do it the old-fashioned hacky way with spaghetti and duct tape

I have the time to focus and make the site better, but I'm worried using this "single page application"-like technology might break things for people on WinXP or terminal browsers or something. So, y'all have the weekend to file your grievances here about such a change!

i dont have a problem with this at all.
okay, i mean im on win7(pc) or win10(laptop) with chrome, i dont think it'll affect me in any way.

but a general thing: progress and moving forward is a natural thing. changes happen. adapting to them is a basic skill every human should have.
i know a lot of changes can be annoying if they happen like every week. but botb 2.0 is ... how old? 10+ years? a change is not only appropriate but also needed imo. you dont have to live in the past, even if youre a chiptuner

As far as I'm concerned, javascript itself isn't a bad thing, it's all the unnecessary shit it sometimes brings along. As in, there are certainly ways to do it in a more lightweight fashion, and handlebars does seem to be a good candidate for something like that.

Also, since botb stuff is all in a database (RIGHT?!) you probably could keep the old stuff working too as a 'non js' backup for the luddites?

eh, the browser will become unusable w/o js if I do this
i assume the player already doesn't work w/o js because it needs js to do the html5 audio bits

I sure as hell hate js and love blocking it wherever I can. I do allow scripts from Botb though (only 1st party though, not the google/analytics crap), because, well, not being able to listen to the music on a site that's mostly about music is kinda pointless. So I'd say go ahead and do whatever you gotta do to make your life easier and the site more maintainable. You may find that including a big 3rd party framework ultimately causes more problems than it solves but there's no way to find out without trying, eh?

Btw it never occured to me to browse botb with a textmode browser but now I just did and amazingly enough it works pretty well, actually.

honestly didn't realize the site still worked properly without js enabled

I generally second Irrlicht's every word. Ideally it would have some kind of fallback that still renders the page without scripts, even if that means looking ugly or incomplete.
Personally I allow botb scripts (1st party only, ofc), except that horrific April Fools one, but I sometimes use BotB on an old Pentium 4 machine as well and it would be a shame if the performance plummeted badly.
It's ultimately up to you, and I'll probably live with the changes if they're not too drastic, nevertheless my opinion has been voiced

Usage of client-side templating engines, to me, results in cleaner and more modular code for web applications. This way you also have a way better separation between front-end and back-end. After using VueJS and React (preference for Vue since it's way faster/more lightweight), you can't convince me to ever go back to manual, handwritten DOM manipulation lol

Living in 2020, I assume the majority of devices and browsers are more than capable enough to do client-side rendering, especially with lighter frameworks?

I'm still using Mac OS X 10.6.8. I'm not sure how well your solution is going to work on my end, considering I'm using Firefox 48.0.2 and Chrome 49.0.2623.112... although it appears that handlebars may not be too bad.

dRRRGH I HATE THIS BCUZ IT BRAKS ME XP VORETUAL MASHINE!!!!11!1one!1!onehundredandeleven FROCK YUO VOMITSEVEN!1!@32!$%^%^436%^#^&

...jokes aside, g0 for it man. as fun as it is browsing botb 2.0 on nt 4 using netscape 3, i think an update is needed for this site. could posssssibly break firefox 52 (xp's latest firefox) but like kff said, handlebars shouldn't be that bad tbh. besides, i have a shared folder in virtualbox for frontpage 03 and beepola and ascii stuff atm and a vdi mounter for older stuff so it's all good.

I giggled xD

ajax or something would be nice for allowing people to browse huge fav lists like djmaximum's or kleeder's without it being really slow to load and taking up a huge amount of memory when it does load. you could maybe make it so it initially loads only 2000 entries and dynamically loads another chunk of them once someone scrolls to the bottom, and unloads the previous chunk. but fav list length is rarely long enough to slow stuff down significantly so i guess it doesn't matter too much.

i hate people with huge fav lists

imo, despite how great it sounds, a major rewrite will always introduce more bugs than it fixes:
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
and in my experience, SPAs (with or without a server-side rendering part) have way more edge cases than you can plan for (every page now has two unrelated "entry points", HTML5 navigation vs native navigation/reloads, and the order page data loads is always different for each). or in other words, "modern web practices" kind of suck and it probably will all be outdated in 5 years anyway.

i would recommend just incrementally improving the hardest-to-maintain parts or making some individual screens like the browser more JS-heavy but only if it really cuts down a lot of code.

also, there are a handful of mustache/handlebars libs for PHP so you could maybe do the API+template stuff in pure PHP without turning the page into facebook or whatever

for my experience with modern JS. it's just terrible. it eats so much CPU usage and memory and is so incredibly bloated. these "everything on one gigantic webpage" sites are such a disaster, you'd be better off having buttons with numbers and a dropdown list on how many faves should be shown like only 20 faves or 50 faves.

my website IS an overscripted mess and even I'm popping in to say: never make the mistake of thinking that modern standards are good

#include "book.h"
Every dependency is a liability. Native programmers know this because wrangling native dependencies is literal hell with no results at all if you have less than 100% of the dependencies. Missing some javascript on a webpage usually isn't a problem because static content and the other JS parts might still run giving a fairly usable page in total.

While this Handlebars thing makes your code shit sparkles and smell like roses right now, what happens in 2021? I think we can all agree that a lot of JavaScript stuff is innovated for the sake of innovation. Your chances of picking the one technology/framework that remains popular/supported/maintained in the future seems very small indeed.

Right now (2020-07-20), the Mustache Wikipedia page is lacking in content/quality and Handlebars.js doesn't even have its own page. Amazingly, I've heard both Mustache and Handlebars get mentioned as rather common technology, I believe WordPress even relies on both? Hell, even *I* know about Handlebars/Mustache and I fucking hate JavaScript so much I'd rather set up a C++(!) to JS transpiler ("Cheerp") than deal with JS directly. So how come the Wikipedia page is lacking? I looked it up: both "handlebars.js" and "mustache.js" seem like dying queries on Google Trends.

#include "opinion.h"
☑ Mustache templates are rather simple
☑ Mustache is a standard with multiple independent implementations (includ a PHP one!)
☒ Both Mustache and Handlebars.js are dying queries on Google Trends
☒ Handlebars.js recommends npm installation in production (yay, complexity!)

I dunno, I haven't looked into Handlebars.js much. Is it compatible with older browsers? Does it have dependencies and what if they break or are unmaintained? What is gonna happen with Handlebars and its own maintenance in the future?

I find Mustache templates to be an excellent choice for templates because it is seemingly the simplest thing out there. I came to this conclusion many years ago. But knowing that puke is gonna add more js into botb is gonna give me some sleepless nights:
I don't want a slow, unresponsive and shitty botb experience where I have to wait for 6 seconds per click to load all assets via AJAX/json queries while TCP SYNs and ACKs and SYNACKs and for the two generals to agree to attack at dawn. Besides, I love the look the site has right now and wouldn't change it for a damn thing.

Please, just do us and yourself a favor and do the bare minimum? Minor fixes is all anyone seems to want or care about. Besides, I'd rather just have another Detroit battle than more JavaScript.
If you ARE gonna go with the Handlebars.js implementation? I highly recommend you use the compiled .js and import that into the source tree. Keep it simple.

If you wanna do everything in PHP? Maybe do what coda says and use the php mustache implementation?

tl;dr: don't use dependencies that you're not absolutely certain will be supported in the future. Sticking to something that's old and stable is preferable to innovation headache being transmitted to your users at the speed of light.

Profile pic related, it's a boring Facom computer.

Y'all need to calm down. If you click/open the BotB Radio the popout loads a mostly empty page, calls a crusty old version of the API and then builds the page using a custom templating engine I made. I looked at all the work in making that templating engine more robust and realized I might be reinventing the wheel. I'm not trying to rebuild the whole site. I'm trying to improve everyone's ability to sift through tens of thousands of submitted entries and then listen to what they find.

We already have jQuery 1.11, and adding handlebars would about double the size of libraries. I'm not using npm or lodash or a cdn or pulling a dependency that requires more dependencies. Thanks for pointing out there are PHP handlebar implementations.

What I really wanted to know was who might this effect in a pragmatic way. Like, do I need to find an older ES5 compliant version?

I've combed💇 down, puke. :p

What ECMAScript version does Handlebars need? And what Handlebars/ECMAScript version are you planning to target?

Consider this:
* No one is seriously using botb with pre-ES5 browsers
* ES5 support is omni-present
* ES6 support is a tiny bit spotty (*FULL* ES6 support for desktop users is only at 92.74%!): https://i.imgur.com/0W8xFFd.png
* ES6 support will probably rapidly improve in the near future as users should never run outdated browsers (and they won't)

I found one guy from 4 years ago willing to argue that ES6's "Template Literals" will be a 'Handlebars killer': https://www.keithcirkel.co.uk/es6-template-literals/ What a coincidence! Handlebars/Mustache are both becoming less popular on google trends! :O

Maybe you can use ES6 template literals for your templating needs instead?! It seems to me that going forward this might be even better supported than Handlebars! And you don't need a library at all?! :OOOOO

tl;dr: Maybe use ES6 template literals?

Epistemic status: ✓ Just do it. 👟

gdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdfgdfjkhdjhgjkdfhgjkhdf

tl;dr: edrfhjud

Looks like KFF's stuff can handle Template Literals (so long as I don't use escape sequences): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#Browser_compatibility

ok, maybe we don't need handlebars
gonna think on how to approach this

see? this is why i asked! <3

<3

oh i could not tell from OP that this was about the radio (maybe i wasn't the only one)
just use whatever, for that thing...

Hold up, so this is *only* about the radio? If so, then I care much less

If y'all had watched the Stakeholders' review of June 2020 this would've been clear e.e

J/k:
I kinda avoid the webdev field, but asked a startup webdev guy I know and his comments are "handlebars should be fine. It's not angular and doesn't have huge deps. But one could also write nice backend stuff using Python and Jinja"

And I mean I don't know what to make of that because the only thing I understood was Python, but I smiled and nodded politely. Then I quickly changed the subject to C pointer arithmetic, because I didn't want to appear like an idiot.

It's about the the browser and the radio. And then I want to put a similar thing, where you can sift through entries and listen to them, on botbr profiles and battle pages.

Jinja is pretty decent, if you can live with the horrible (but for the right reasons) syntax. I think the PHP equivalent would be Twig

.