3 ms·
I am no a JavaScript expert - I started playing with frontend (jQuery doesn't count) only recently. The only problem I have with your approach is that the mode
by eddd 11y ago
I am no a JavaScript expert - I started playing with frontend (jQuery doesn't count) only recently.
The only problem I have with your approach is that the model might mutate. For small projects it is ok - but for larger ones overriding state from many places generates pesky race conditions that are source of all evil.
I am not advocating for react as well - to me it is just a view layer. Combining it with redux, flux or any other library concept makes everything complex. And add javascript build tools on the top of that (good javascript sucks).
As a mostly "backend" developer (python, erlang, elixir) I really started to like ELM (http://elm-lang.org/docs#complete-guide http://elm-lang.org/docs#complete-guide) which solves all the problems as a language.
1. Language forces you to model-view-controller style
2. Language makes the model immutable
3. Language forces you to use correct types which saves a lot of trouble.
On the other hand, I a new to frontend - so I might be wrong.
- lisivka 11y agoJust use database at client side (e.g. PouchDB), which will solve your problems with concurrent modifications. Your Views will display data from DB. Your Controllers will put data into DB. Your DB will be Model. As bonus, PouchDB is able to replicate to CouchDB server without need to configure CouchDB at all (except CORS), which is superb for quick prototyping of real apps using clientside javascript only.