About Effective Web-Development
I want to share some experience I made throughout various projects, as a team member in big companies or as a developer for startups on a tight budget. Why a jelly-fish? Fun fact: they are the most energy effective animal on the planet!
What is a good software design
Deciding on a software design is crucial, but it is even more crucial if the architecture cannot be changed easily. I do not know who said it, but I think it is a pretty good definition:
Comparing two software designs, the one that can be changed more easily is the better one.
That is why modularity is important, small specialized modules with a small api, that can be pulled out and replaced easily. If you start like this, it easy to adapt to future challenges. You can start small and go big ;)
There are a lot of articles this vs that, that gain a lot of attraction, but I think the answer is not rarely: both or does not matter. Each successfull technology has its strengths. Functional programming is better than OO programming in some cases, in others it will be the other way round. The great thing is, that there are many ways to combine different services. You can start with an MVP solution and later replace parts of it with a specialized service that performs better. Of course there are other things to consider, for example the future of a technology, is it backed by a big community or company etc. (Hint: check the Github contributors, not the stars :)) )
There is a trend to do many things in the frontend and use the backend as an api. There are definetly use cases for that, but you should think about the cost for taking that route. The moment you are going full frontend, you are throwing away a lot of knowledge that exists on the serverside. A framework like RubyOnRails ‘knows’ your routes and database structure and provides a lot of helpers that use that knowledge to make your life easier. Building ‘just’ an Api is also not necessarily a time saver on the backend side, as it has to be documented and communicated and is not less work than putting together some HTML templates.
Of course you cannot present a webapp that behaves like in the 90s. But that has not so much to with choosing a JS framework as you might think. Take Youtube, until lately - before rewriting everything in the Google Polymer framework - they used a thing called SPF that replaces parts of the DOM with HTML rendered on the server. Rails uses Turbolinks, Github used or uses a similar approach. Did you notice any difference in the experience using Youtube lately? I didn’t.. There might be one, but in my experience going full js in the frontend takes a lot more (wo)man power and it might not justify taking that route if you do not have a highly dynamic UI.
Best of both worlds
I made very good experience using serverside rendering for the not so dynamic parts combined with Ajax page replacement (Turbolinks, SPF), and something like reactjs for dynamic components. One great thing that was added to React 16 is portals. It lets you render your react app in different places in the dom. What I like about react, preact etc. is the small Api that can be drop-in-replaced, it is not a framework itself. By using this approach you do not need to use complex code where not needed, e.g. an imprint page using AngularJS :)
Please do not just use stuff because you read it on this ‘internet’
That also counts for this little article ;) There is not really a good or bad technology, but bad use cases. When easy things get too complicated, there is no reason to take the path. I read questions on github where people ask if it is ok to do things with some js framework trying to do a simple fetch request. There is no benefit in using a technology just for the sake of using it.
It is important to have a good time when coding to get a good product. For me it boils down to this: if something does not work, best case scenario it is some mistake I made that makes sense. Or in other words: the technology works as expected. As it is all numbers, of course everything is logical somewhere, but I hope YKWIM ;) On the other hand the language itself is important, and you can only compare what you have used to some extend, that is why I like try out stuff myself, best case with a small real world project.
Tough things first
What I like to do is solve the tough things first and get a minimal valuable product that is usable. By doing so you see that things work out as you expected and you have the possibility to make radical decisions early in the project without too much refactoring. So take the most complex task and implement it. If you are ok with the solution you have a solid foundation to build upon.
Last things last
Dependent on your situation effectiveness might be more or less important to you. But even if parts of my point of view are somewhat from an indie-developer/startup perspective, I think starting with a solid foundation and improving on it can be applied to many projects out there. Getting stuff done quickly cannot be such a bad thing in the end :)