That being said, there is something for the pressure cooker environment that forces you to consider and learn the hard topics. I have gone back to school twice as an adult, first for a pure math degree, and now for comp sci - machine learning. Both times, the amount of pain it takes is just not something a person with average or above average motivation would go through on their own.
True, though on the flip side sometimes it is easier to take the time needed for deeper understanding outside the pressure cooker environment of classes. Pressure cooker environments can be motivating to keep moving forward, but sometimes at cost of depth and intuitive understanding.
Second this. I have learnt about so many new technologies from HN, that 1) it pushed me to finally start my own venture, and 2) the technologies I have learnt about and use in my daily stack all came from HN posts over the years
First, do know that the scope you have outlined is a huuuge undertaking. Maybe think of limiting the scope to start off with (inventory mgmt OR dealer mgmt OR accounting OR payroll). For tech stack, my suggestion is to use a back-end that provides as much out of the box as possible.
Ruby on Rails provides huge bang for the buck with their integrated database ORM, as does Phoenix (what I used). Your scope involves a lot of referential data, stick to traditional robust SQL database system (Postgres for example). If you use a NoSQL db, you may be quicker out the gate (as it'll take any JSON you give it), but once you get to the analytics with lots of joins, it won't be as much fun (personal experience).
Also, I would suggest using the server frameworks' rendering engine to get your MVP up and running, as you can then fast iterate between data model changes and visual representation (i.e. HTML output), and avoid front-end builds and all that encompasses. Phoenix is very snappy, and with something like Turbolinks can potentially be as snappy as a dedicated front-end app.
Personally, I needed very interactive front-end, so had to build a separate front-end using Ember. I found Ember with Ember Data provides a robust toolset that manages complex data. I also have experience with React and Vue, but keep in mind with their state management (e.g. Redux / Vuex) that you'll need to manage complex data relationships yourself.
As far as mobile, don't think native, as you'll need to learn specific technologies to implement that as well (more time...). Grab a bootstrap template that is already responsive, and you can run the same web-site on an iPad (forget the phone initially).
Good luck!
source: just finished a 2 year build of an investment-related accounting and analytics webapp
I've used Vue pretty much daily over the last year in a fairly complex app (some 150+ components, Vuex store with 100+ actions, full client side router navigation) and it has been pretty pleasant. I even contribute a nominal amount to the Patreon campaign.
However, the upgrade path from v1 to v2 is not a quick undertaking. Certain changes require a revisit to practically all components (e.g. change of 'ready' to 'mounted', v-el to ref etc.) that don't really bring a lot of value to the end user other than change in semantics. The upgrade diagnostic tool is a great feature, but seeing 600+ breaks in your app is not so much fun. Changes in Vuex (e.g. no more vuex: getters in the components, 'dispatch' is now 'commit' in the store modules) translates to significant work in a largish app just to upgrade semantics.
Also, the article references the verbosity of Redux with respect to forms. In all fairness, all Flux implementations, including Vuex, have pretty much similar verbosity.
Just providing some balancing thoughts for folks to be aware of before investing heavy time in any framework, including this one.
> To take one example, UI code is wonderful stuff for adding end-user value. But if you want extreme leverage in your code it can't be the first priority, because it's also stuff that tends to be thrown out frequently - because other features change, or you're on a new toolkit, or you found a slicker design. You have to instead allow the UI to be too crude at first, and think about application features as a layer apart from the UI. And then only as you come towards the end, confident that the core features are correct and will be robust against a partially-working UI, can you go back and invest in a great presentation.
This bears repeating a hundred times over. All the more pertinent today when there is an endless stream of shiny web UI frameworks that constantly tempt all but the most disciplined and hardy devs.
Ok, I read through this whole thread and with the variety of recommendations for frameworks and tools mentioned it will make your head spin for sure.
You mentioned Vue, so I will talk about Vue. Vue will get you there in terms of any complexity you may need. React, Angular, Ember, etc. will also get you there, but you mentioned Vue so let's stick to that.
Wrt boilerplate templates: just use vue-cli to generate the project, there are not even that many options, and you get hot-reloading, test harness with it automatically.
To keep it real, I imagine your SPA will need different sections of the screen to show: a header, some kind of menu (sidebar?) and a main window that shows what the user is working with for the moment. How do you get the main window to show the relevant content if the user clicks on a menu item? If you solve that (hint: vue-router), you now understand one of the main benefits of using a front end framework for managing components and avoiding round trips to the server.
Next challenge: create a nice page that has, let's say, two different panels. One panel shows a list of items, and the other panel shows some details about the currently selected item from the list. How do you: 1. show the details about the selected item in the second panel? 2. If you change the item name in the detail panel, will it update immediately in the list above? Solving for this will satisfy your curiosity of why a state management solution would be useful, and you'll be led to ...... yes, Vuex!
These 'challenges' would be enough for a good 90% of common web apps/SPAs, with navigation and master-detail UI.
Just one piece of advice, pick one current framework, learn it by solving these common problems, and you'll be on your way.
Source: I have built and rebuilt a complex system in Angular, Meteor, React and Vue (I do NOT recommend that kind of churn, but keep in mind each framework have had significant shortcomings over that past 2 years which made client-side state management difficult).
If you take the intellectual route and try to do all this with vanilla JS or solely jQuery, be prepared to spend a while before becoming productive (depends on your app's complexity of course).
I have the same problem. The only thing that works for me is working in a set number of pages per day as a goal, say 10. That way, even a medium to large sized book can be covered in 1-2 months.
That's what reviews are for, unfortunately as hosts, in the current environment of rapid expansion by AirBnB, it works out to typically 75% of inquiries are from new users with no reviews. So there is very little to go by when accepting people to sleep in your home with you.
