Pretty cool/interesting. For the most part, I've stuck with marked and try to stick as closely to gfm as reasonable. I have on occasion added additional emoji support, but that's all I've found that I needed.
Recently added a layer to present a medium-style editor over the top, and that has been a huge set of frustrations in order to filter for nefarious content (xss).
Part of the exercise is to practice writing clearly. This is a very important skill in a number of fields, in particular medicine. When legal, medical or engineering notes are hard to read, especially potentially a while after written there is the opportunity for bad things to happen or the inability to find context later on.
While I appreciate the effort and think the project is cool, I find that the purpose of side stepping part of the exercise/assignment isn't such a great idea.
When generating your droplet, just use your public key instead of a passphrase here, it will allow you to skip several steps.
I would also suggest using dokku and add the letsencrypt plugin once you have your app in place. Deployment becomes as simple as a Dockerfile and a `git push deploy` from your repository. It takes a tiny bit of work, and really less than the article's approach. Note: make sure to run the command to setup the letsencrypt cron job. And you can set the letsencrypt contact email as a global config entry.
You may want to deploy dokku in your own ubuntu container just so you're more prepared for updates, that said it's pretty straight forward and will allow you to host several applications.
One warning is that if you're using the $5 droplet, you should setup vram. I tend to go for the $20 droplet, but I can host a dozen small sites without issue and get easy https to boot.
http://dokku.viewdocs.io/dokku/
#3 is not quite correct... all inheritance in JS is prototype based, even if using the class syntax, it's sugar over the prototype model.
Prototype based inheritance in JS is kind of like a search path... is property X on the object, on it's prototype, and so on down the chain. You can also use Object.create({...}, null) to inherit from null instead of Object as a base prototype.
#4 somewhat disagree on the FP cons... even before I understood what FP was, I leaned into that style far more early in my career... prefering utility functions and composition over class methods. I didn't come at this with a formal education, and even then tended towards FP practices.
On the flip side, class syntax/structure is useful when you need to bind state and behavior. This can be useful in certain types of components, though I prefer React + Redux, with other libraries using class syntax is easier to reason with.
#6 I'd add that when using the prototype the properties aren't serialized by default (Object.keys/entries) and this can be beneficial if you want utility properties/methods but don't want them serialized. There are other ways to do this, but the prototype is a relatively clean break for this behavior.
#9 While I appreciate micro-services, the orchestration can often be more work than the application development itself. If you don't have dedicated resources to this operation design and overhead it's usually not a good idea. If you're leaning on a cloud platform and they offer things like lambda (aws) or functions (azure) then it might be worth leveraging these things earlier. Otherwise stick closer to the monolith model and then break off pieces that tend to bottleneck or can be parallelized or separated out via a queue system first.
I'm also in general a fan of a dedicated server api for the ui, even if there's a more formal set of APIs behind it... this can allow more edge-line utility on a server before the internet latency becomes a thing. GraphQL is another similar example of this approach. I find that node/js is a very good fit here as you can leverage the same mindset/language without the disconnect at this level.
#10 kind of a sloppy definition, but mostly correct in the context of node and the browser.
While I love JS... I'm not sure it's the best language for beginners. The only real advantage it has is accessibility, you can play in a browser without additional tools, since pretty much any desktop computer, and even example websites are easy to use from pretty much anywhere.
That said, I'm unsure that other languages wouldn't be better to start with. JavaScript is incredibly flexible, and conceptually that's a benefit, for a beginner it's a massive hindrance. It's way too easy to muddle concepts in JS, and without the experience to know when one approach may be better than others, you wind up in a weird path.
Of course, I've also seen this with experienced developers, who are new to JS, so I could be entirely wrong on this.
Duomly is pretty much spammy content... they've been blocked on as many independent sources as I can do... dev.to, medium and github I can't reasonably block because there's too much relevant content.
#3 is not quite correct... all inheritance in JS is prototype based, even if using the class syntax, it's sugar over the prototype model. Prototype based inheritance in JS is kind of like a search path... is property X on the object, on it's prototype, and so on down the chain. You can also use Object.create({...}, null) to inherit from null instead of Object as a base prototype. #4 somewhat disagree on the FP cons... even before I understood what FP was, I leaned into that style far more early in my career... prefering utility functions and composition over class methods. I didn't come at this with a formal education, and even then tended towards FP practices. On the flip side, class syntax/structure is useful when you need to bind state and behavior. This can be useful in certain types of components, though I prefer React + Redux, with other libraries using class syntax is easier to reason with. #6 I'd add that when using the prototype the properties aren't serialized by default (Object.keys/entries) and this can be beneficial if you want utility properties/methods but don't want them serialized. There are other ways to do this, but the prototype is a relatively clean break for this behavior. #9 While I appreciate micro-services, the orchestration can often be more work than the application development itself. If you don't have dedicated resources to this operation design and overhead it's usually not a good idea. If you're leaning on a cloud platform and they offer things like lambda (aws) or functions (azure) then it might be worth leveraging these things earlier. Otherwise stick closer to the monolith model and then break off pieces that tend to bottleneck or can be parallelized or separated out via a queue system first. I'm also in general a fan of a dedicated server api for the ui, even if there's a more formal set of APIs behind it... this can allow more edge-line utility on a server before the internet latency becomes a thing. GraphQL is another similar example of this approach. I find that node/js is a very good fit here as you can leverage the same mindset/language without the disconnect at this level. #10 kind of a sloppy definition, but mostly correct in the context of node and the browser.