51–60 of 86 posts
Good article, I agree with learning architecture first. No one should start learning by using framework first. But don't forget about "loosely coupled" frameworks like PhalconPHP. It allows you to code your own without using pre-built one.
What does it exactly mean to learn architecture? And how is it relevant who is on working on backend or web services?
I'm going to admit, I didn't finish the article. So, I apologize if my point is useless. I've done plenty of web development before Angular/backbone etc. The productivity that I've experienced after becoming proficient in these frameworks more then makes up for any debugging issues. My other experience is that though sometimes it may take a tediously long time to figure something out, once you get it working... it ju…
Earlier quoted context omitted.
This is actually 100% my experience, wow. I started with Rails many years ago, had absolutely no idea what I was doing. Was just googling for gems and snippets from Stack Overflow, if anything ever broke I was done. A few years later I decided I was going to really dig deep into the meat of it and wrote my own framework in Clojure that we are still using to this day in production. It was incredibly liberating to know…
> I eventually realized that our super small team and I simply couldn't sustain keeping this super-custom framework maintained and updated, not with all the other work that needs to be done at the company. We moved most of our work to Haskell's Yesod framework, which has years of community work and incredible craftsmanship behind it. And then Haskell's Yesod gets abandoned when the core devs move to shinier things an…
The author is only partway through the learning process. There is a circular progression. The total newbie just "learns the framework" and is helpless to debug through leaking abstractions. I agree 100% that you don't want to be stuck there. So eventually she decides to just compose her own architecture. Now she understands all the pieces. But as she matures further as a programmer and architect, she starts to see al…
> It can't be, because all the people spending their time on bespoke solutions are solving the same problems over and over again separately, whereas the people working on shared solutions keep building off each other. Over the long-run it gives a massive quality advantage to the shared solutions. In theory, yes. In the real world, "the people working on shared solutions" get distracted too easily, follow latest BS fa…
If the answer is no, then using a framework was probably a mistake. However, for 99% of web applications, I don't think the answer to this question is a no.
I couldn't agree more with that.
The author is only partway through the learning process. There is a circular progression. The total newbie just "learns the framework" and is helpless to debug through leaking abstractions. I agree 100% that you don't want to be stuck there. So eventually she decides to just compose her own architecture. Now she understands all the pieces. But as she matures further as a programmer and architect, she starts to see al…
This is directly related to one's ability to spin off a library containing a generalizable component of functionality and have it be repeatedly reused. My belief is that this is actually far harder than it ought to be in most languages. Actually, worse than that, most languages and the style of their libraries as supported by the community cause tradeoffs which penalize reusability quite harshly.
* It's difficult to manage documentation of interfaces
* Abstractions leak *heavily* and therefore have
exponentially complex "spooky interaction at a distance"
* Breaking algorithms into chunks must be done at
boundaries defined by efficiencies instead of as
defined by meaning (implementation privileged over spec)
I'm not going to claim that Haskell has figured out modularity, but I do think it's massively better than the status quo here. The upshot is that Cabal Hell is in part caused by the fact that nobody quite knows how to handle such massive modularity in practice.
Where that's relevant, I think, to this post is that without a genuine case for reusable modularity—supported at the language and the community levels—it is much harder to invest your time into reusable things and instead you focus efforts on frameworks. Lacking the technology to have legos we choose between prefab houses.
I think the best way for Javascript, i.e., to move forward away from framework driven development is to double down on the community's investment in purity as neither types nor laziness are ever going to be core to the language. This has already occurred in a small way with things like the virtual dom technique (which can be easily made immutable and updated purely) and the rise of things like Mori and Immutable.js.
As this pattern grows I predict the ability for people to genuinely build applications from well-cut, reusable components will become far more of a reality and the "framework epoch" will slowly close.
I think patterns are stupid idea. You bother learning a way of doing things (the pattern ), and you bother all you colleagues learning that way of doing things. OK, cool, that sounds good. But you never bother to teach it the computer! The computer should understand the pattern as well, in form of some abstraction. Because now you force yourself and others to recognize pattern every time you need to use it (either re…
Richard P. Gabriel critiqued this notion of "patterns should be abstracted and instantiated" in his 1996 book Patterns of Software [1]. To summarize as briefly as possible: abstraction has costs, too. Sometimes it's better to spell out the pattern. As you probably know, the idea of patterns came from architecture, where "reusable abstraction" translates to "modular house" – which is not obviously better. [1]: https:/…
However, I think when you program the pattern you have already instantiated it, anyway. At least when you used it several times throughout your program. In those cases I think it's then better to explicitly abstract it away (i.e. tell the computer you are using the pattern).
The author is only partway through the learning process. There is a circular progression. The total newbie just "learns the framework" and is helpless to debug through leaking abstractions. I agree 100% that you don't want to be stuck there. So eventually she decides to just compose her own architecture. Now she understands all the pieces. But as she matures further as a programmer and architect, she starts to see al…
> It can't be, because all the people spending their time on bespoke solutions are solving the same problems over and over again separately, whereas the people working on shared solutions keep building off each other. Over the long-run it gives a massive quality advantage to the shared solutions. In theory, yes. In the real world, "the people working on shared solutions" get distracted too easily, follow latest BS fa…
Then you discover the framework designers consider your problem too far from their core target use cases and so show no interest in improving that area of the framework. The community question why on earth you were trying to solve that problem in the framework in the first place, and tell you that obviously you should have used a different framework from the start.
Frameworks all target different use cases; often simply the ones the designers happen to have faced over the years. Half the battle in choosing a framework seems to be finding out what those target uses cases actually are - most frameworks seem to think they are good at everything.
God forbid your app evolves and changes such that no framework fully supports all your uses any more...
(That's not to say frameworks are bad, I just think there's a bit too much religious fervour involved when discussing them.)