re: I'm planning on creating a website with NodeJS, What can I use to future proof it? VIEW POST

FULL DISCUSSION
 

Do yourself a favor and avoid all those three. Starting from the worst:

  • Template strings will be very messy, you do not get a good IDE support, and you will lack proper interaction (depends on how "static" your page is)
  • There is no reason to use MongoDB from the start. Fulstop. In general use SQL databases as long as you do not notice performance problems. Then you can either get familiar with scaling SQL or you can look at NoSQL. Transitioning from SQL to NoSQL is a lot easier than the other way round. Having a Schema in your DB helps you a lot in avoiding invalid data due to bugs which are common in the beginning.
  • Node.js, I always wonder why people choose node for production (!) software. It is slow, most of the trivial bugs you write (e.g. typos) are only detected at runtime (if at all) and Javascript as a language is weak. You basicly trust your business to a glorified text file

There is no "general" future proof stack. Pick the stack that's now the best for the job and not because they have biggest marketing claims (cough MongoDB cough). When I start a new project i basicly follow this plan:

  • Is it a website or an app (eg blog vs dataviz)

    • Blog: Static site generator, I like Hakyll a lot
    • App: continue

  • Which frontend framework (if app)

    • No react/redux (not a framework, but also not a simple library, forces you do follow weird OOP approach, in case of redux a lot of boilerplate)
    • No Angular (Bloated, too much "magic", if something fails, reason is not clear)
    • I like Cyclejs, but as Co-Maintainer I'm biased. I would recommend Cycle if you want to do a lot of async stuff (e.g. websockets)

  • API

    • No Node, see above
    • I've grown to love Haskell servant, which lets me specify the URL, let me write the handler and does all the plumbing for me. Also the type system saves you a lot from errors

  • What type of data do you have

    • Logging data (mostly append): TimescaleDB (Postgres plugin)
    • CRUD: Postgres/MariaDB
    • Images/Videos: Document database (NoSQL)
 

If you find that Node is slow, there is something horribly wrong in the way your app is either written or deployed.

Next, every languages represent code as "text files"... compiled or not makes no difference. Code is a human readable set of instructions. The fact that it is not compiled does mean possible runtime uncaught exceptions. This is why we have linting, unit tests and acceptance tests... If, regardless of thise you still get errors, it brings me back to my first point: you're doing something horribly wrong.

An application is, in essence a group of tools, like a db, an http server, some caching, etc. With the language simply acting as a glue between them. I don't beleive that a language can be categoricaly inferior or superior to another one- just that they all have their perks. JS for APIs is a real breeze.

If you need some help setting it up, hit me up, my fees are reasonnable ;)

 

The glorified text field was refering to no type system that protects you. Unit test are no replacement for a type system.

Node is slow. I did a few benchmarks before choosing my Stack and node was the slowest of them. My Haskell server could handle twice as many clients before maxing out my test rig.

Js is not a breeze, it's horrible. The express API is the worst API i have ever seen. I would never even consider node for anything more than a prototype.

To each its own, innit?

Nodejs is awesome if you REALLY KNOW nodejs. So is anything else you REALLY KNOW...

code of conduct - report abuse