Comment by austincheney | Hacker News Reader

Comment by austincheney | Hacker News Reader

Parent Full thread

I can not speak for other peoples' opinions. Here is the reason I would pitch it in one word: scale.

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.

Not sure what type of sites you're building on the web, but building nontrivial feature-rich web applications does not scale well with vanilla JS. Frameworks like React and Angular give you the power to manage state, respond to state updates with performant and predictable UI rerendering, and share components and logic in an opinionated way that buys engineering teams consistency and speed of development. Maybe the 10% of companies that aren't deterred by this opinion simply don't have websites that necessitate a "web application," but having an applicant say this would personally have me looking the other way 100% of the time.

> Maybe the 10% of companies that aren't deterred by this opinion simply don't have websites that necessitate a "web application,"

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.

Super mario is orders of magnitude simpler than most web applications. Almost the entire state is encoded in the current frame and there are only three instructions.

Change it to mario maker where you can create and upload levels and look at and play others levels directly in the browser and it is still easier to implement in vanilla JS than for example react. Honestly if these things are not enough to constitute a complex web app then I don't see how the demand for people able to write complex web apps can be that large, since almost nothing I use are complex in that case.

In turn, though, if your features are sufficiently close to being possible with a static HTML page, I fail to see the point of introducing a framework into that mix when you could just use static HTML (with maybe a sprinkling of JS when it's absolutely necessary, e.g. input validation more complex than what HTML offers).

> Not sure what type of sites you're building on the web, but building nontrivial feature-rich web applications does not scale well with vanilla JS. Frameworks like React and Angular give you the power to manage state,

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.

Do you write your own dom/data/event binding systems in vanilla javascript or simply not use that approach? Genuine question, I have written a ton of ground up code across multiple languages but couldn't imagine reinventing that particular wheel for what we do.

Yes. Reinventing the wheel in this case is far less work than it sounds. You aren't really reinventing anything. Here is my current project where everything is vanilla.

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

Reply on news.ycombinator.com