New projects - use a new tech stack or existing project boilerplate?
I'm curious what your thought process with starting new projects. Do you use an existing boilerplate without modification, use an existing scaffolding but try a couple of new components/modules, or shake things up by trying out new frameworks or services? I know this is a little generic and that projects differ quite a bit, but would like to see other peoples approach. The engineer in me leans towards new frameworks, but my practical side of me keeps me in check by starting with an existing scaffolding with the addition of a new/different module or service.
Depends on your goals.
If you want to try/learn something new and don't care about time then go with a new stack.
If you want to ship something quick and not worry about learning new things then go with an existing stack.
In rare cases you might also be dictated by the problem space. A while back I had project that had a lot of need for concurrency so I decided to drop my familiar PHP and pick up something new.
Agreed.
Start with defining how you're going to determine if the project is successful or not. Time to market? Maintainability? Learning a new framework? Revenue? Ability to talk about something at a conference?
Then work back from there.
Just kicking around an idea? Go with what you know. Wanting to learn? Go with the new stack. Building something for someone else? You might need to pick the stack they know so they can support it long term. Could someone take a serious credibility hit if the job goes south technically? Might want to go with something that's more proven than the 'coolest cutting edge language'.
A few years ago I spent about a month reviewing web app frameworks at TodoMVC.com with the intention of finding what was "best" to upgrade some old Perl based web apps I first released back in 2002.
When I was finished going over those frameworks that interested me I couldn't decide when was best. I gave myself over a week to review them again and ponder it, and still couldn't. The reason was, I finally realized, is that I knew I'd have to invest a lot to really get up to speed with whatever I chose.
Stressing over that led me to ponder instead what was "easiest" for me. That opened up a lot of new ground to explore and what I ended up using was no framework at all.
On the server side I use the Apache web server and CouchDB. On the client side I use PouchDB, jQuery, Mustache, and Bootstrap.
When you add "Service Workers" to those you've got an offline first, reactive UI, multi-user app with built-in user authentication and live data sync across all the connected devices.
If you're coming from a LAMP stack and are a hard core SQL user it might not be for you. But, if you're willing to give it a shot you'll find it's an incredibly productive toolset with an almost seamless API that has an amazingly deep feature set. And you can drop in all kinds of little Javascript libraries to handle specific chores.
Apps made this way are fast because the app code is stored and runs almost entirely on the client side. It only connects to the server to authenticate a user and sends only the data a user requires to be sent in both directions, and with no formatting data (html/css or Javascript) at all. It only downloads app data when the app has been updated.
There are all kinds of configuration options with these tools. Offline only, offline first, web first, web only, remote data storage, in-house data storage, 3rd party data services (IBM Cloudant), and even running and serving the entire app in node.js with just PouchDB and no CouchDB at all.
And, of course, you don't need jQuery to do most of the DOM work but since it's there with Bootstrap you have it and it's easy to use and familiar for most of us and has a ton of example code on Stackoverflow that makes it easy to keep getting stuff done.
PouchDB/CouchDB offer an entirely different way of doing things, but it's a very easy to get started with and powerful way that was built from the ground up for "web apps".
Service Workers are now implemented broadly enough to make those apps run entirely offline on almost any device and the way they sync data with remote servers is like magic. You can make it happen all in the background and it just works, and you can give the user a button to push to make it happen on demand whenever they want.
For me, these features are something I've waited for almost 20 years to come, and these tools make it amazingly easy to implement them.
I have a demo at https://cherrypc.com/todo you can check out. You can download the code at https://cherrypc.com/todo-3.zip. That is a offline only app. Once you go to that page it will work until you delete it from your web browser cache and it doesn't connect to my server again unless I update the app.
Depends a little bit on what my goal is and where my skillset is at - for my current project https://harvy.app, I didn't have any experience with React but I knew it was the latest/hottest technology, so I wanted to learn it. If I want to get something out the door ASAP, I use something I already know so I don't have to deal with any learning curve. If I want to be a part of the journey, learn something new along the way, and don't have as tight of a deadline, then I try and pick something new to learn and advance my skills.