How to build apps pragmatically(alextoussaint.com)
alextoussaint.com
How to build apps pragmatically
https://alextoussaint.com/2020-02-01_How-To-Build-Apps.html
50 comments
I'd add from my experience: decide if you want to have a product at the end or learn something. I've tried a few times to "do this thing while also using X to learn about it". Every time I did learn about X. Rarely did I ever end up with the expected end product though (because learning and trying new things gets in the way of actually completing until I ran out of time/steam)
It's odd the author chose Django because it's "popular" and dismissed PHP because it's "old".
Laravel is far newer and more popular than Django and PHP is both newer and more popular for web dev than Python.
Why would the author insinuate Laravel (and presumably WP and the rest of PHP) will be dead by 2030? For that matter, is it pragmatic for a startup to worry at all about what the best choice ten years in the future will be?
Laravel is far newer and more popular than Django and PHP is both newer and more popular for web dev than Python.
Why would the author insinuate Laravel (and presumably WP and the rest of PHP) will be dead by 2030? For that matter, is it pragmatic for a startup to worry at all about what the best choice ten years in the future will be?
To be fair, per their About page, the author is 18 :)
> Why would the author insinuate Laravel (and presumably WP and the rest of PHP) will be dead by 2030?
I think the author meant that writing a complex server-rendered webapp in PHP would take very long, hyperbolically saying it would take until 2030.
I think the author meant that writing a complex server-rendered webapp in PHP would take very long, hyperbolically saying it would take until 2030.
Ah, ok. That's slightly less strange, but still very strange given the productivity and ecosystem size of Laravel vs that of Django.
You've got it all right!
why is this trash got submitted? author picked Django but trash talk PHP. Apple to Apple. shouldn't you compare Django to laravel? Wikipedia, WP, Facebook and countless other site/project have been build with PHP. so...like WTF?
HN is going down in quality with trash like this.
HN is going down in quality with trash like this.
> author picked Django but trash talk PHP. Apple to Apple. shouldn't you compare Django to laravel?
I understand that as exactly what was written. Plain old PHP is the old thing here. It could be a PHP vs Laravel comparison instead of PHP vs Django as well.
I understand that as exactly what was written. Plain old PHP is the old thing here. It could be a PHP vs Laravel comparison instead of PHP vs Django as well.
What are "Watcher Views"?
I think they mean the following. In Django, a view function, or view for short, is a Python function that takes a Web request and returns a Web response.
So a watcher view is probably a view that returns an extremely short response. It's just telling you whether more data is available, or not.
They mention websockets as an alternative that's far more complex.
So a watcher view is probably a view that returns an extremely short response. It's just telling you whether more data is available, or not.
They mention websockets as an alternative that's far more complex.
Yup exactly you've understand it all.
From the article:
"These are views that tell you when a model changed last. Watcher Views are light enough so that you can continuously call them to know whether you should fetch recent data. They're far less complex than WebSockets and avoid the performance costs of continuously polling unchanged data from the API."
"These are views that tell you when a model changed last. Watcher Views are light enough so that you can continuously call them to know whether you should fetch recent data. They're far less complex than WebSockets and avoid the performance costs of continuously polling unchanged data from the API."
Do you still have to poll a Watcher View - if it's an endpoint that tells you if the model is updated or not?
Yes you do, except that it's much faster for the backend to answer as it just hits a cache instead of doing a db query and serializing the whole model.
tsss(2)
More often than otherwise, I’ve found code duplication preferable over abstraction. I only abstract code when I understand the problem space really, really well (I.e. have solved it before), or when I can have some certainty the wrong abstraction won’t cost me too much time to fix.
It takes time to build the kind of self confidence and humility it takes to allow a code base to sprawl for a while until you've seen enough examples to have an idea where it's going.
The first thing I like to do is solve the problem, period. Without inventing anything, just simply write code to cover most cases. Then I'll start improving on it in small ways, cutting down on duplication and inventing abstractions; until I reach a tipping point where I can visualize a complete design, which results in a major refactoring.
It looks messy in comparison to so called best practices, but it's faster and the code that comes out of the process is clearly better.
DRY is hurting more than helping if you ask me; because it shames inexperienced developers into premature abstraction, causing plenty of pain and misery along the way.
The first thing I like to do is solve the problem, period. Without inventing anything, just simply write code to cover most cases. Then I'll start improving on it in small ways, cutting down on duplication and inventing abstractions; until I reach a tipping point where I can visualize a complete design, which results in a major refactoring.
It looks messy in comparison to so called best practices, but it's faster and the code that comes out of the process is clearly better.
DRY is hurting more than helping if you ask me; because it shames inexperienced developers into premature abstraction, causing plenty of pain and misery along the way.
This. 1000x this.
Agreed.
Also one can get over-eager with abstractions over things that are not real duplicates. They just happen to look similar at this moment in time.
In this category, I would also put premature automation before learning what it actually is you are automating among other things.
Or more generally: Don't try to be clever about something you don't (yet) understand.
Also one can get over-eager with abstractions over things that are not real duplicates. They just happen to look similar at this moment in time.
In this category, I would also put premature automation before learning what it actually is you are automating among other things.
Or more generally: Don't try to be clever about something you don't (yet) understand.
I once read a guideline (by DHH I think?) "One, Two, Refactor" as in write it once, then duplicate it, and the third time think about refactoring it to be DRY. But yes it's all about discerning what's reasonable given the circumstances, and not being dogmatic.
It does seem that this lesson takes at least a decade to internalize, and as such one can usually estimate the level of experience a person has based upon how much they embrace “DRY” as a hard rule vs a guidepost.
"duplication is cheaper than the wrong abstraction"
i think i read that in POODR by sandi metz
i think i read that in POODR by sandi metz
Her book with Katrina Owen “99 Bottles of OOP” lays out an even better case for this I think. Particularly useful is the introduced language to help measure the state of a codebase (“shamelessly green” vs “incomprehensibly concise” etc).
Also quite like Fowler’s observation in Refactoring that (to paraphrase) abstractions are earned, not enforced.
Also quite like Fowler’s observation in Refactoring that (to paraphrase) abstractions are earned, not enforced.
Wasn’t it Fred Brooks who said, “Plan to write it twice, you will anyway”?
I fell into the trap of premature abstraction yesterday: I spent an hour breaking down functionality to make it “easier” to implement different backends, only to realise that the “abstraction” was strongly coupled to the structure of the single backend I’d written.
Young me would have forged on regardless because “abstractions”. Old me threw it away.
I fell into the trap of premature abstraction yesterday: I spent an hour breaking down functionality to make it “easier” to implement different backends, only to realise that the “abstraction” was strongly coupled to the structure of the single backend I’d written.
Young me would have forged on regardless because “abstractions”. Old me threw it away.
I try to follow the Rule of Three
https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...
https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...
Some old tools are gold. It's good to know them. You can master regular expressions and they are applicable everywhere, from simple parsers to mass-editing the files. You can master UNIX shell and some tasks will be incredibly easy. You can master vi and you'll be able to edit remote files over terrible ssh connection.
Also, IMO, some old tools are not bad, even if they're out of fashion. I can write web application with Java Servlets and JSP like it's 2000 and it'll be fast and performant enough for many use-cases, not everyone have to use React. So if some tools are not that good, but you know them very well, may be it's worth to keep them around.
Also, IMO, some old tools are not bad, even if they're out of fashion. I can write web application with Java Servlets and JSP like it's 2000 and it'll be fast and performant enough for many use-cases, not everyone have to use React. So if some tools are not that good, but you know them very well, may be it's worth to keep them around.
"To serialize logic, we would just need to represent the AST in a lisp-like syntax". Why not use Hy (http://hylang.org) and keep your Django.
Why not, but is it portable to other programming language like Go?
"Use Popular Tools", "Old Doesn't Mean Gold" and "Use The Right Tool" are all kind of contradictory. "Cool" and "popular" are usually correlated. "Old" might correlate inversely with "cool" but directly with the ease of finding plugins, Stack Overflow issues and blog posts.
IMO, the criteria to use when evaluating a tool are 1) cost of building it yourself, 2) how well you know the tool, 3) how big the community is, and 4) how well the tool fits the job.
IMO, the criteria to use when evaluating a tool are 1) cost of building it yourself, 2) how well you know the tool, 3) how big the community is, and 4) how well the tool fits the job.
> "Use Popular Tools", "Old Doesn't Mean Gold" and "Use The Right Tool" are all kind of contradictory.
Yes, but that doesn't make them simultaneously good advice. The tension among these three is one of the trichotomies of technical leadership.
Yes, but that doesn't make them simultaneously good advice. The tension among these three is one of the trichotomies of technical leadership.
Exactly, it's a balance to find.
> Try to build a complex server-rendered web app with PHP because "It's more inclusive" or "it has better frontend performance". See you in 2030.
Like Facebook, WordPress and MediaWiki? Bashing PHP is a popular pastime, but front-end performance and inclusion are not to be scoffed at. Especially not if your target audience has a different standard of living than that of a major European city.
Personally, I'm much more worried about optimizing heavily third-party dependent front-end code to perform well on old laptops and cheap phones than I am with scaling up and load balancing a server-rendered site.
Like Facebook, WordPress and MediaWiki? Bashing PHP is a popular pastime, but front-end performance and inclusion are not to be scoffed at. Especially not if your target audience has a different standard of living than that of a major European city.
Personally, I'm much more worried about optimizing heavily third-party dependent front-end code to perform well on old laptops and cheap phones than I am with scaling up and load balancing a server-rendered site.
> Like Facebook, WordPress and MediaWiki?
Yes, exactly. Facebook, Wordpress, and even MediaWiki have had man-centuries put into them.
If you want a polished result in less time, you should consider a different approach than server-rendered PHP for everything.
Yes, exactly. Facebook, Wordpress, and even MediaWiki have had man-centuries put into them.
If you want a polished result in less time, you should consider a different approach than server-rendered PHP for everything.
Of course they've had lots of man-time poured into them: they've existed for a long time. But there were first versions of all of those, too, and first versions of tonnes of other complex server-rendered sites and apps.
Mocking inclusion and front-end performance is quite contradictory to "Use The Right Tool". There are several cases where server-side rendering has a place and there are several frameworks and approaches that help with the complexity, just like there are cases when client-side interactivity is a better choice and you can pick a framework that will help with performance and cross-browser issues - and complexity, which exists on the client side as well.
Mocking inclusion and front-end performance is quite contradictory to "Use The Right Tool". There are several cases where server-side rendering has a place and there are several frameworks and approaches that help with the complexity, just like there are cases when client-side interactivity is a better choice and you can pick a framework that will help with performance and cross-browser issues - and complexity, which exists on the client side as well.
Well yes, like all of them. It's just that building complex apps with a lot of interactions gets messy super quickly when you render everything on the server. It brings a lot of limitations that are hard to deal with.
yeah. he lost me with that.