Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You probably don't need a JavaScript framework

slack-files.com

Post reply on HN
Print view View original

251–260 of 356 posts

Re: You probably don't need a JavaScript framework

#251

Post by Michielvv »

Svenskunganka wrote: post #117

I apologize for not adressing your concerns with the post earlier, I've just added an update to the bottom of the post with some replies to some comments I've read. Please keep in mind that my intent is not to mock you or your framework of choice. My goal with this post is to try to inspire you to try building something with the native DOM and Web API and see for yourself. Some may enjoy it, others may not. And if yo…

Although I agree with the idea that Frameworks can easily make your life worse instead of better. Especially at the time the Framework moves forward to a version that is not at all compatible with what you are doing.

However, in your update you are suggesting to use Object.observe as a simple alternative to React. I looked it up and https://developer.mozilla.org/en/docs/Web/JavaScript/Referen... says it is deprecated and even removed in some browsers.

Using API's that are not widely supported and then not relying on a well supported framework to abstract them, seems to me an even worse maintenance nightmare than sticking with a Framework.

Re: You probably don't need a JavaScript framework

#252

Post by calsy »

maaaats wrote: post #230
calsy wrote: post #224

Earlier quoted context omitted.

'I'm really glad I don't have to work with people who think like this.' You're glad you don't work with people who weigh up the list of possible solutions based on the specific problem? You're glad you don't work with people who care about performance, size and redundant code? You want to work with people who don't think, who don't question implementation? Thats pretty dumb isn't it. If someone has an alternative sol…

You are building a straw man and then arguing with it.

No, im not. Those are the exact points laid out in the article. The author mentions both the performance, size and redundancy related to frameworks.

Gjolund, states that he is glad he does not work with people who think like this. He goes onto mention that projects that have limited complexity are not worth talking about, thus the only factor in considering a projects worth is its complexity.

Re: You probably don't need a JavaScript framework

#253

Post by calsy »

gjolund wrote: post #234
calsy wrote: post #224

Earlier quoted context omitted.

'I'm really glad I don't have to work with people who think like this.' You're glad you don't work with people who weigh up the list of possible solutions based on the specific problem? You're glad you don't work with people who care about performance, size and redundant code? You want to work with people who don't think, who don't question implementation? Thats pretty dumb isn't it. If someone has an alternative sol…

You are right, 10,000 hits a day is not worth talking about.

Really thats it?

Re: You probably don't need a JavaScript framework

#254

Post by renke1 »

philliphaydon wrote: post #248
edejong wrote: 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…

Hmmm I still use a framework. Riot.js because it's all I need. No jQuery, no other frameworks. Just riot.js. I feel like all I write is small little web components. I could do it without riot but this just makes things more consistent for me. For example I wanted the ability to report content on a page. So I created report.tag, 40 lines of html, 30 lines of Javascript. Done. Then a button which mounts the component w…

I wouldn't exactly call React giant framework. It's API is pretty small actually.

Re: You probably don't need a JavaScript framework

#255

Post by zxcvcxz »

tomc1985 wrote: post #97
gjolund wrote: post #63

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

>"the framework people"

As opposed to the unemployed people?

Re: You probably don't need a JavaScript framework

#256

Post by jasonwelk »

hellofunk wrote: post #250

>Virtual DOM is efficient and has good performance, but native DOM interaction is insanely fast and your users will not notice any difference. As soon as I saw this, I knew there were limits to this author's knowledge on the subject. React was a requirement for the low-latency UI we built for a major commercial app and without it (or a similar library) the user experience we shot for would have been impossible.

I agree, but it also possible to use these frameworks without much understanding of the DOM and I think anyone serious about web development should have a good inside grasp on how the DOM works before using a library.

Re: You probably don't need a JavaScript framework

#257

Post by mbrutsch »

jlg23 wrote: post #110
edejong wrote: 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…

I can relate to your experience but you, just as me, seem not to be a typical front-end developer - the "web-boys" (a term which probably got you the down-votes) on the other hand are. If one asks them why they do things the way they do them, they usually have a coherent answer and are happy to explain it. As someone else pointed out in this thread, a great advantage of established frameworks is that they provide a c…

> As someone else pointed out in this thread, a great advantage of established frameworks is that they provide a coding standard for a team.

So it's useful for young, inexperienced developers. Do you kids really not have in-house coding standards anymore, or do you rely on your toolsets to provide that for you?

Re: You probably don't need a JavaScript framework

#258

Post by __s »

openEtG doesn't even use jQuery, it's been alright. Only library it uses is pixijs, & a slimmed down version at that. Originally everything went through canvas/pixijs but over time only a few views aren't DOM

http://etg.dek.im for site

http://github.com/serprex/openEtG for source

It does a lot of dynamic content generation, which dom.js has proved sufficient for

Re: You probably don't need a JavaScript framework

#259

Post by statictype »

timr wrote: post #7
statictype wrote: post #6

React doesn't exist to handle the massive amounts of data that facebook has. React exists to make complex UIs easier to build and maintain. Being able to just write the code once to render a UI from some state and then just reloading the entire UI when the state changes is an incredible simplification of your code. That the author kind of misses this point makes me pay less attention to the rest of the post.

"That the author kind of misses this point makes me pay less attention to the rest of the post." Too bad. The author addressed everything you said. You just didn't read past the sentence you quoted. Nowhere does the piece imply that you should render every state change server-side. In fact, it goes on to show, with specific examples, of how you can get data-binding and partial-update behavior with web-native APIs. Th…

So, I actually did read the rest of the post. I just didn't look at it deeply.

I disagree that the author addressed everything I said. He mentioned two-way data binding using mutation observers. That's not the win you get with react. React isn't about 2-way data binding - its the opposite - unidirectional data flow - which massively simplifies the mental model of how your user interface works.

Re: You probably don't need a JavaScript framework

#260

Post by braythwayt »

morgante wrote: post #237
braythwayt wrote: post #141

Earlier quoted context omitted.

> If your code had been as easy to understand as you say it > is there would have been no need to re-write it. In theory, only difficult-to-understand and/or difficult-to-maintain code is rewritten. In practice, the definition for “difficult-to-understand” and “difficult-to-maintain” often boil down to whatever the team decides they are familiar with... Or want to be familiar with. I wouldn’t assume there’s any corre…

> In practice, the definition for “difficult-to-understand” and “difficult-to-maintain” often boil down to whatever the team decides they are familiar with... Or want to be familiar with. And that's perfectly valid. In fact, it's one of the best reasons to use a framework. If I hand-roll my application with a cobbled-together framework, I am the only one who understands how it works. Even if I'm a pretty great develo…

My point was solely that rewriting code--whether to a framework or for any other reason--is no reason to judge the original code as suspect.

Every team has their own reasons. You have yours, I have mine, but they’re the team’s reasons.

By the way...

  > If I hand-roll my application with a cobbled-together framework
That is an interesting claim, but I do not find it to be a universal experience. Sometimes people--including myself!--do cobble together ad hoc frameworks, and in the long run a popular framework is almost always a better choice.

But sometimes, people just write a single app that does just what it needs to do without a lot of abstraction and indirection. They are ruthless about YAGNI. And the result is very easy to understand, because the cognitive load of reasoning about an app that is just an app is no greater than the cognitive load of reasoning about an app sitting on top of a framework you have internalized.

The problem is when people build their own framework and then build an app on top of their own framework. Sadly, this is usually the case, as they fall in love with building infrastructure in the hopes that future features can be added with just one line of code or dropping one file in one place.

That kind of thing is quite properly the domain of a framework, and very, very few teams should be writing frameworks.

tl;dr Let’s not set imply a false dichotomy between writing your own framework and using an off-the-shelf framework.

Post reply on HN