
How to build apps pragmatically - belzebalex
https://alextoussaint.com/2020-02-01_How-To-Build-Apps.html
======
arexxbifs
> 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.

~~~
paulddraper
> 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.

~~~
arexxbifs
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.

------
SirensOfTitan
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.

~~~
codr7
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.

~~~
gpu_explorer
This. 1000x this.

------
vbezhenar
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.

------
jakelazaroff
"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.

~~~
afarrell
> "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.

------
viraptor
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)

------
AlchemistCamp
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?

~~~
axiosgunnar
> 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.

~~~
AlchemistCamp
Ah, ok. That's slightly less strange, but still very strange given the
productivity and ecosystem size of Laravel vs that of Django.

------
twic
What are "Watcher Views"?

~~~
cerberusss
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.

~~~
belzebalex
Yup exactly you've understand it all.

------
cutler
"To serialize logic, we would just need to represent the AST in a lisp-like
syntax". Why not use Hy ([http://hylang.org](http://hylang.org)) and keep your
Django.

~~~
belzebalex
Why not, but is it portable to other programming language like Go?

------
dotnetcore
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.

~~~
viraptor
> 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.

~~~
withinboredom
Since when is PHP older than Python?

~~~
viraptor
That's not what I wrote though.

