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

341–350 of 356 posts

Re: You probably don't need a JavaScript framework

#341

Post by devishard »

jlg23 wrote: post #202
exodust wrote: post #191

Earlier quoted context omitted.

> "They did invest lots of time to learn about all those tools and libraries" Unfortunately that claim doesn't hold up to what I suspect is happening most of the time. 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". One case in particular, Angular was chosen and turned out not to be suitable - it ran very…

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

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

I totally disagree, and not because of performance; choosing a framework based on its performance would be premature optimization. Your argument breaks down here:

> I'll be damned if I make them learn my way of doing things. I'd expect these devs to implement a feature quickly

But that's exactly what a lot of projects using a framework end up doing. Between Ember, Angular, React, Backbone, Dojo, Prototype, and GWT, there is a ton of competition in this space, and you would have a hard time finding a team of professionals who all know the same framework. So at least some of your team will be learning the framework, and that learning will not pay off compared to just using vanilla JS. You can't argue that familiarity outweighs the complication added by a framework because people aren't familiar with the same frameworks.

Vanilla JavaScript is the lowest common denominator: almost everyone is familiar with it.

Re: You probably don't need a JavaScript framework

#342

Post by jerf »

MustardTiger wrote: post #340
jerf wrote: post #336

Earlier quoted context omitted.

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?

Pretty sure all those things are used by non-web people too.

If you're going to apply that standard, since to a first approximation everything is hooked up to the web, everything is web. In that case, it does no good to claim that "web people" are particularly prone to anything when "web people" are to a first approximation everybody.

Re: You probably don't need a JavaScript framework

#343

Post by ChrisDutrow »

bikamonki wrote: post #129

This eternal argument of js framework/non-framework reminds me of them old days of static html when Dreamweaver will just munch a PSD file and spit out working HTML + Images + CSS. Some of us hated it b/c the output was bloated, super hard to read/maintain, etc. So, some of us just went ahead and coded from scratch. I guess the preference has to do with a need to 'understand' what's going on. Tools like React or fram…

I feel this way about backbone as well. Before using backbone, I wrote complex user interfaces in Javascript/JQuery. They were a mess.

Backbone allowed me to write cleaner code without forcing me to do anything. I still use backbone today. The code tends to be very verbose, but the trade-off is that it is not heavy handed. I never have to "hack" around backbone, it just gets out of my way when I want it to.

This fits my personal preferences, I prefer simple, verbose code. I also tend to prefer lower-level to high level. For example, I don't like ORMs. For me, it is easier to explicitly express how I want the data to be indexed and move in and out of a database as opposed to have an ORM manage it for me... because if it doesn't do it right, its very difficult for me to learn how to get the ORM to do what I want it to do. I also prefer more keystrokes and fewer "things to have to know about" to fewer keystrokes with many things going on behind the scenes that I cannot see. I think I may be in the minority in this respect?

I understand that there may be better frameworks now, but I feel I need to commit to something and stick with it, I think the cost of re-writing things all the time is too high. I think its faster in the long run to use an old framework that's 50% slower than switch to a better framework every two years.

For reference, this is the main project I use backbone on: https://demo.enterprisejazz.com/

Re: You probably don't need a JavaScript framework

#344

Post by bikamonki »

ChrisDutrow wrote: post #343
bikamonki wrote: post #129

This eternal argument of js framework/non-framework reminds me of them old days of static html when Dreamweaver will just munch a PSD file and spit out working HTML + Images + CSS. Some of us hated it b/c the output was bloated, super hard to read/maintain, etc. So, some of us just went ahead and coded from scratch. I guess the preference has to do with a need to 'understand' what's going on. Tools like React or fram…

I feel this way about backbone as well. Before using backbone, I wrote complex user interfaces in Javascript/JQuery. They were a mess. Backbone allowed me to write cleaner code without forcing me to do anything. I still use backbone today. The code tends to be very verbose, but the trade-off is that it is not heavy handed. I never have to "hack" around backbone, it just gets out of my way when I want it to. This fits…

>I think the cost of re-writing things all the time is too high.

Exactly. So, unless it stops running on modern browsers, the code should continue to execute and provide a complete solution. Although, I do try to keep Backbone versions up to date.

I also plan to continue using Backbone but I do want to learn a 'view' tool to improve performance of UI-rich apps. React seems too big and complicated, I am more inclined towards vue.js or mithril.js.

I checked your demo, in case you have not done so already here are 3 tweaks I've done to make Backbone run faster: - Select el already on DOM for a view's el instead of render/append. This is a huge performance improvement. - For big collections use plain JS array instead of Backbone native collection. You'll trade some methods for performance, but such methods can be re-implemented with Underscore. - Ditch the router if you need dynamic routes.

Here's an experiment of a classic listings app. After selecting a city, 5000 random listings are loaded at once into a JS array, after that I use Underscore for search/sort. Records in this example come from a static demo file. A red warning pops up with total download time and total processing time (lapse from download ready to array populated and ready for use). When I used Backbone collection processing time would be between 5-9 seconds (depends on processor speed).

http://edwardspooner.com/items/index.html

Re: You probably don't need a JavaScript framework

#345

Post by ChrisDutrow »

bikamonki wrote: post #344
ChrisDutrow wrote: post #343

Earlier quoted context omitted.

I feel this way about backbone as well. Before using backbone, I wrote complex user interfaces in Javascript/JQuery. They were a mess. Backbone allowed me to write cleaner code without forcing me to do anything. I still use backbone today. The code tends to be very verbose, but the trade-off is that it is not heavy handed. I never have to "hack" around backbone, it just gets out of my way when I want it to. This fits…

>I think the cost of re-writing things all the time is too high. Exactly. So, unless it stops running on modern browsers, the code should continue to execute and provide a complete solution. Although, I do try to keep Backbone versions up to date. I also plan to continue using Backbone but I do want to learn a 'view' tool to improve performance of UI-rich apps. React seems too big and complicated, I am more inclined…

I actually do use an el already in the DOM. To be honest, I do it that way because the code looks cleaner and is easier for me to understand that way, I didn't know it was faster. The only caveat I've found with that way is that if you remove a view and add an identical one, the events from the old view still get fired. For views where that happens, I actually use a custom extension of the original views that has a special destroy method that gets called which unbinds events and stuff.

When first learning backbone, I played around with the router, but I don't use it at all now. It was pretty hard for me to use and didn't seem to have much of a point. I suspect for many use cases, if you really need the url path to change, reloading the page from the server would be fine. But of course my perspective comes from only the use cases that I've worked with.

I actually mostly don't use backbone to organize the data, mostly only to display the data. The demo you looked at actually has little mini database implemented in the background using arrays and objects (used as maps). I mostly use collections for things that go right on the screen. I also (mostly) don't use backbone's ability to sync data with the server. I have a module that uses Jquery's Ajax for this instead. The reason I don't use backbone for this is that I found their way of doing it breaks down with more complex relationships within the data.

I mainly use backbone as a utility for message passing (update a model and one place, and messages are passed so everywhere else it is displayed updates also). And for organization: the views, pieces of the DOM within a view, and events.

Also, I use Marionette.js, not pure Backbone.js

...I'm not trying to say my way of doing things is the right way, just relating what I do and why for discussions sake.

Oh, and I looked at your demo. That is really cool. That's really fast for so many records.

Re: You probably don't need a JavaScript framework

#346

Post by MustardTiger »

jerf wrote: post #342
MustardTiger wrote: post #340

Earlier quoted context omitted.

NoSQL databases aren't used by web companies? Linux distros aren't used by web companies? Programming languages aren't used by web companies?

Pretty sure all those things are used by non-web people too. If you're going to apply that standard, since to a first approximation everything is hooked up to the web, everything is web. In that case, it does no good to claim that "web people" are particularly prone to anything when "web people" are to a first approximation everybody.

I am aware they are used by non-web people. That is why I asked if these incidents were web companies or not. I am not applying any standard, I asked you a simple question and you responded with a bizarre claim that they were explicitly not web.

Re: You probably don't need a JavaScript framework

#347

Post by jerf »

MustardTiger wrote: post #346
jerf wrote: post #342

Earlier quoted context omitted.

Pretty sure all those things are used by non-web people too. If you're going to apply that standard, since to a first approximation everything is hooked up to the web, everything is web. In that case, it does no good to claim that "web people" are particularly prone to anything when "web people" are to a first approximation everybody.

I am aware they are used by non-web people. That is why I asked if these incidents were web companies or not. I am not applying any standard, I asked you a simple question and you responded with a bizarre claim that they were explicitly not web.

Oh, well, then I hate to disappoint you, but no, these were not primarily web apps.

Re: You probably don't need a JavaScript framework

#348

Post by sbarre »

mbrutsch wrote: post #325
sbarre wrote: post #313

Earlier quoted context omitted.

I actually upvoted you, for the record. But you drew a distinction between "in-house standards" and "the framework's standards" (which are by definition probably taken from widely adopted standards). If you were implying that those two things might be identical then you did a bad job of conveying that (and then why even comment?)

> I actually upvoted you, for the record. That's why I said "you and my downvoters", rather than "you and my other downvoters". I am apparently very bad at making simple points. > But you drew a distinction between "in-house standards" and "the framework's standards" One is used in-house for all things relevant, one applies to a framework. In that, they are distinct. > (which are by definition probably taken from wid…

It's always possible to craft an anecdotal argument to disprove a generalized statement. We were obviously dealing in apples and oranges here..

I was making a generalized statement that likely applies to a large number of places (but indeed not all places), and you were providing a specific but not really comparable counter-point in return.

So yes, we were both right, but then again I ask "why reply?" if you're not replying in a similar context.

That's like me saying "the oceans are vast and dangerous" and you saying "but a pond is relatively safe"... You're technically correct, but what does it have to do with my initial statement?

Re: You probably don't need a JavaScript framework

#349

Post by MustardTiger »

jerf wrote: post #347
MustardTiger wrote: post #346

Earlier quoted context omitted.

I am aware they are used by non-web people. That is why I asked if these incidents were web companies or not. I am not applying any standard, I asked you a simple question and you responded with a bizarre claim that they were explicitly not web.

Oh, well, then I hate to disappoint you, but no, these were not primarily web apps.

Why would that disappoint me? I asked a simple question. Now you're still not giving me a straight answer, which makes me think you're being dishonest and trying to hide the fact that they were web shops. It doesn't matter if the choice was "primarily" for a web app or not if the choice is being made by web people. People who as a rule abhor learning and value fads.

Re: You probably don't need a JavaScript framework

#350

Post by kafkaesq »

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…

If your app isn't complex enough to merit using a framework, then you aren't really building something worth talking about.

Like HN, Craigslist, Reddit, DuckDuckGo, Wikipedia?

From what I understand, each of these sites was famously minimalist in terms of front end architecture as such, in their early stages at least. And still are, comparatively speaking.

You don't NEED a framework, just like you could theoretically build a car from scratch.

Very often you don't need a "car" to launch a business or start a community. Sometimes what you need is more akin to a bicycle. Or a walking stick.

I'm really glad I don't have to work with people who think like this.

I greatly prefer working with people who challenge conventional wisdom (and my own unthinking assumptions and tunnel vision about things), actually.

Post reply on HN