Perhaps the right answer is to code know the basics but also have a handle on the popular frameworks too.
Yes more likely. In fact I would find informative to see the framework that you have built as an example of understanding web development.
To expand a bit I think learning the framework is easier once you have an understanding of the web platform's basic. For non web stuff I value more problem solving ability, general CS knowledge over specific technology knowledge. I usually don't set a language requirements in interviews and look more to someone being able to explain how the code they wrote works and why it's a better solution than say some inefficient brute force method. Which in my example when applied to web stuff would translate to why is implementing something this way in angular better than an alternative, what advantages did you gain from angular. Etc...
The code that uses it looks like this: https://github.com/serprex/openEtG/blob/master/views/MainMen...
The site looks like this: http://etg.dek.im
I recently worked on a site at my job where I was able to implement it with JS + C#/OWIN, all static html, only uses toastr/jquery. Was nice they let me break away from the illusion that the choice is only between WebForms or MVC
If you ask me to compare this to Angular, I'd have to say I've never used Angular so I don't know
But in my view, building your own framework first and then learning a standard equivalent gives you a much better understanding of the tech of the new framework which will pay dividends. For instance, I built my own PHP framework in 2001, and subsequently played around with Drupal/Django/other homegrown frameworks. When Rails dropped in 2004 I was immediately ready to jump on board because I had been through the same mental process as DHH had when he started building Basecamp in Ruby after having been frustrated by PHP. Whereas a lot of people complained about Rails' magic and lack of transparency, to me it was very easy to dive into the source code and understand the reasoning that led to its architecture.
Of course these things calcify over time, and you don't need to necessarily go very deep into every layer of the stack, but you have to at least be competent in a few layers or you'll be helpless the minute you hit a problem with a leaky abstraction. But in the case of JS, yes I think any time spent learning core JS is well-spent, and knowing only React/Angular is a real liability as a front-end engineer, especially because those frameworks are designed to solve heavy SPA problems which are only a tiny subset of the type of interactive web pages one might want to create.
Convention makes code readable and maintainable. A framework is essentially shared convention that you don't have to maintain. Making your own framework shows that you understand the value of convention.
A framework means that spaghetti code can only get so bad. A bad ad-hoc implementation of a web platform is an order of magnitude worse than bad code written on top of a popular web platform.
When I look at ugly React code, I know how to extract logic, where to push it, how to identify poorly-named concepts. When I look at ugly vanilla JS, I don't know what to make of anything.
Consult MDN (Mozilla developer network) and read their articles
I've never been able to fathom how anybody can do that without understanding the foundation that it's built on. At the bare minimum, how the heck do these people troubleshoot errors? If you have so much as a typo in your code, Angular is going to give you a completely cryptic jQuery error message.
It's also partially an artifact of JavaScript's lack of namespaces and scoping rules and prototypical inheritance because these make it easy to make a class of errors that are conceptually difficult to understand without holding a complex mental model in my head...and that's after standardization of browsers reduced the number of arbitrary rules that could cause bugs.
With some effort, the relevant jQuery methods that act as polyfills could be extracted.
However, a minified version of core jQuery is < 20Kb. A very low technical debt trade-off to support 99% of browsers.
Reasons to include inefficient code for compatibility reasons might include applications where maximum reach is valuable, or where the scale is so large that the "infinitesimal market share" percentage plays out into thousands of end users.
Did anyone get fired for that bit of programmer malpractice?
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
It would be cool to see the before (with AngularJS) & after (pure HTML) of this.
[1] I regularly nerdgasm at LibreOffice releases reading how many thousands LoC they removed from the code base.
ps: beside code golf, I think there should be a patch golf thing. Try the smallest changeset that fixes or add a feature.
[1] also, git surgically precise patch mindset helped too.
"Strive to optimize for less code, and the minimum level of abstraction."
That should be the appropriate level of abstraction. The appropriate level of abstraction being that which requires the least code to implement and least effort to reason about.
Nice example.