3 ms·

IMO the current SPA vogue is overkill for basic CRUD requirements like you have described, particularly if it's a business-oriented product. Unless you are plan

IMO the current SPA vogue is overkill for basic CRUD requirements like you have described, particularly if it's a business-oriented product. Unless you are planning to build something that is very consumer-focused with high levels of interaction that will compete with other, established SPA-style offerings, then the traditional server-side approach is all you need (think: choose boring technology). My personal advice based on your skill set is to investigate a straightforward server-side framework such as Flask, which I believe uses the established MVC pattern. Choose a single framework like this, and stick with that as your "one token of innovation". Build up the rest (e.g. client side) using technologies you're already familiar with. On a subsequent project, you can dip your toes into a client-side framework such as React, to give you a taste of what might be useful for you from the contemporary suite of tools. Then you can decide whether it's valuable for you or not, based on cost/benefit.

ab_testing 6y ago
I want to dip into react or blueprint.js due to the data heavy side of this application. However the tutorials around react all assume using non that loads a ton of dependencies that makes it difficult to judge what all is going into production .
- trilinearnz 6y ago
  There's a certain amount of "just the way it's done now" to the NPM dependency topic. A bit like how with the .NET ecosystem everything has turned into many dependent Nuget packages whereas before it was all integrated into coarse-grained DLLs. Not getting bogged down in the hell that is the dependency upgrade cycle is a key concern here. If you can accept the inevitability of a bit of noise when it comes to this, you will eventually become familiar and comfortable with the chatty output of the NPM build process. Maybe you could decide on a particularly stable (LTS) release of React, that may not be subject to too many dependencies which are in a state of flux?

ab_testing 6y ago

I want to dip into react or blueprint.js due to the data heavy side of this application. However the tutorials around react all assume using non that loads a ton of dependencies that makes it difficult to judge what all is going into production .

trilinearnz 6y ago
There's a certain amount of "just the way it's done now" to the NPM dependency topic. A bit like how with the .NET ecosystem everything has turned into many dependent Nuget packages whereas before it was all integrated into coarse-grained DLLs. Not getting bogged down in the hell that is the dependency upgrade cycle is a key concern here. If you can accept the inevitability of a bit of noise when it comes to this, you will eventually become familiar and comfortable with the chatty output of the NPM build process. Maybe you could decide on a particularly stable (LTS) release of React, that may not be subject to too many dependencies which are in a state of flux?