Earlier quoted context omitted.
This site is also extremely simple and only requires 6 lines of js. HN is not a complex app.
Right. So then make your site as simple as this.
You're completely ignoring possible business requirements.
You probably don't need a JavaScript framework
281–290 of 356 posts
Re: You probably don't need a JavaScript framework
#282A) There are people that love frameworks.
B) There are the ones that don't.
The type A ones just gave up to the complexity and bury it with foreign frameworks.
The latter ones invent their own ecosystem. And are very productive with it. It's fast and beautiful. And you know every screw and bolt. There is a feature request? No problem, you know immediately how to solve it. I know many of them. And nearly all of them are the best I have ever known.
But here is the big "but". Would programmer type B want to work with a 2 year old project from another type B programmer? And there you have your answer why there is such a hugh appretiation for frameworks. Its easier to throw 10 programmers of type A onto the same project.
Re: You probably don't need a JavaScript framework
#283I still remember doing a PoC for an end-to-end secure messaging app with web support, around 3 years back. It was written in plain JS with jquery and one or two libs for crypto bolted on. Simple, easy, but not very maintenance friendly written. Took around 2000 lines all in all. One of four clients (Android, iOS and a bot framework in Scala/Java). Then the web-boys came in to rewrite my... well, contraption. In came…
> The web-boys however, didn't understand asynchronous messaging, cryptography and eventual consistency very well
Would it be fair to say you didn't understand the web frameworks very well?
I'm not sure that lines of code is a great measure here. What about test coverage? Maintainability? NPM is a package manager - anyone would advocate using that over manual dependency management, no matter what environment you're programming in.
It sounds like you had an expansion of the web team. It only makes sense that you'd standardise things when that happens. It just happens they weren't standards you are familiar with.
There's a perception among "server boys" (or are you "server men" looking over the "web boys"?) that the web doesn't deserve 15,000 lines of code. It's a lot more complex than you give it credit for - or would you be happy to write all your backend code in C and C only?
Re: You probably don't need a JavaScript framework
#284I think the flame war that has erupted has a pretty simple explanation: some people forget the state of javascript just a few years ago. I am currently in the process of moving my team away from the monolithic dojo framework towards using more of the vanilla web standards, but I think dojo was a great choice at the time. The pains of cross-browser support, terrible vanilla APIs that were completely different in IE8 vs the rest of the web, etc. made frameworks "the way to go" in the past, and that's set us off in the direction we are going today of immediately reaching for one. Articles like this one are great in that they are helping to educate people on the power and ease of use that the modern web has to offer, but I can 100% see why people are going to skeptical for a while longer when it comes to using only vanilla javascript.
Re: You probably don't need a JavaScript framework
#285I'm really glad I don't have to work with people who think like this. You don't NEED a framework, just like you could theoretically build a car from scratch. If your app isn't complex enough to merit using a framework, then you aren't really building something worth talking about. Frameworks do exactly what they say, provide a common framework for your team to work off of while they build a complex application. I fee…
How funny, then, that the framework people can't seem to standardize over anything more than jquery or react? If layers upon layers of frameworks really were the best approach for complex applications then why can't people get behind one clear winner? Why does there seem to be a new framework popping up all that damn time? How much money has been lost simply keeping up with the artificially hastened pace of change? N…
> Why does there seem to be a new framework popping up all that damn time?
I would think those who don't like frameworks end up building one for themselves and decide to share the correct way of doing things without all the clutter found in other contenders.
Re: You probably don't need a JavaScript framework
#286So instead of using an established framework the post is suggesting possibly using these things?
MutationObserver for UI updates + Fetch API for networking + History API and a custom router for routing + CSS for animations + HTTP/2 instead of Webpack + npm for building + JSPM for package management + multiple polyfills for browser support for all this
Besides not having a name and a dedicated site, how is the above any different from using a framework? Once you've worked out how to get all these things to play nice together, are you really saving any time from just using an established framework that's done the work for you in the first place (i.e. they'll use some of this stuff under the hood already)?
Just because you're leaning on native features instead of library features doesn't make it any different from using a framework. At least with an existing framework you know it's battle tested, has good documentation, has an active community and is easier to maintain for new programmers on the team.
Re: You probably don't need a JavaScript framework
#287A) There are people that love frameworks. B) There are the ones that don't. The type A ones just gave up to the complexity and bury it with foreign frameworks. The latter ones invent their own ecosystem. And are very productive with it. It's fast and beautiful. And you know every screw and bolt. There is a feature request? No problem, you know immediately how to solve it. I know many of them. And nearly all of them a…
> The latter ones invent their own ecosystem. And are very productive with it. It's fast and beautiful. And you know every screw and bolt. There is a feature request? No problem, you know immediately how to solve it. I know many of them. And nearly all of them are the best I have ever known.
You're forgetting type C that don't know anything about existing frameworks so decide to reinvent the wheel by writing an unmaintainable mess of spaghetti code... I'm guessing type Bs are very rare. Once you've seen enough untestable jQuery soup you'll learn to appreciate frameworks.
Re: You probably don't need a JavaScript framework
#288To begin, React isn't a framework. It’s a tool. Would you compare a table saw to a workshop? That doesn’t make sense and neither does comparing React to a framework—especially if you’re saying you don’t need one. Furthermore, using a virtual DOM is not the purpose of React. Virtual DOM is merely a part of how React works. People don't buy cars to get an engine. They buy cars to get around places. People don't use Rea…
> To begin, React isn't a framework. The way I look at it: - If you use a library that augments your style of work but doesn't change it then it's a library. Maybe a tool. - If you use a library that replaces or changes your style of work then it is a framework. React is a framework in my opinion. It can be used as a library but it's almost never used that way; most people incorporate JSX and much of the virtual dom…
> If you use a library that augments your style of work but doesn't change it then it's a library. Maybe a tool.
> If you use a library that replaces or changes your style of work then it is a framework.
I don't think that one's style of doing things have any merit in classifying what 200 people at Facebook had built. (Perhaps someone likes two-way binding. Backbone would be a library/tool and any Virtual DOM implementation would be a framework?)
Re: You probably don't need a JavaScript framework
#289I still remember doing a PoC for an end-to-end secure messaging app with web support, around 3 years back. It was written in plain JS with jquery and one or two libs for crypto bolted on. Simple, easy, but not very maintenance friendly written. Took around 2000 lines all in all. One of four clients (Android, iOS and a bot framework in Scala/Java). Then the web-boys came in to rewrite my... well, contraption. In came…
> Took around 2000 lines all in all....The line-count went up, of course, easily to 15000 lines.
Inexperienced programmers can make bad decisions in any setting so I don't think this has anything to do with frameworks. I would be heavily against any decision that bloats a codebase 7 times its original size unless the pros heavily outweighed the cons.
People tend to associate poor coding mostly with spaghetti code and copy/paste everywhere, but poor coding also includes adding useless tests and abstracting too much.
Re: You probably don't need a JavaScript framework
#290You don't need one, but if you don't eventually adopt one, you'll end up writing one.
Sure, you may well end up writing one, but it's likely to be a fraction of the size. My current entire app is running at half the size of jquery, which is getting me awesomely quick page loads even on poor mobile connections. The dev time was longer, but not crazily longer, and the surface area for testing is somewhat smaller
I'm not sure how the size of your app can possibly say anything about applicability or quality of jQuery.