Open daviddyess opened 5 years ago
I will also run with whatever the majority picks. Here's my vote for go and Vue.js anyway :)
I'm in love with go right now, because developing with it is just pure fun. Building a REST API is a breeze. If you haven't played with go yet, search youtube for go REST API
and see for yourself. I also like that anybody can just go get gituhub.com/Korlimann/MixnJuice
to get the app and be done with it.
For the frontend: right now I'm playing with Vue.js and I kind of like it. I don't have too much experience with the other big ones like React or Angular to make an educated choice, but Vue looked more accessible to me. Regarding CSS I only know bootstrap, so that's that. Fun fact: once build, you can easily convert the js, css, html etc. generated by Vue into go code, go get
the frontend and have go serve the site with https and all the bells and whistles. No apache, nginx whatever needed. Supposedly this can handle all the traffic we could ever expect.
In terms of back-end code, I'd recommend Node.js for the simple reason that it means one language for all your back- and front-end code. That lowers the barrier of entry for developers and increases the pool of developers you can draw on. It is performant and has tons of solid, well-supported libraries for interoperability with popular technologies and systems.
That said, it seems we have some code in PHP already, and you can say most of the same things above about PHP - while it is not JavaScript, it is a scripting language that most programmers either know or could pick up quickly. It has many libraries for persistence and for API-building.
On the front end, I'd recommend React, regardless of anything else. Having used React and Angular professionally, I find the former to be significantly more flexible and powerful. I couldn't get into Vue but it seems like the Middle Path between React and Angular - the middle ground between least and most rigid.
In terms of UI frameworks, I think the following are all worthy of mention:
For CI, we can use Travis and/or CircleCI for free as an open source project. That gets us the ability to build and deploy on someone else's dime. In terms of hosting, an SPA that uses code-splitting is likely going to be the cheapest in terms of data transfer, so a tool like Webpack or Rollup will likely be part of the picture.
I'd encourage the use of SVG-based icons and eschew the use of images entirely if possible - saves a ton of data transfer.
For icons, the following are excellent:
I'd chime into the discussion but I feel like I'm the person with the least experience here. I want to do this because on one hand, I've received so much help from this community, I want to give something back. On the other hand, I think it's a great opportunity to learn new stuff and work together in a team. That being said, I'll happily go with anything the majority wants and I'll give my best at learning and working with that :)
Add my vote on node.js
I'm just going through the comments and trying to tie us into open source tools that may meet our needs.
If node.js and react are chosen to run the web site, I think Electrode could be considered: http://www.electrode.io/
Electrode is what Walmart.com uses.
I personally like vue.js, but I've used React (via Electrode).
While I hope all of us can contribute to all of the facets of the project in some way, I admit we will likely specialize in some manner and take on semi-specific roles. I'm thinking RFC#4 should probably be about developer roles and each of our intended/expected contributions.
Therefore, I believe it may be more appropriate for us to negotiate specific needs and desires within those roles. For instance, if someone is contributing more on the frontend and the design aspects, they should have more negotiation power within that aspect than someone who is mostly working on the backend.
This doesn't mean everyone doesn't have the power the make a choice, this is entirely a team effort. I'm just saying, to be fair and efficient, we need to ensure we are engaged in a team effort that best utilizes our abilities and ensures the best outcome we can obtain.
For example, I don't want us to choose z for x reason, when those of us contributing mostly to that facet would be better suited (and motivated) to use y.
Again, no one is above anyone else in this project, we are equals and our single responsibility is to provide the best possible product to the community.
… if you’re building a server, I can’t imagine using anything other than Go. Ryan Dahl creator of node.js
So, that's that :)
This is dependent on Issue#1, but we need to propose what we will use to build this.
Topics of concern:
Open API server backend language of choice (include a framework or platform if you have a preference)
Web Site backend language of choice (include a framework or platform if you have a preference)
Frontend Javascript framework
CSS framework
Utilities for rapid development
Utilities for rapid deployment
Sidenote: I started the API server using the Slim Framework, which is written in PHP. It's designed to work similar to node.js frameworks for routing and things like that and uses composer packages. With that said, this is a team project and I will go along with what the majority want to use.
Again, dependent on Issue#1, but we can have the API running something different from the web site.
If this becomes too heavy, please split topics into other issues.