Skip to content

Stack Justification

Jump to bottom
Daniel Reeves edited this page May 10, 2020 · 4 revisions

As of writing, the only stack decision we've 100% decided on for the website is Python 3.7 and Flask. This leads to a natural question: why?

Why Python?

Our justification for using Python is that, due to how the CRWA tends to staff its team (academics and scientists), Python is the most viable language that a website can be built in while still being maintainable by the CRWA. The two most popular coding languages in academia are R and Python. You can't really build a website in R (you technically can, but really really shouldn't for a lot of reasons). So the next option is Python.

Even if the CRWA does not staff people based on their Python knowledge (we do not expect that they will do this), they are very likely have connections to various people who know Python. It is unlikely that the CRWA will have as many direct ties to people who have Javascript or PHP knowledge. Because long-term maintainability is such a high priority, Python is the sensible technical solution.

Not only is Python way more popular than PHP in academia, it's the most popular programming languagein general. This means that Python is a natural fit for any organization's coding projects that do not have specialized needs for a particular coding language.

There are a lot of disadvantages to building a website in Python, which is why most websites are built in LAMP, MEAN, Ruby on Rails, and other software stacks. Most of the advantages of other frameworks are performance related: for server-side scripting, Python is a very slow language compared to PHP 7. Also, many modern stacks are designed to facilitate reducing the amount of server-side scripting required by processing stuff in users' browsers. Because this website is relatively simple and won't be directly utilized by many people, these advantages of modern web stacks-- designed to build websites that can handle thousands or millions of concurrent users-- don't matter nearly as much as ease of maintainability.

Why Flask?

Once we have decided on Python for web development, we need to make a determination on whether to use Django or Flask, the two leading frameworks for building websites in Python.

Django is designed for much more complicated websites than what we would be building. Django has its own idiom that takes a lot of time to learn and get used to. Django is very fleshed out and exposes a lot of the in-the-weeds logic behind maintaining a website that will surely excite venerable web developers, but that's not necessarily what we need.

On the other hand, Flask is a very simple and lightweight framework built mainly around the use of its "app.route()" decorator. Essentially, you write functions that output strings, and those strings are rendered as HTML. Whereas Django feels like learning a whole framework, Flask feels comfortable and intuitive to anyone familiar with Python without demanding additional homework or web development expertise.

Granted, Flask is not quite that simple-- there are functions such as render_template, and you can flesh out a lot of HTML files marked-up with a tool called Jinja. But overall, Flask code ends up much closer idiomatically to conventional Python than Django code. So between the maintainability concern and the fact that it's not a particularly complicated website to begin with, we want Flask.

What else?

The rest of the stack is currently up in the air. We may want sqlite, or we may want Postgres. We may want Redis to manage caching our data pulls, or maybe we'd use something else. What about Celery? How about the modeling portion? Or perhaps a Twitter bot down the line? These are open questions.

We will have to make decisions on the stack we use based on available expertise, simplicity, appropriateness for the scale, and maintainability.

Clone this wiki locally

, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Stack Justification · codeforboston/flagging Wiki · GitHub
Skip to content
Stack Justification
Jump to bottom

Daniel Reeves edited this page May 10, 2020
·
4 revisions
As of writing, the only stack decision we've 100% decided on for the website is Python 3.7 and Flask. This leads to a natural question: why?
Why Python?
Our justification for using Python is that, due to how the CRWA tends to staff its team (academics and scientists), Python is the most viable language that a website can be built in while still being maintainable by the CRWA. The two most popular coding languages in academia are R and Python. You can't really build a website in R (you technically can, but really really shouldn't for a lot of reasons). So the next option is Python.
Even if the CRWA does not staff people based on their Python knowledge (we do not expect that they will do this), they are very likely have connections to various people who know Python. It is unlikely that the CRWA will have as many direct ties to people who have Javascript or PHP knowledge. Because long-term maintainability is such a high priority, Python is the sensible technical solution.
Not only is Python way more popular than PHP in academia, it's the most popular programming languagein general. This means that Python is a natural fit for any organization's coding projects that do not have specialized needs for a particular coding language.
There are a lot of disadvantages to building a website in Python, which is why most websites are built in LAMP, MEAN, Ruby on Rails, and other software stacks. Most of the advantages of other frameworks are performance related: for server-side scripting, Python is a very slow language compared to PHP 7. Also, many modern stacks are designed to facilitate reducing the amount of server-side scripting required by processing stuff in users' browsers. Because this website is relatively simple and won't be directly utilized by many people, these advantages of modern web stacks-- designed to build websites that can handle thousands or millions of concurrent users-- don't matter nearly as much as ease of maintainability.
Why Flask?
Once we have decided on Python for web development, we need to make a determination on whether to use Django or Flask, the two leading frameworks for building websites in Python.
Django is designed for much more complicated websites than what we would be building. Django has its own idiom that takes a lot of time to learn and get used to. Django is very fleshed out and exposes a lot of the in-the-weeds logic behind maintaining a website that will surely excite venerable web developers, but that's not necessarily what we need.
On the other hand, Flask is a very simple and lightweight framework built mainly around the use of its "app.route()" decorator. Essentially, you write functions that output strings, and those strings are rendered as HTML. Whereas Django feels like learning a whole framework, Flask feels comfortable and intuitive to anyone familiar with Python without demanding additional homework or web development expertise.
Granted, Flask is not quite that simple-- there are functions such as render_template, and you can flesh out a lot of HTML files marked-up with a tool called Jinja. But overall, Flask code ends up much closer idiomatically to conventional Python than Django code. So between the maintainability concern and the fact that it's not a particularly complicated website to begin with, we want Flask.
What else?
The rest of the stack is currently up in the air. We may want sqlite, or we may want Postgres. We may want Redis to manage caching our data pulls, or maybe we'd use something else. What about Celery? How about the modeling portion? Or perhaps a Twitter bot down the line? These are open questions.
We will have to make decisions on the stack we use based on available expertise, simplicity, appropriateness for the scale, and maintainability.
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Stack Justification · codeforboston/flagging Wiki · GitHub
Skip to content
Stack Justification
Jump to bottom

Daniel Reeves edited this page May 10, 2020
·
4 revisions
As of writing, the only stack decision we've 100% decided on for the website is Python 3.7 and Flask. This leads to a natural question: why?
Why Python?
Our justification for using Python is that, due to how the CRWA tends to staff its team (academics and scientists), Python is the most viable language that a website can be built in while still being maintainable by the CRWA. The two most popular coding languages in academia are R and Python. You can't really build a website in R (you technically can, but really really shouldn't for a lot of reasons). So the next option is Python.
Even if the CRWA does not staff people based on their Python knowledge (we do not expect that they will do this), they are very likely have connections to various people who know Python. It is unlikely that the CRWA will have as many direct ties to people who have Javascript or PHP knowledge. Because long-term maintainability is such a high priority, Python is the sensible technical solution.
Not only is Python way more popular than PHP in academia, it's the most popular programming languagein general. This means that Python is a natural fit for any organization's coding projects that do not have specialized needs for a particular coding language.
There are a lot of disadvantages to building a website in Python, which is why most websites are built in LAMP, MEAN, Ruby on Rails, and other software stacks. Most of the advantages of other frameworks are performance related: for server-side scripting, Python is a very slow language compared to PHP 7. Also, many modern stacks are designed to facilitate reducing the amount of server-side scripting required by processing stuff in users' browsers. Because this website is relatively simple and won't be directly utilized by many people, these advantages of modern web stacks-- designed to build websites that can handle thousands or millions of concurrent users-- don't matter nearly as much as ease of maintainability.
Why Flask?
Once we have decided on Python for web development, we need to make a determination on whether to use Django or Flask, the two leading frameworks for building websites in Python.
Django is designed for much more complicated websites than what we would be building. Django has its own idiom that takes a lot of time to learn and get used to. Django is very fleshed out and exposes a lot of the in-the-weeds logic behind maintaining a website that will surely excite venerable web developers, but that's not necessarily what we need.
On the other hand, Flask is a very simple and lightweight framework built mainly around the use of its "app.route()" decorator. Essentially, you write functions that output strings, and those strings are rendered as HTML. Whereas Django feels like learning a whole framework, Flask feels comfortable and intuitive to anyone familiar with Python without demanding additional homework or web development expertise.
Granted, Flask is not quite that simple-- there are functions such as render_template, and you can flesh out a lot of HTML files marked-up with a tool called Jinja. But overall, Flask code ends up much closer idiomatically to conventional Python than Django code. So between the maintainability concern and the fact that it's not a particularly complicated website to begin with, we want Flask.
What else?
The rest of the stack is currently up in the air. We may want sqlite, or we may want Postgres. We may want Redis to manage caching our data pulls, or maybe we'd use something else. What about Celery? How about the modeling portion? Or perhaps a Twitter bot down the line? These are open questions.
We will have to make decisions on the stack we use based on available expertise, simplicity, appropriateness for the scale, and maintainability.
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Stack Justification · codeforboston/flagging Wiki · GitHub
Skip to content
Stack Justification
Jump to bottom

Daniel Reeves edited this page May 10, 2020
·
4 revisions
As of writing, the only stack decision we've 100% decided on for the website is Python 3.7 and Flask. This leads to a natural question: why?
Why Python?
Our justification for using Python is that, due to how the CRWA tends to staff its team (academics and scientists), Python is the most viable language that a website can be built in while still being maintainable by the CRWA. The two most popular coding languages in academia are R and Python. You can't really build a website in R (you technically can, but really really shouldn't for a lot of reasons). So the next option is Python.
Even if the CRWA does not staff people based on their Python knowledge (we do not expect that they will do this), they are very likely have connections to various people who know Python. It is unlikely that the CRWA will have as many direct ties to people who have Javascript or PHP knowledge. Because long-term maintainability is such a high priority, Python is the sensible technical solution.
Not only is Python way more popular than PHP in academia, it's the most popular programming languagein general. This means that Python is a natural fit for any organization's coding projects that do not have specialized needs for a particular coding language.
There are a lot of disadvantages to building a website in Python, which is why most websites are built in LAMP, MEAN, Ruby on Rails, and other software stacks. Most of the advantages of other frameworks are performance related: for server-side scripting, Python is a very slow language compared to PHP 7. Also, many modern stacks are designed to facilitate reducing the amount of server-side scripting required by processing stuff in users' browsers. Because this website is relatively simple and won't be directly utilized by many people, these advantages of modern web stacks-- designed to build websites that can handle thousands or millions of concurrent users-- don't matter nearly as much as ease of maintainability.
Why Flask?
Once we have decided on Python for web development, we need to make a determination on whether to use Django or Flask, the two leading frameworks for building websites in Python.
Django is designed for much more complicated websites than what we would be building. Django has its own idiom that takes a lot of time to learn and get used to. Django is very fleshed out and exposes a lot of the in-the-weeds logic behind maintaining a website that will surely excite venerable web developers, but that's not necessarily what we need.
On the other hand, Flask is a very simple and lightweight framework built mainly around the use of its "app.route()" decorator. Essentially, you write functions that output strings, and those strings are rendered as HTML. Whereas Django feels like learning a whole framework, Flask feels comfortable and intuitive to anyone familiar with Python without demanding additional homework or web development expertise.
Granted, Flask is not quite that simple-- there are functions such as render_template, and you can flesh out a lot of HTML files marked-up with a tool called Jinja. But overall, Flask code ends up much closer idiomatically to conventional Python than Django code. So between the maintainability concern and the fact that it's not a particularly complicated website to begin with, we want Flask.
What else?
The rest of the stack is currently up in the air. We may want sqlite, or we may want Postgres. We may want Redis to manage caching our data pulls, or maybe we'd use something else. What about Celery? How about the modeling portion? Or perhaps a Twitter bot down the line? These are open questions.
We will have to make decisions on the stack we use based on available expertise, simplicity, appropriateness for the scale, and maintainability.
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
Stack Justification · codeforboston/flagging Wiki · GitHub
Skip to content
Stack Justification
Jump to bottom

Daniel Reeves edited this page May 10, 2020
·
4 revisions
As of writing, the only stack decision we've 100% decided on for the website is Python 3.7 and Flask. This leads to a natural question: why?
Why Python?
Our justification for using Python is that, due to how the CRWA tends to staff its team (academics and scientists), Python is the most viable language that a website can be built in while still being maintainable by the CRWA. The two most popular coding languages in academia are R and Python. You can't really build a website in R (you technically can, but really really shouldn't for a lot of reasons). So the next option is Python.
Even if the CRWA does not staff people based on their Python knowledge (we do not expect that they will do this), they are very likely have connections to various people who know Python. It is unlikely that the CRWA will have as many direct ties to people who have Javascript or PHP knowledge. Because long-term maintainability is such a high priority, Python is the sensible technical solution.
Not only is Python way more popular than PHP in academia, it's the most popular programming languagein general. This means that Python is a natural fit for any organization's coding projects that do not have specialized needs for a particular coding language.
There are a lot of disadvantages to building a website in Python, which is why most websites are built in LAMP, MEAN, Ruby on Rails, and other software stacks. Most of the advantages of other frameworks are performance related: for server-side scripting, Python is a very slow language compared to PHP 7. Also, many modern stacks are designed to facilitate reducing the amount of server-side scripting required by processing stuff in users' browsers. Because this website is relatively simple and won't be directly utilized by many people, these advantages of modern web stacks-- designed to build websites that can handle thousands or millions of concurrent users-- don't matter nearly as much as ease of maintainability.
Why Flask?
Once we have decided on Python for web development, we need to make a determination on whether to use Django or Flask, the two leading frameworks for building websites in Python.
Django is designed for much more complicated websites than what we would be building. Django has its own idiom that takes a lot of time to learn and get used to. Django is very fleshed out and exposes a lot of the in-the-weeds logic behind maintaining a website that will surely excite venerable web developers, but that's not necessarily what we need.
On the other hand, Flask is a very simple and lightweight framework built mainly around the use of its "app.route()" decorator. Essentially, you write functions that output strings, and those strings are rendered as HTML. Whereas Django feels like learning a whole framework, Flask feels comfortable and intuitive to anyone familiar with Python without demanding additional homework or web development expertise.
Granted, Flask is not quite that simple-- there are functions such as render_template, and you can flesh out a lot of HTML files marked-up with a tool called Jinja. But overall, Flask code ends up much closer idiomatically to conventional Python than Django code. So between the maintainability concern and the fact that it's not a particularly complicated website to begin with, we want Flask.
What else?
The rest of the stack is currently up in the air. We may want sqlite, or we may want Postgres. We may want Redis to manage caching our data pulls, or maybe we'd use something else. What about Celery? How about the modeling portion? Or perhaps a Twitter bot down the line? These are open questions.
We will have to make decisions on the stack we use based on available expertise, simplicity, appropriateness for the scale, and maintainability.
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Stack Justification · codeforboston/flagging Wiki · GitHub
Skip to content
Stack Justification
Jump to bottom

Daniel Reeves edited this page May 10, 2020
·
4 revisions
As of writing, the only stack decision we've 100% decided on for the website is Python 3.7 and Flask. This leads to a natural question: why?
Why Python?
Our justification for using Python is that, due to how the CRWA tends to staff its team (academics and scientists), Python is the most viable language that a website can be built in while still being maintainable by the CRWA. The two most popular coding languages in academia are R and Python. You can't really build a website in R (you technically can, but really really shouldn't for a lot of reasons). So the next option is Python.
Even if the CRWA does not staff people based on their Python knowledge (we do not expect that they will do this), they are very likely have connections to various people who know Python. It is unlikely that the CRWA will have as many direct ties to people who have Javascript or PHP knowledge. Because long-term maintainability is such a high priority, Python is the sensible technical solution.
Not only is Python way more popular than PHP in academia, it's the most popular programming languagein general. This means that Python is a natural fit for any organization's coding projects that do not have specialized needs for a particular coding language.
There are a lot of disadvantages to building a website in Python, which is why most websites are built in LAMP, MEAN, Ruby on Rails, and other software stacks. Most of the advantages of other frameworks are performance related: for server-side scripting, Python is a very slow language compared to PHP 7. Also, many modern stacks are designed to facilitate reducing the amount of server-side scripting required by processing stuff in users' browsers. Because this website is relatively simple and won't be directly utilized by many people, these advantages of modern web stacks-- designed to build websites that can handle thousands or millions of concurrent users-- don't matter nearly as much as ease of maintainability.
Why Flask?
Once we have decided on Python for web development, we need to make a determination on whether to use Django or Flask, the two leading frameworks for building websites in Python.
Django is designed for much more complicated websites than what we would be building. Django has its own idiom that takes a lot of time to learn and get used to. Django is very fleshed out and exposes a lot of the in-the-weeds logic behind maintaining a website that will surely excite venerable web developers, but that's not necessarily what we need.
On the other hand, Flask is a very simple and lightweight framework built mainly around the use of its "app.route()" decorator. Essentially, you write functions that output strings, and those strings are rendered as HTML. Whereas Django feels like learning a whole framework, Flask feels comfortable and intuitive to anyone familiar with Python without demanding additional homework or web development expertise.
Granted, Flask is not quite that simple-- there are functions such as render_template, and you can flesh out a lot of HTML files marked-up with a tool called Jinja. But overall, Flask code ends up much closer idiomatically to conventional Python than Django code. So between the maintainability concern and the fact that it's not a particularly complicated website to begin with, we want Flask.
What else?
The rest of the stack is currently up in the air. We may want sqlite, or we may want Postgres. We may want Redis to manage caching our data pulls, or maybe we'd use something else. What about Celery? How about the modeling portion? Or perhaps a Twitter bot down the line? These are open questions.
We will have to make decisions on the stack we use based on available expertise, simplicity, appropriateness for the scale, and maintainability.
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Stack Justification · codeforboston/flagging Wiki · GitHub
Skip to content
Stack Justification
Jump to bottom

Daniel Reeves edited this page May 10, 2020
·
4 revisions
As of writing, the only stack decision we've 100% decided on for the website is Python 3.7 and Flask. This leads to a natural question: why?
Why Python?
Our justification for using Python is that, due to how the CRWA tends to staff its team (academics and scientists), Python is the most viable language that a website can be built in while still being maintainable by the CRWA. The two most popular coding languages in academia are R and Python. You can't really build a website in R (you technically can, but really really shouldn't for a lot of reasons). So the next option is Python.
Even if the CRWA does not staff people based on their Python knowledge (we do not expect that they will do this), they are very likely have connections to various people who know Python. It is unlikely that the CRWA will have as many direct ties to people who have Javascript or PHP knowledge. Because long-term maintainability is such a high priority, Python is the sensible technical solution.
Not only is Python way more popular than PHP in academia, it's the most popular programming languagein general. This means that Python is a natural fit for any organization's coding projects that do not have specialized needs for a particular coding language.
There are a lot of disadvantages to building a website in Python, which is why most websites are built in LAMP, MEAN, Ruby on Rails, and other software stacks. Most of the advantages of other frameworks are performance related: for server-side scripting, Python is a very slow language compared to PHP 7. Also, many modern stacks are designed to facilitate reducing the amount of server-side scripting required by processing stuff in users' browsers. Because this website is relatively simple and won't be directly utilized by many people, these advantages of modern web stacks-- designed to build websites that can handle thousands or millions of concurrent users-- don't matter nearly as much as ease of maintainability.
Why Flask?
Once we have decided on Python for web development, we need to make a determination on whether to use Django or Flask, the two leading frameworks for building websites in Python.
Django is designed for much more complicated websites than what we would be building. Django has its own idiom that takes a lot of time to learn and get used to. Django is very fleshed out and exposes a lot of the in-the-weeds logic behind maintaining a website that will surely excite venerable web developers, but that's not necessarily what we need.
On the other hand, Flask is a very simple and lightweight framework built mainly around the use of its "app.route()" decorator. Essentially, you write functions that output strings, and those strings are rendered as HTML. Whereas Django feels like learning a whole framework, Flask feels comfortable and intuitive to anyone familiar with Python without demanding additional homework or web development expertise.
Granted, Flask is not quite that simple-- there are functions such as render_template, and you can flesh out a lot of HTML files marked-up with a tool called Jinja. But overall, Flask code ends up much closer idiomatically to conventional Python than Django code. So between the maintainability concern and the fact that it's not a particularly complicated website to begin with, we want Flask.
What else?
The rest of the stack is currently up in the air. We may want sqlite, or we may want Postgres. We may want Redis to manage caching our data pulls, or maybe we'd use something else. What about Celery? How about the modeling portion? Or perhaps a Twitter bot down the line? These are open questions.
We will have to make decisions on the stack we use based on available expertise, simplicity, appropriateness for the scale, and maintainability.
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
Stack Justification · codeforboston/flagging Wiki · GitHub
Skip to content
Stack Justification
Jump to bottom

Daniel Reeves edited this page May 10, 2020
·
4 revisions
As of writing, the only stack decision we've 100% decided on for the website is Python 3.7 and Flask. This leads to a natural question: why?
Why Python?
Our justification for using Python is that, due to how the CRWA tends to staff its team (academics and scientists), Python is the most viable language that a website can be built in while still being maintainable by the CRWA. The two most popular coding languages in academia are R and Python. You can't really build a website in R (you technically can, but really really shouldn't for a lot of reasons). So the next option is Python.
Even if the CRWA does not staff people based on their Python knowledge (we do not expect that they will do this), they are very likely have connections to various people who know Python. It is unlikely that the CRWA will have as many direct ties to people who have Javascript or PHP knowledge. Because long-term maintainability is such a high priority, Python is the sensible technical solution.
Not only is Python way more popular than PHP in academia, it's the most popular programming languagein general. This means that Python is a natural fit for any organization's coding projects that do not have specialized needs for a particular coding language.
There are a lot of disadvantages to building a website in Python, which is why most websites are built in LAMP, MEAN, Ruby on Rails, and other software stacks. Most of the advantages of other frameworks are performance related: for server-side scripting, Python is a very slow language compared to PHP 7. Also, many modern stacks are designed to facilitate reducing the amount of server-side scripting required by processing stuff in users' browsers. Because this website is relatively simple and won't be directly utilized by many people, these advantages of modern web stacks-- designed to build websites that can handle thousands or millions of concurrent users-- don't matter nearly as much as ease of maintainability.
Why Flask?
Once we have decided on Python for web development, we need to make a determination on whether to use Django or Flask, the two leading frameworks for building websites in Python.
Django is designed for much more complicated websites than what we would be building. Django has its own idiom that takes a lot of time to learn and get used to. Django is very fleshed out and exposes a lot of the in-the-weeds logic behind maintaining a website that will surely excite venerable web developers, but that's not necessarily what we need.
On the other hand, Flask is a very simple and lightweight framework built mainly around the use of its "app.route()" decorator. Essentially, you write functions that output strings, and those strings are rendered as HTML. Whereas Django feels like learning a whole framework, Flask feels comfortable and intuitive to anyone familiar with Python without demanding additional homework or web development expertise.
Granted, Flask is not quite that simple-- there are functions such as render_template, and you can flesh out a lot of HTML files marked-up with a tool called Jinja. But overall, Flask code ends up much closer idiomatically to conventional Python than Django code. So between the maintainability concern and the fact that it's not a particularly complicated website to begin with, we want Flask.
What else?
The rest of the stack is currently up in the air. We may want sqlite, or we may want Postgres. We may want Redis to manage caching our data pulls, or maybe we'd use something else. What about Celery? How about the modeling portion? Or perhaps a Twitter bot down the line? These are open questions.
We will have to make decisions on the stack we use based on available expertise, simplicity, appropriateness for the scale, and maintainability.
Clone this wiki locally