Languages and technology discussion

[KenavR]

Before we can start we need to make some decisions on which languages and which technology we want to use.

Front-end

I believe since we have a lot of people just learning HTML/CSS/JS we should stick to these technologies. For version 2.0 we could introduce a framework/library in the future.

Back-end

Is a little bit tougher, I have no idea what people are learning or interested in. I personally have at least some experience with a lot of the popular languages but no real preference. I believe the languages new developers come across the most, are PHP and NodeJS (JS), if we limit it to these two languages my vote is for NodeJS, not because I think it is better, but because I have more experience with it and I don’t know how much time I have to look into the “harder” requirements for this project. The backend may also be harder, because doing more than the basic stuff without using the ecosystem is unnecessarily hard, therefore there is an additional start difficulty of setting up and understanding the ecosystem/tools.

Data Store

The primary question is if we want to use a SQL (PostgreSQL, MySQL,...) or NoSQL (e.g. document store like MongoDB) data store. I personally worked with both, but lately, I am back on the SQL train. I will support the choice of the majority. There are arguments for both sides, but I believe it mainly comes down to what the majority wants to learn/work with.

Architecture

There are certainly some architectural decisions that make it a lot easier to work in teams. My question is, should more experienced developers provide tools and a ruleset on how to structure an app or are we going to figure it out together?

[yochrisbolton]

I use MeteorJS a lot, which is using the Node Stack with MongoDB. I think it's really good for beginners as it has everything you need to dev in one package with an awesome community built around it.

It makes it really easy to prototype and deploy live apps!

However it has some drawbacks, mainly being that its way of doing things aren't like traditional stacks, so it doesn't really teach you best practices in a 'real' full stack environments.

A secoond problem is that is uses the Blaze contemplating language (which is great) which only works in Meteor. ( however it is based on mustache templates )

[SpaceOso]

Don't have much to add but would like to add my vote for Node and PostgreSQL

[Tor020]

As far as general language suggestions, i'd swing for Node.js + MongoDB. I know the generals of MySQL personally, but I feel like MongoDB is much easier to pickup and get started with compared to MySQL. Additionally, For the reasons of more potential devpower from everyone knowing the basics of JavaScript, Node.js for the backend seems like a good choice.

My ideology on tooling for the most part consists of, if the tool fits the job then there's no reason not to use it. If theres a technology choice that makes sense for the project, and more senior devs have experience with it i absolutely feel as though it should be utilized for the project. It would do a good job better simulating a realworld scenario, and learning how things actually happen is just as valuable a learning component as learning fundamentals.

The caveat here being that if we do choose to use technology, we should provide good links in the documentation for contributing so that it's easier for those unfamiliar with the tools to get started learning the concepts associated with the tools.

[KenavR]

@finchMFG I haven't used Meteor myself, but I know off it. If I remember correctly, it supports other front-end technology than Blaze (React, Angular). Anyway, I think your first drawback disqualifies it for the first project. I think it is a very good framework for getting shit done fast, but if your main objective is to learn the "basics" it's the wrong tool.

@Tor020 I agree that relational databases and SQL are pretty big subjects, which we can certainly do without at the beginning. Anyhow, I still believe almost everyone should learn about RDBs and SQL at some point in there learning process or career.

I believe we should keep tooling to a minimum, without rewriting every library out there. It basically comes down to "Does the expertise of knowing the library outway your ability to write that library on your own". I am currently working on some front-end helpers to make separation easier, but I have the feeling I am essentially writing parts of React, Vue or Angular.

[Tor020]

Yeah I agree with you about databases.

I tend to think about learning / understanding frameworks in two pieces. One part of it is to know conceptually what it is the framework is doing. Another is to know what that tool/framework makes possible or makes easier. After those two things are well understood the rest of the logic behind the tool has diminished returns in terms of value from understanding versus time spent recreating all the moving bits behind the scenes. The problem solving ability that comes with being any type of programmer should allow people to take it down the logical path if they need to in the future.

As an example, for React

React is a JavaScript library that aims to help us write user interface(UI) code. React’s fundamental building block is the Component which, in its simplest form, is a JavaScript function that generates UI code (usually HTML). The generated UI code is then rendered by the device. A Component represents a small portion of the UI. Many Components are used together, or composed, to create entire views or applications. React Components can receive data that is used to generate the UI code. Whenever a Component’s data changes, it will automatically regenerate the UI code. source

Understanding a concept like that I feel is the most significant part of learning a framework, not because you actually know literally what the javascript is doing behind the scenes, but because that gives enough information to rebuild that functionality by figuring out how to break that down into smaller pieces. That does make several assumptions about the developer working on the problem however.

Either way, that's just my take on it though, I'll support your decision here.

[KenavR]

We will start with NodeJS and mongo on the back end. I will add around 20 issues today for people to work on and set up the back end.

For people who want to read up on libraries we use on the back-end
ExpressJS (http://expressjs.com/) - A library to write REST APIs
MongooseJS (http://mongoosejs.com/) - Is ODM (Object Document Wrapper) which allows you to work with simple Javascript objects and store them into the datastore.

Install MongoDB (instructions may follow)...

For the most part, there will be example code for this library in the project (for express there already is) and it will be mostly configured already.

[ozgunbal]

What do you think about using ES6 Javascript? I generally prefer using const, let, arrow function etc. Latest NodeJS supports these features at least for the back-end but it also be added for front-end with babel transpiler.

[KenavR]

Personally, I use transpilers and other tools for all of my projects, but here we deliberately made the decision to use just the basic technology supported by the browser. This should allow everyone, even if they are just learning HTML/CSS/JS to contribute.

In the future, either in a later version of this project or a new one, we will introduce new tech and transpilers are certainly one of the first.