Live data from Hacker News

You probably don't need a JavaScript framework

slack-files.com

331–340 of 356 posts

Re: You probably don't need a JavaScript framework

#331
post #202

Earlier quoted context omitted.

> introduce frameworks without so much as "apparently it's quite good, so let's use it" And if they all want to use it - let them use it. The productivity gained by agreeing on a framework usually outweighs the performance loss over the "best" solution. Yes, my native JS implementation of a gallery app is much faster than the React version (reviewed by an experienced React-dev and judged "good") but if that project g…

>> The productivity gained by agreeing on a framework This is a false dichotomy. This only applies once the developers have real experience with the framework. Throwing a brand new framework at the devs without at least a month to play with it - play, not work! - is doomed to failure. Expecting first-time use of a framework on an actual project to go well is a horrible mistake. There is a lot to learn with any reason…

(I should point out that this isn't a direct counter-argument to the parent I replied to. Just a clarification on that single point. It doesn't apply to most of their comment.)

Re: You probably don't need a JavaScript framework

#332
post #202

Earlier quoted context omitted.

> introduce frameworks without so much as "apparently it's quite good, so let's use it" And if they all want to use it - let them use it. The productivity gained by agreeing on a framework usually outweighs the performance loss over the "best" solution. Yes, my native JS implementation of a gallery app is much faster than the React version (reviewed by an experienced React-dev and judged "good") but if that project g…

>> The productivity gained by agreeing on a framework This is a false dichotomy. This only applies once the developers have real experience with the framework. Throwing a brand new framework at the devs without at least a month to play with it - play, not work! - is doomed to failure. Expecting first-time use of a framework on an actual project to go well is a horrible mistake. There is a lot to learn with any reason…

You are quoting me but I am not sure you are responding to my comment.

>> if they all want to use it - let them use it

>> they use the framework they are most comfortable with.

> Then please don't expect devs to pick up a new framework on the spot with no time to self-train on it.

I never said I did.

Re: You probably don't need a JavaScript framework

#333
post #332

Earlier quoted context omitted.

>> The productivity gained by agreeing on a framework This is a false dichotomy. This only applies once the developers have real experience with the framework. Throwing a brand new framework at the devs without at least a month to play with it - play, not work! - is doomed to failure. Expecting first-time use of a framework on an actual project to go well is a horrible mistake. There is a lot to learn with any reason…

You are quoting me but I am not sure you are responding to my comment. >> if they all want to use it - let them use it >> they use the framework they are most comfortable with. > Then please don't expect devs to pick up a new framework on the spot with no time to self-train on it. I never said I did.

Haha. I thought of that and posted a sub-reply, according to timestamps, just 5 mins before you posted this. I read your whole comment, and just intended to clarify that the very act of choosing a framework does not necessarily mean increased productivity, if the devs don't know the framework in question. A tangent based solely off the quoted part, for something I've seen time and time again over the years (new framework, no time to learn it, rushed deadlines).

Re: You probably don't need a JavaScript framework

#334
post #282

A) 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 unmai…

I would go so far as to say that to a new programmer on the team, Type B and Type C programmers' code looks much the same.

I'm a type B. I've written entire systems from scratch that fit me like a glove. I could fix any problem in no time flat, and it was very stable.

But when it came time to have other people work on it, it didn't fit them like a glove. It barely made any sense to them at all. They eventually got up to speed, but they were never as productive in it as they would have been in a decent framework-based system.

I was actually quite happy when they decided to rewrite the whole thing... And then it turned out I left about a year later, so it was a good thing they did.

Re: You probably don't need a JavaScript framework

#335
post #43

I 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…

I agree. We can make subjective arguments over this or that framework all day. But objectively speaking 15,000 lines is likely to be more difficult to maintain than 2,000.

Re: You probably don't need a JavaScript framework

#336
post #276

Earlier quoted context omitted.

"At least in my experience at work I've seen tech leads or someone similar introduce frameworks without so much as "apparently it's quite good, so let's use it"." I completely agree. Web people quite often commit to frameworks based on their marketing copy and maybe one guy they read on the internet saying "seems pretty AWESOME after I've played with it for two days!" and a testimonial or two. Of course, I've seen de…

>you know, this may not really be just a "web" thing.... It isn't just a web thing, but it is way worse in the web world. How many of the cases you described were for web shops?

Zero, since I was deliberately describing things that weren't web in my list?

Re: You probably don't need a JavaScript framework

#337
post #68

Earlier quoted context omitted.

> When a framework which has a community is chosen, these boring things like docs/examples/references/blog posts get fixed over time. Not in my experience. I've seen frameworks come and go like that over the span of 15 years and teams rewriting for the new "hotness". So, one year they do Angular, then Angular 2 comes out, invalidating a lot of their code/experience, then they get to React, then they're told that they…

Release of a new framework doesn't render all existing code based on an older framework useless. Nobody mandates moving all existing Angular 1 codebases to Angular 2.

Mandate moving them, no.

But eventually they'll bit rot, and all the new features, and community support will move to 2 -- and you're stuck with the worst of both worlds: a framework with stuff you don't need AND with few left to maintain it.

Re: You probably don't need a JavaScript framework

#338
I came across this thread late, but the comments here have been quite fascinating to read. I think as developers we're always seeing patterns in our code and trying to figure out the best way to solve them and that's how many frameworks emerge. Before React's emergence I would occasionally come across UIs which were incredibly complex due to events firing left and right (and events firing in response to those events, etc) and in an attempt to reduce cognitive load I would try and re-structure the code with a uni-directional flow that would re-render the entire UI when any state changes with varying degrees of success (since applying this pattern on top of another framework is pretty fragile). So React was immediately appealing to me. And Flux and later redux was the evolution of that idea taken to another level.

As for the article itself I was a bit confused by it as from the clarifications at the bottom it makes the assumption that the reader is building a trivial application with minimal UI state. There are thousands of boring companies like mine not named Youtube or Facebook building complex web applications and it wasn't until I read the clarification at the bottom that I realized the whole article wasn't aimed at me.

Re: You probably don't need a JavaScript framework

#339
post #297
post #278

Earlier quoted context omitted.

Serious question: How else can you adopt a new technology, without investing significant amount of time? It would be nice to exhaustively explore a tech before using it, but that's often simply not feasible due to lack of resources.

There's a range of options between "I watched an hour video and saw a cool demo" and "I invested six months into prototyping and testing the tech before I chose it." I mean, that really ought to answer your question, but to be concrete: Never bet anything but maybe your startup on a tech that you can't find anybody else your size trying out. Try searching "$TECH sucks" and similar queries on the Internet. If you can'…

"Never bet anything but maybe your startup on a tech that you can't find anybody else your size trying out. Try searching "$TECH sucks" and similar queries on the Internet. If you can't find anything, that's not a sign the tech is too awesome to have flaws... it's a sign nobody's using it! "

That's great advice. It's what I do. Helps find the trouble spots before I run into them.

Re: You probably don't need a JavaScript framework

#340
post #336

Earlier quoted context omitted.

>you know, this may not really be just a "web" thing.... It isn't just a web thing, but it is way worse in the web world. How many of the cases you described were for web shops?

Zero, since I was deliberately describing things that weren't web in my list?

NoSQL databases aren't used by web companies? Linux distros aren't used by web companies? Programming languages aren't used by web companies?
Post reply on HN