You probably don't need a JavaScript framework • Hacker News Board

Re: You probably don't need a JavaScript framework

#321

Post by morgante » Sat, Apr 30, 2016, 6:29 PM UTC

MustardTiger wrote: post #317

morgante wrote: post #238

Earlier quoted context omitted.

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…

That's the opposite of reality. Users hate it. Overwhelmingly. You did do it for a reason, but the reason was "look I think this is cool!". Users suffer for the fashion driven choices of the web development world.

> That's the opposite of reality. Users hate it. Overwhelmingly.

You have absolutely no evidence of that.

On the contrary, there is abundant evidence that SPAs increase engagement.

You're living in an echo chamber if you actually thing the average user would like to return to the web of the 90s. They love things like the infinite scroll on Facebook, Google instant search, Slack, Trello, etc.

If you think the huge companies implementing these things haven't done extensive user testing to show that people prefer these experiences, you're letting your political agenda cloud your judgement.

Re: You probably don't need a JavaScript framework

#322

Post by MustardTiger » Sat, Apr 30, 2016, 6:32 PM UTC

morgante wrote: post #321

MustardTiger wrote: post #317

Earlier quoted context omitted.

That's the opposite of reality. Users hate it. Overwhelmingly. You did do it for a reason, but the reason was "look I think this is cool!". Users suffer for the fashion driven choices of the web development world.

> That's the opposite of reality. Users hate it. Overwhelmingly. You have absolutely no evidence of that. On the contrary, there is abundant evidence that SPAs increase engagement. You're living in an echo chamber if you actually thing the average user would like to return to the web of the 90s. They love things like the infinite scroll on Facebook, Google instant search, Slack, Trello, etc. If you think the huge com…

An echo chamber? Where? Show me this echo chamber. The echo chamber is the one repeating the same baseless nonsense you are. And where on earth do you get a "political agenda" from pointing out the fact that user testing shows javascript messes are bad?

Re: You probably don't need a JavaScript framework

#323

Post by morgante » Sat, Apr 30, 2016, 6:37 PM UTC

tomc1985 wrote: post #303

morgante wrote: post #238

Earlier quoted context omitted.

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…

No, you can build your own full-text search engine with dynamic pages with postgres' fulltext index types. You can subscribe to changes through LISTEN/NOTIFY, or by outputting log entries in trigger functions, among other techniques. That fulfills the 'dynamic' part of the question. I don't know how you read that question (well, ok, I do), but it's not how I read it. Whiff of an insult duly noted. We did it because u…

> I don't know how you read that question (well, ok, I do), but it's not how I read it. Whiff of an insult duly noted.

I don't know how you read "provide search engines with indexable dynamic pages" as implementing your own search engine. It was pretty clearly referencing the well-known challenge of making your JavaScript-rendered pages indexable by Google/Bing/etc.

> Whoever said we were railing on SPAs?

You are. When you say we should just abandon all this JavaScript and instead render everything through Rails, you're arguing against building SPAs.

Re: You probably don't need a JavaScript framework

#324

Post by jqm » Sat, Apr 30, 2016, 6:45 PM UTC

catnaroek wrote: post #205

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. This isn't true. There is value in simplifying the problem at hand to the point where you don't need fancy tools to solve it. Not always possible, of course...

Some of the most useful things I've written have been the simplest.

In fact, I'd say there is a pretty strong correlation between simplicity and usefulness (for some reason).

You don't necessarily need a heavy framework to make a useful app.

Re: You probably don't need a JavaScript framework

#325

Post by mbrutsch » Sat, Apr 30, 2016, 6:53 PM UTC

sbarre wrote: post #313

mbrutsch wrote: post #301

Earlier quoted context omitted.

> naively doing everything your own personal way (including at the team/company level). You, and my downvoters, all assume (naively) that any in-house standard must somehow be different than "widely-adopted coding standards (that most frameworks probably use)". Obviously, that need not be true, and in my limited 40 years of experience, it rarely is. Not sure how you even got there.

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 widely adopted standards).

Probably.

> If you were implying that those two things might be identical then you did a bad job of conveying that.

sigh. Two things can be true at the same time. I give up.

Re: You probably don't need a JavaScript framework

#326

Post by developer2 » Sat, Apr 30, 2016, 7:14 PM UTC

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…

>> The productivity gained by agreeing on a framework

This is a false dichotomy. This only applies once the developers have real experience with the framework. Throwing a brand new framework at the devs without at least a month to play with it - play, not work! - is doomed to failure. Expecting first-time use of a framework on an actual project to go well is a horrible mistake.

There is a lot to learn with any reasonably sized framework. Making devs use an unknown framework without time to learn it will result in a project that doesn't use that framework properly. Thousands of lines of code will be written... to duplicate functionality the framework already provides, but that the devs don't know exist. The rush of deadlines means that the devs skip reading documentation or researching the "right way" to do every task, and you wind up with a project that technically uses the framework... except that the entire project will be written in a way that someone with previous experience with that framework would never have allowed to happen.

Some frameworks have so much to learn that it's essentially equivalent to having to learn a new programming language. Would you ever expect someone to learn C in a week? Java? Python? No...? Then please don't expect devs to pick up a new framework on the spot with no time to self-train on it.

Re: You probably don't need a JavaScript framework

#327

Post by ruffrey » Sat, Apr 30, 2016, 7:19 PM UTC

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've worked with node/npm/frontendy land for 5 years solid now. At first I used a lot of libraries. I guess with experience, it became clear that relying on as few as possible is much better.

Frankly, build systems like grunt and gulp are not necessary for node or frontend development. You can write the same or much less code, with much less domain knowledge, and accomplish the same thing using npm scripts and plain JS files.

Re: You probably don't need a JavaScript framework

#328

Post by jammons » Sat, Apr 30, 2016, 7:38 PM UTC

CameronBanga wrote: post #23

Are Slack Files an official blog from Slack? For a second, I thought looking at the URL that this was just a URL for a Slack snippet or something similar.

Slack's blog is at slack.engineering. It's called Several People Are Coding. This is not from Slack, as noted by philfreo.

Re: You probably don't need a JavaScript framework

#329

Post by jimbobimbo » Sat, Apr 30, 2016, 7:44 PM UTC

coldtea wrote: post #68

educar wrote: post #50

The main point of frameworks/libraries is to set coding guidelines for the team. It's fine to go off and invent your own framework but this causes maintenance issues for the people coming in next. Most likely, there are no docs or examples for the code you just wrote (especially the framework bits). When a framework which has a community is chosen, these boring things like docs/examples/references/blog posts get fixe…

> When a framework which has a community is chosen, these boring things like docs/examples/references/blog posts get fixed over time. Not in my experience. I've seen frameworks come and go like that over the span of 15 years and teams rewriting for the new "hotness". So, one year they do Angular, then Angular 2 comes out, invalidating a lot of their code/experience, then they get to React, then they're told that they…

Release of a new framework doesn't render all existing code based on an older framework useless. Nobody mandates moving all existing Angular 1 codebases to Angular 2.

Re: You probably don't need a JavaScript framework

#330

Post by angelofm » Sat, Apr 30, 2016, 8:05 PM UTC

gjolund wrote: post #100

coldtea wrote: post #86

Earlier quoted context omitted.

> Complexity requires structure in order to be maintainable. Structure is the job of the lead programmer(s), not some third party framework developer. And it should suit the specific job. It's as if we forgotten that programs have to be designed with an overall architecture based on our business, and instead just download off the shelve scaffoldings and try to adapt our business logic around their design. You know th…

>Complexity requires structure in order to be maintainable. A competent lead programmer will choose a structure that adheres to common best practices and is maintained by a community. Also known as a framework. >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 posi…

I have to say I agree with a lot of your point but your tone comes off really agressive, I think frameworks are good particularly for inexperiences developets that will have a really hard time writing simple and maintainable code, but all people are saying is that in development you cannot just cross out bespoke development altogether there will always be a use case when you need to fine tune your software.

Saying that please bare in mind that I love react it's a great tool but like everything it has its place.