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

261–270 of 356 posts

Re: You probably don't need a JavaScript framework

#261

Post by statictype »

timr wrote: post #60
thatswrong0 wrote: post #21

Earlier quoted context omitted.

If you're going to tell me I don't need to use a library, it has to be way more convincing than, "Look how easy data binding it with native APIs! And it's not slow!" This is a weak argument in my opinion, and does nothing to address how removing abstractions will make my life easier.

That's a perfectly fair counterargument to the content of the piece, but the comment to which I replied had no such content. The post didn't miss the point that "being able to just write the code once to render a UI from some state...is an incredible simplification of your code." It argued that you can do that without using React.

It argued that you can do that without using React.

I actually didn't see that argument being made - two way data bindings are not the same thing.

To achieve React's simplicity you either need to

a) Simply tear down the entire DOM and rebuild it - works for small UIs and I've actually used this myself before react existed

b) Implement something similar to the Virtual DOM that react has for any non-trivial UI that is too slow to rebuild on every user interaction.

Re: You probably don't need a JavaScript framework

#262

Post by ak39 »

veidelis wrote: post #233
ak39 wrote: post #219

Earlier quoted context omitted.

What's the difference between platforms, frameworks and libraries? Here's my attempt ... jQuery: library. (Others: D3, knockout). Salient feature: does not impose code structure or organization of code modules. Angular and React: frameworks. Salient feature: expects adherence to module separation and code structure protocol. Like other MVC frameworks. EJB: platform. Salient feature: provides entire terra firma and at…

I find this answer helpful - http://stackoverflow.com/questions/148747/what-is-the-differ...

Thanks.

It's true that the word framework is buzzwordy. If you look at the general interpretation or the most common usage of that term, you'll see that it does refer to some type of "boundary setting" type of thinking. To work within the confines of a frame.

So, IMO frameworks necessarily impose parameters within which to maneavure.

Re: You probably don't need a JavaScript framework

#263

Post by [deleted] »

veidelis wrote: post #233
ak39 wrote: post #219

Earlier quoted context omitted.

What's the difference between platforms, frameworks and libraries? Here's my attempt ... jQuery: library. (Others: D3, knockout). Salient feature: does not impose code structure or organization of code modules. Angular and React: frameworks. Salient feature: expects adherence to module separation and code structure protocol. Like other MVC frameworks. EJB: platform. Salient feature: provides entire terra firma and at…

I find this answer helpful - http://stackoverflow.com/questions/148747/what-is-the-differ...

[deleted]

Re: You probably don't need a JavaScript framework

#264

Post by moron4hire »

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.

React Virtual DOM is faster than rebuilding the entire DOM from scratch, yes. But making edits to DOM manually will be faster with native browser functions and no VDOM diffing overhead.

Re: You probably don't need a JavaScript framework

#265

Post by ak39 »

mcintyre1994 wrote: post #244
ak39 wrote: post #219

Earlier quoted context omitted.

What's the difference between platforms, frameworks and libraries? Here's my attempt ... jQuery: library. (Others: D3, knockout). Salient feature: does not impose code structure or organization of code modules. Angular and React: frameworks. Salient feature: expects adherence to module separation and code structure protocol. Like other MVC frameworks. EJB: platform. Salient feature: provides entire terra firma and at…

Useful comment. EJB=Enterprise Java Beans right? Assuming that is the case, your other two examples were Javascript - is there anything in js that looks like EJB?

Yip. EJB is Java's version of another total waste of developer time introduced by Microsoft (MTS/COM+). These are larger constructs than mere libraries or frameworks. I call them platforms. You have to obey their large gravitational force fields. Failure to do that will result in catastrophe.

Edit:

I'd say the browser is the platform in the JS world. But analogies don't necessarily fold neatly.

Re: You probably don't need a JavaScript framework

#266

Post by sgmarks »

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…

As an end user, I don't see that the framework craze has any positive impact. Many websites that were highly usable around 2004 have degraded into a bloated mess.

Amazon is an example, but there are many others.

Re: You probably don't need a JavaScript framework

#267

Post by mattmanser »

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…

They're not a standard though. Everything's only a year old and gets replaced next year.

Where's Backbone gone? Or Knockout? Or Handlebars? Is it NPM, Bower or a mix of the two? Or etc. etc. Are you writing coffeescript still, why not typescript? Did you make an app in Durandal? Haha! Time for Aurelia!

Angular 1, one of the longer lived projects, is literally just being turned into a non-standard after a whole lifetime of about that of the family hamster.

So they're not standards, they're all today's hotness that won't be used on tomorrows projects.

It takes a couple of years for coding standards in new languages and libraries to even evolve, no-one knows how to use it properly to begin with and everyone makes a mess in a different way as they deal with the quirks and build non-trivial projects, but eventually a consensus is born.

In JS frameworks, just as that is happening, the whole thing is abandoned rapidly for the new hotness.

Re: You probably don't need a JavaScript framework

#268

Post by sbarre »

mbrutsch wrote: post #257
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…

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

A counter-point to your argument: In-house coding standards smells a little bit of NIH syndrome.

Odds are good that even if you are not a "young, inexperienced" developer, widely-adopted coding standards (that most frameworks probably use) have had more thought and reasoning put into them than you would ever be able to do on your own.

So I agree with your overall point of "don't just blindly adopt something", but the case can be also made for not naively doing everything your own personal way (including at the team/company level).

For example, "go fmt" exists for a reason.

Re: You probably don't need a JavaScript framework

#269

Post by ssmoot »

morgante wrote: post #238
tomc1985 wrote: post #138

Earlier quoted context omitted.

How does a LAMP/RAILS app share server side rendering code with the client? It doesn't, because I don't need/want it to. Any data that needs to be passed to the client is rendered as JSON. Client-side get committed to the database via AJAX (to my buzzword-o-rific REST api), or with good-ol' POST. How does a LAMP/RAILS app share data models between the server and client? Again, not needed. How does a LAMP/RAILS app pr…

We didn't collectively decide to move rendering to the client side for no reason. It is unquestionably more complex to build a SPA than to have a traditional web app. We did it because users demand it. A SPA feels substantially faster and more reactive. Users notice. If Gmail used your approach, it never would have succeeded. > How does a LAMP/RAILS app provide search engines with indexable dynamic pages? Uh, through…

Most SPAs feel substantially slower IME.

The users didn't demand this. They were perfectly happy when you delivered a website that performed a full-round trip in 50ms a decade ago containing more data than your average SPA can handle before choking on it.

The users want it to work. They want it to be fast. They want it to be pretty. That's about it.

I'm tired of hearing about why GMail succeeded. It's revisionist. GMail succeeded because they had the best spam filtering, in a simple design, and you were probably using Google search anyways. Plus Hotmail was always going down for hours (days?) at a time.

I've never experienced bugs in the web like I have with SPAs. I'm very thankful that even if my budgeting software is built in Ember, making it slow and buggy, my bank's site isn't. Making it predictable, and very fast to render. Time to Render is atrocious on many "modern" sites.

Re: You probably don't need a JavaScript framework

#270

Post by falcolas »

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…

Given the cost of abandonment and lost sales due to slow page rendering (there's a lot that's been written about that), even a 3% loss of conversions due to slow frontend code over 2 years is a lot of money. For a million-dollars-a-year business, that's upwards 6 months worth of a developer's time.

[0] 3% based on how many people will abandon a page that takes more than 1 second to render: https://blog.kissmetrics.com/loading-time/?wide=1

Post reply on HN