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

221–230 of 356 posts

Re: You probably don't need a JavaScript framework

#221

Post by jlg23 »

exodust wrote: post #206
jlg23 wrote: 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…

Good point. Team unity and shared understanding of the methods, I'm all for that. Personally I consider everything and don't rule anything out. I wouldn't rule out be-spoke is my main argument. It's just that, you know, life can be more rewarding if you not only aim for perfection or near-perfection, but achieve it. There's a philosophical angle here that may be more suited to the start-ups thinking and dreaming big…

> life can be more rewarding if you not only aim for perfection or near-perfection, but achieve it

I do that with my own software in my spare time, but from an economic point of view I cannot justify to spend that time when working for someone else. And since projects are always evolving also in requirements "perfection" is a moving target.

Re: You probably don't need a JavaScript framework

#222

Post by josephcooney »

exodust wrote: post #191
jlg23 wrote: post #110

Earlier quoted context omitted.

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…

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

Sounds like "Resume Driven Development" http://imgur.com/DQcks8ul

Re: You probably don't need a JavaScript framework

#223

Post by MortenK »

gjolund wrote: post #80
coldtea wrote: post #76

Earlier quoted context omitted.

> If your app isn't complex enough to merit using a framework, then you aren't really building something worth talking about. That's the very mentality that gave us J2EE crapfest and poisoned JS. The idea that a complex app requires a kitchen sink approach and framework-itis...

Complexity requires structure in order to be maintainable. Its not a "kitchen sink", its scaffolding. If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position. Both are signs of inexperience.

"Both are signs of inexperience."

Case of pot calling the kettle black methinks.

Re: You probably don't need a JavaScript framework

#224

Post by calsy »

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…

'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 solution and a sound argument to back them up, your response would be 'I don't like the way you think'.

But I guess projects are only worth talking about when they are incredibly complex. A simple website taking 10,000+ hits a day isn't worth squat unless you have a big JS framework under the hood. Complexity = value, not users, not the UX, not the support, not performance, but COMPLEXITY.

Re: You probably don't need a JavaScript framework

#225

Post by mhd »

It's interesting that by comparison, a lot of these modern JS frameworks are positively tiny. No comparison to e.g. Cocoa, QT, MFC, Rails, Spring and all the things usually called the f-word. React itself barely qualifies for "library", more like "helper functions".

So, having started outside the web world, I really don't understand the hullabaloo. It reminds me of a certain point in Windows development, when shareware etc. was a thing, but download speeds, RAM and disk space were still low. Creating smaller programs was a thing for some developers, both for distribution and an alleged "bare metal" feel (whether they were that much better than e.g. a big package including all of Tcl/Tk is another matter). Programming Win32 with assembly. The ATL. Compressed executables. People recomming a new weird command-line oriented operating system made by some crazy Finn.

Both ATL and Win32ASM bring in yet another feature: Programming in my favorite, possibly new idiom. Another reason for creating these mini-frameworks in the JS world. All glued together by slapdash micro-libs and utilities, that might be there one day, might be gone tomorrow.

I might finally be getting old and cranky, but I actually feel that some bigger frameworks wouldn't hurt. Some kind of standard library included, given that this won't come out of standards or the global community. More opinions. A set of standard components/widgets, not just three score methods of displaying them and two score of connecting them to a score of different backends.

Go all in: If you really want to just use the web browser as a delivery system for all kinds of GUIs, give me a GUI framework. I think that strangely enough ExtJS used to have more competition there...

Either that, or make more use out of the old-fashioned tenets of HTML, do more with text and links and stick to progressive enhancement. The middle ground of shiny but tiny GUIs that seems to be the rule for modern "SPAs" is neither fish nor flesh. (And I don't think that "isomorphic apps" is the answer here, either.)

Re: You probably don't need a JavaScript framework

#226

Post by ak39 »

dwg wrote: post #118
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…

Why was it rewritten, because it was difficult to maintain? It sounds like whomsoever rewrote it failed to make it more maintainable, then I would say that is a failure on the part of the person than on the concept of a framework.

Aren't frameworks supposed to prevent this type of thing exactly?

If there's no guarantee, how do we ensure that we don't create an even bigger nightmare code structure when using frameworks? This risk has to be understood before framework choices are made.

Re: You probably don't need a JavaScript framework

#227

Post by deathanatos »

BinaryIdiot wrote: post #139
gjolund wrote: post #92

Earlier quoted context omitted.

That seems incredibly anecdotal. Perhaps if you don't understand the framework you are using. Ember (for example), takes care of huge swathes of complexity for you. I can't imagine trying to build a: * client side router * data transportation/cache layer * view layer * model layer * build pipeline ... and more, in less code that just `npm install -g ember-cli` `ember new my-app` And then having a common app structure…

> I can't imagine trying to build a: * client side router * data transportation/cache layer * view layer * model layer * build pipeline Why can't you? Routers are easy ; you likely don't need more than a few lines of code to accomplish most of what you need. Caching and data transportation is also easy and simple (there are a million cache libraries if you don't want to write a small one). Views and models have been…

> Routers are easy; you likely don't need more than a few lines of code to accomplish most of what you need.

Router as in delegating a URL to a handler for that URL? I wrote one once … and it is deceptive and not easy; most of the server side ones that I've encountered (e.g., Django, Flask, nginx) do a poor job.¹

The naive implementation of a mapping of regexes to handlers is dead simple to implement, but not very ergonomic to really use. Something that understands that paths are hierarchies works a lot better. Then it's also nice to have something that can stub out a component to a variable (and preferably type check that), e.g., "/customers/:customer_id", and pass you "customer_id" after validating it to be an integer, a UUID, or whatever. Then you need the capability to delegate an entire subtrees to a subrouter, and maybe if we could just get some handling of delegation based on the method in here, but HEAD needs to be automatic…, and canonicalization of URLs would be nice too.

¹I feel like this is one of those things that until you've seen something better, you're still wanting the faster horse.

Re: You probably don't need a JavaScript framework

#228

Post by zeemonkee3 »

jlg23 wrote: post #217
fsloth wrote: post #208

Earlier quoted context omitted.

" I'd expect these devs to implement a feature quickly " Isn't that basic sin of software development - weighing speed of implementation (which is just a tiny part of the lifetime cost of software) over anything else. I'm not arguing against 'good enough', I just don't think this is a particularly strong argument for that. It's like surgeon not washing his hands and sterilizing his equipment because that way implemen…

"lifetime cost of software" means what? 99% of the software we write is obsolete within 2 years. We should not confuse big enterprise, long term support software with modern web development. IMHO, if you want to invest into software viable on the long term, rather spend your time writing functional tests and good documentation so the current implementation can easily be replaced with a new one that uses the then hip…

> "lifetime cost of software" means what? 99% of the software we write is obsolete within 2 years

More like, developers change jobs that often. So it's no longer your problem.

Re: You probably don't need a JavaScript framework

#229

Post by etatoby »

The article's author does not seem to understand what React is for and why people use it.

The article is full of sentences like: it's true React is fast, but basic Javascript is even faster. Duh? It's true React is quite small, but if you don't use it, your site will be even smaller. No sh*t Sherlock?

React was invented to simplify the program structure of medium-to-large applications by replicating the successful data flow of the Web itself: namely, the state of the application is in one place only (the URL in the Web, the state object in React); HTML is generated from that state using one set of reusable and composable templates; and crucially, user events only affect the state, not the HTML itself.

Personally, I'm going back to basic HTML + progressive enhancement, for a variety of reasons. But React is the sanest of all the client-side architectures I've seen so far, including bare-bones web api.

Re: You probably don't need a JavaScript framework

#230

Post by maaaats »

calsy wrote: post #224
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…

'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.
Post reply on HN