10
kamen
145d

To finish my photography portfolio website and get it online. I've been putting this off for YEARS. Just started again (and from scratch) and I've been making some progress for the last couple of days. I don't want to even look at that old project I scrapped, or maybe I will once I finish (read: publish) this one.

My problem before was that I was always looking at the big picture and was trying to figure everything out in one go.

In contrast with that, I now figured out a relatively simple and straightforward way to start off with no back end at all and just use static resources instead (with some logic to parse them every time I "upload" new stuff), which should be fine even in the long run if I end up being too lazy and/or busy to do the back end. In general, I now try to tackle small tasks one by one (even if I don't always write them down and/or track them) and realise that it's better to be done (even not in the best way I imagine it) than to not be done at all. It's as if I learn how to do stuff properly for the first time. Oh, well...

Comments
  • 1
    What's the stack you are trying to build it with?
  • 1
    @Ison Currently it's React (with TypeScript of course), Valtio (because it's way more straightforward and way simpler than Redux for such a small scale thing) and Material UI (something to step on because I absolutely suck at writing HTML and CSS by myself).

    I'm a beginner with React (I haven't used it professionally), so maybe there are going to be some things that are not done the best way (from the perspective of React), but that's one way to learn I guess.
  • 1
    @kamen

    If you suck at writing HTML and CSS, then it seems to me as if you're trying to drive a car while not knowing how to really ride a bike.

    You don't need to reach for a state management library if you barely have any state to manage (you said your app's scale is small - I assum that it's basic/simplistic in functionality). It's better to stick to what React itself provides (state hooks, React context) before reaching for libraries.

    React is undoubtedly practical and popular, but it is a fairly serious tool. I'm confident in my belief that most people are overengineering their simple applications by thinking they need all these fairly advanced things just because "everyone is using them".

    My advice is keep it as simple as possible. Don't solve problems that don't exist yet. If you make this project harder than it needs to be, then you're also making it harder for yourself to actually deliver something and to feel that accomplishment.
  • 0
    @Ison My point with HTML and CSS is that I spend way too much time for simple things - that's why I prefer using something tried and tested. Since the main thing on the site will be my own content, I'm not too concerned that the components themselves would look similar to something else; moreover they allow styling on top of them, so that's a possibility for a later point.
  • 0
    @Ison As for state management - sure I can do it in plain React, I just don't really like how it's done. Moreover I like this library's approach in particular. I've used NgRx in Angular before and it was kind of an overkill even for larger scale apps - mainly because it requires a lot of boilerplate code (and now that I got a refresher on Redux, I realised how similar they are - after all NgRx is modelled after Redux). Again - maybe it's not the best approach, but it works so far, and what's more important for me right now is that I'm comfortable with the stack enough to be able to focus on the logic and not spend time on thinking how exactly to implement it. A library would be an overkill if it gets in the way of the implementation or if it weighs the bundle too much - and right now I don't have a problem with either.
Add Comment