An application written with original logic directly to the requirements provided will be smaller, execute faster, and require less overhead to maintain than something written with a giant framework provided your developers know what they are doing. One of the biggest selling points to using a large framework is precisely because many developers don't know what they are doing and many businesses are not willing to invest the money in training and documentation.
There are also specific demands that require original code that a framework is not ideal for. One of the employers that contacted me from HN was wanting me to write and maintain a Jabber based chat client that runs the browser with high concurrency like a high volume IRC room. Performance was critical and so they didn't want to deal with the overhead of a large framework.
Also, large frameworks are generally there to supplement developers' insecurity with the DOM and general architecture in the browser. That doesn't solve for writing a Node.js application.
As for myself I do both client-side and Node.js work. I enjoy working with Node more because that space is less opinionated. Developers' have all kinds of irrational opinions that they are willing to bet their careers on when it comes to working in the browser. Compared to most of that foolishness I am a 10x developer, and its not because I'm great at writing software.
What is super frustrating though is talking through these concerns during a job interview and dazzling the interviewers virtually ensuring my selection for the position. This is super frustrating because it isn't my intent. I am not trying to impress anybody when I go down that risky path of laying all my cards on the table. I am trying to voice my concerns as directly as possible to ward off a future bad relationship. Then once I get hired and go to work on the team sure enough all my apprehensions that I attempted to illuminate during the interviews are present ensuring that everyday at work will be a slow death trying to sprint though an ocean of tar.
The further your features get from a static html page the less JS frameworks helps. For example you can pretty easily write super mario in vanilla JS using normal html elements for rendering, doing that in JS frameworks would not be very fun at all. However if all you want to do is display data from servers or let the user fill in forms then JS frameworks are pretty good.
I disagree. It's extraordinarily trivial. Managing state is as simple as changing the value in a settings object as the user interacts with a control on the page and then saving that object so that when the page is reloaded there is known restore point by which all controls are repopulated and in the condition from which they were left. In my current personal project I am synchronously sending the state object to a Node instance that writes it to a file so that state is restored cross-browser and cross-computer.
These are beginner things. The only reason why many developers even pretend they are vaguely more challenging than copy/paste is because they have never written this logic themselves.
I am tired of being stuck, at work, in perpetual beginner land with developers who are intimidated to write 3 lines of code without 3mb of framework to tell them how its done. It isn't because these other developers lack the intelligence or capabilities to write original code. It is because the social state of development encourages them not. Here are some reasons why:
Many developers college educated UI developers I have worked with prefer to toggle configurations instead of writing original logic, even trivial logic. This is what they were taught in school and this how they were prepared for the real world. This is bad design. Playing around with configurations wastes people time. A better approach is to simply supply a working default state for any conceivable configuration and a point of automation to supplying changes to options.
As I have mentioned several times already in just this comment most UI developers I have worked with are deathly afraid of writing original code. This isn't because they are incompetent or incapable. It is primarily due to social reinforcement where any locally crafted software is inherently untrusted compared to equivalent code written by a stranger from some untested external package. I have experience this myself when a colleague adamantly told me to use some software in preference to the current office approach from outside the company not realizing I wrote a good porting of the software he was recommending. This social state is so prolific it even has a name: https://en.wikipedia.org/wiki/Invented_here
Developers also go way out of their way to reinforce much of this irrationality by offering simple cliches in their defense. The most common are:
* Writing a web application is too hard to scale without some framework to do it for me
* Reinventing the wheel
* The DOM is too slow (implying that somehow a framework makes it faster)
There is no evidence behind any of those points, but there is plenty of evidence and examples to the contrary. Its irrational nonsense that people use to reinforce bad ideas shared by their peers. I am no longer interested in working along side that lack of evidence-based critical reasoning and fear of originality.
If this means dismissing many potential employment opportunities then so be it. I would rather find a rare better fit than desperately settling for something so unambitious.
* Code: https://github.com/prettydiff/share-file-systems
* Demo: http://mailmarkup.org/sharefile/demo1.mp4
The video demo is a few months old now, but in the current code I have broken network sharing during a refactor. The GUI and local file system still work well though.
Take a simple site like HN, there is no need to make maintenance many times more expensive by doing all of those things when a hundred lines of javascript will do the trick while still being simple enough that any programmer could read it and understand how it works.
I mean, by virtue of being a client-side Javascript developer, you're surely going to be working on client-side applications large enough to demand a client-side Javascript developer.
Frankly, avoiding jobs that use frameworks seems like you're choosing for nothing more than legacy spaghetti-code messes, not some sort of back-to-basics enlightenment. But I'm not here to judge what somewhat likes. :P
Maybe there's just something I don't get and clearly frontend developers somehow manage to make all of this work, but to an old-school backend guy like me the modern JS ecosystem seems horrifying, needlessly complicated, over-engineered and brittle.
https://news.ycombinator.com/item?id=20589013
I can see a lot of companies being willing to hire a person who can do that even if he doesn't want to use a specific UI framework. Just write down the javascript and you can integrate it in whatever codebase you have, so he is a lot easier to work with than your average JS dev.