Live data from Hacker News

You probably don't need a JavaScript framework

slack-files.com

241–250 of 356 posts

Re: You probably don't need a JavaScript framework

#241

Earlier quoted context omitted.

"I feel like people who say "just use the dom" don't actually have enough experience to know why that is such a bad idea." "You people really are kidding yourselves. I feel bad for whoever is paying your salaries." "Honestly, it just sounds like you are bad at managing your own software projects" "I'm really glad I don't have to work with people who think like this." "Both are signs of inexperience." "I guess I won't…

I am very good at what I do. I have had lots of these conversations with other people who think they are good at what they do. This line of thinking kills companies, because the prototyper they hired for their "MVP" doesn't like frameworks. A year later he/she is gone and I'm rebuilding their app as an angular app. You don't have to agree with me, but I am right. Millions of of dollars in contracts and a resume full…

> You don't have to agree with me, but I am right. Millions of of dollars in contracts and a resume full of happy returning clients says so.

They tell me that you can cover the tracks of your desasters long enough to move on, so that problems surfacing later are attributed to the maintenance programmers and not you, even if your "great" choice of frameworks were the real reason.

Re: You probably don't need a JavaScript framework

#242
post #61

"Another example is the Fetch API"... That API has very limited cross-browser support. One of the largest reasons web frameworks exist is to bridge the gaps between browser incompatibilities/offering legacy support. I don't know if this person has even really scaled and deployed a web application that must work across several browsers - especially older browser versions. I always wonder that whenever I see people bas…

Yeah I find it hard to believe that the people who go on about how convoluted web development is actually get paid to do web development. 1) Where are all the people hiring web devs who don't know a single library or framework? 2) Why do huge tech companies like facebook and google develop web frameworks if they're unnecessary?

> Why do huge tech companies like facebook and google develop web frameworks if they're unnecessary?

For the same reason you should write your own "framework": An internal 'framework' is nothing more but a certain way of structuring your code, so that it works for you and your problems, which no one ever argued against. It gets far harder to make that case when you say "well, all my problems can be taken care of by popular framework of the day" - now you can only solve problems well which fit the frameworks model. And if your problem doesn't fit the model you start writing around the framework, so in the end you have written - again - a custom framework, which only in name resembles the one you started with.

Re: You probably don't need a JavaScript framework

#243
post #42
post #34

Earlier quoted context omitted.

I don't see that. Actually the only bit that seems uncivil to me is just "You just didn't read past the sentence you quoted." You can't know that, and such statements are the internet comment equivalent of elbowing.

I was responding to the last line of his comment, coupled with the fact that the comment completely mischaracterized the article based on a single line, early in the piece. I admit that the last line is unnecessary. I'll remove it.

(I didn't downvote you, I really don't mind, but it did sound aggressive).

Here's what you wrote: >> 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. The argument is that most people don't need React, not that they don't need AJAX or data binding.

Here's a political rewrite (Keep in mind I'm not a native english speaker):

It seems that the author addressed your points later in the article. For instance, rather than rendering every state change on the server-side, it explains how you can get data-binding and partial-update behavior with web-native APIS.

The main argument of the article is that most people don't need React, not necessarily that they don't need AJAX or data binding.

Re: You probably don't need a JavaScript framework

#244
post #219
post #158

Earlier quoted context omitted.

Using a JS framework like jQuery or Angular or React isn't even remotely similar to Enterprise Java Beans and all that nonsense. You must be joking.

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?

Re: You probably don't need a JavaScript framework

#245

Earlier quoted context omitted.

> And then having a common app structure with thousands of other people that can provide help and insight. You don't think that there are thousands of people who can provide help and insight into the standard Web & DOM API's? I mean, do you in all seriousness think that there are more people that can help you with React than it is that can help you with the Web & DOM API? Not to mention the standard browser libraries…

>There's examples online of a router that's 20 lines Yes, 20 lines which you have to be responsible for and maintain... and changes over time add up to make it 200. >The browser already takes care of data transportation ... HTTP protocol, WebSocket protocol or WebRTC Yep, with boilerplate code that you have to write and again, grows as your use cases grow. >if you absolutely need one, here (frzr) Oh, some view layer…

> Oh, some view layer some guy came up with 22 days ago... or something that has been working for a decade for facebook. I wonder which one I want to go with.

Tell us, because - as I am not Facebook - I couldn't decide without checking both, maybe making a simplified prototype of what I'm trying to accomplish and see which one fits the use case better. You seem to have another process?

Re: You probably don't need a JavaScript framework

#246
post #217
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…

Sure, if the software gets totally junked in a couple years then lifetime costs of the implementation become less of an issue.

I work in an environment that's quite lean, but where deployment can take up to a year and lifetime is measured at the decade level so in my case the more traditional 'implementation is 10% of total costs' actually applies.

Re: You probably don't need a JavaScript framework

#247
post #217

Earlier quoted context omitted.

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

Personally, I have terrible pangs of guilt if I know I leave a mess behind me. I've had to suffer fixing enough of someone elses messes to know what a timebomb of anger and frustration that is.

Re: You probably don't need a JavaScript framework

#248
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 when needed. I like this way than using giant frameworks like react and angular.

Re: You probably don't need a JavaScript framework

#249
Whilst predictably this HN thread has turned into a bit of a flame war I would like to point out the article certainly made one indisputable point. That HTTP/2 is going to change how modern web apps are written all over again. So then we'll all need another new framework.

Re: You probably don't need a JavaScript framework

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

Post reply on HN