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

Re: You probably don't need a JavaScript framework

#301

Post by mbrutsch » Sat, Apr 30, 2016, 4:26 PM UTC

sbarre wrote: post #268

mbrutsch wrote: post #257

Earlier quoted context omitted.

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

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

Re: You probably don't need a JavaScript framework

#302

Post by ssmoot » Sat, Apr 30, 2016, 4:29 PM UTC

oblio wrote: post #280

ssmoot wrote: post #269

Earlier quoted context omitted.

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

Gmail also offered 1GB+ at a time when generous competitors offered 100MB.

Great point. In the time before Dropbox, S3, etc Email was THE way to share your 50Mb zip file. And routinely having to clean your mailbox because you ran out of storage was a huge pain.

Re: You probably don't need a JavaScript framework

#303

Post by tomc1985 » Sat, Apr 30, 2016, 4:29 PM UTC

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…

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 users demand it. A SPA feels substantially faster and more reactive. Users notice.

Dude! Whoever said we were railing on SPAs? But since you bring up Gmail I'd just like to note that gmail has been a slow, bloated mess for many years now. It takes a half a minute for the page to stop janking on my dev box with 50mbps internet, so I think Gmail in its current state is a poor choice of example. Gmail of old, back before they tried to cram 80 million things into it, was a pretty good example.

Re: You probably don't need a JavaScript framework

#304

Post by Silhouette » Sat, Apr 30, 2016, 4:41 PM UTC

neppo wrote: post #278

jerf wrote: post #276

Earlier quoted context omitted.

"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"." I completely agree. Web people quite often commit to frameworks based on their marketing copy and maybe one guy they read on the internet saying "seems pretty AWESOME after I've played with it for two days!" and a testimonial or two. Of course, I've seen de…

Serious question: How else can you adopt a new technology, without investing significant amount of time? It would be nice to exhaustively explore a tech before using it, but that's often simply not feasible due to lack of resources.

How else can you adopt a new technology, without investing significant amount of time?

I suppose it depends on what you consider "significant" to mean. I have found close to 100% correlation between new technologies where I can understand the basic use cases and structure within a few hours and be moderately productive within at most a few days, and new technologies that have proven to be worth the effort in the long term when I've tried them. I can't immediately think of any exception to that rule within the field of front-end web tools I've tried so far.

Re: You probably don't need a JavaScript framework

#305

Post by natrius » Sat, Apr 30, 2016, 4:46 PM UTC

MrGando wrote: post #220

geoffpado wrote: post #62

Earlier quoted context omitted.

I, too, did a double-take at the use of the word, but I looked it up, and it seems to be a valid usage. Various dictionaries define program merely as a "set of instructions," so, yeah, a library or framework counts as a program just as much as a separate process.

I just felt a program is such a general and high-level way to describe software... basically anything that computes... wikipedia: " collection of instructions that performs a specific task when executed by a computer " We can do better than describing a JS Framework/Library, than calling it a program I guess.

I used "program" because that's what we call things that automate things for us, and that's the appropriate frame for thinking about React: it automates things you could've done by hand, but why do that?

Re: You probably don't need a JavaScript framework

#306

Post by tomc1985 » Sat, Apr 30, 2016, 4:47 PM UTC

morgante wrote: post #240

tomc1985 wrote: post #185

Earlier quoted context omitted.

As a user of React, I disagree -- unless you are using React in a javascript runtime, in which case you're probably fine. But I resent react for all the extra cognitive load it forces me to worry about when all I really give a shit about is its shadow DOM implementation. And then, only when I've got page(s) full of data I need to update without lag.

I'd like to correct some misconceptions you seem to have regarding React. > unless you are using React in a javascript runtime, in which case you're probably fine React is written in JavaScript. It runs exclusively in JavaScript. If you've somehow managed to run it outside a JavaScript runtime then I'd actually be delighted to learn about how. > all I really give a shit about is its shadow DOM implementation React do…

Well, react-rails is how. And it's messy as hell.

Re: You probably don't need a JavaScript framework

#307

Post by quickpost » Sat, Apr 30, 2016, 4:59 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…

That sounds very painful.

Re: You probably don't need a JavaScript framework

#308

Post by Silhouette » Sat, Apr 30, 2016, 5:12 PM UTC

sbarre wrote: post #268

mbrutsch wrote: post #257

Earlier quoted context omitted.

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

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.

If your own in-house developers, with full knowledge of the nature of their project and the kinds of requirements they're trying to meet, and with full control over their choice of tools and standards, really can't ever do better than some external organisation that is building a generic tool to cater to generic requirements and writing to general coding standards, then you should probably question the competence of your in-house developers.

This is not to say you shouldn't use existing material from outside your organisation if it's a good enough fit for what you're doing and saves time or otherwise has some tangible benefits, of course. However, your in-house team will normally have a huge advantage in terms of knowing specifics compared to almost any external equivalent. This is true whether we're talking about frameworks, coding standards, tools, or almost anything else used in programming.

The meme that anything written by a larger group of people outside your organisation is somehow inherently superior for your purposes to anything you could write in-house, and that any reluctance to use those external resources is inherently a case of NIH syndrome, just doesn't make any sense to me. There is no logical reason to believe it should be true since you're almost never comparing like with like, and I see very little empirical evidence that it is true in practice either, assuming reasonably competent and experienced in-house developers.

Re: You probably don't need a JavaScript framework

#309

Post by rimantas » Sat, Apr 30, 2016, 5:17 PM UTC

untog wrote: post #283

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…

> The web-boys however, didn't understand asynchronous messaging, cryptography and eventual consistency very well Would it be fair to say you didn't understand the web frameworks very well? I'm not sure that lines of code is a great measure here. What about test coverage? Maintainability? NPM is a package manager - anyone would advocate using that over manual dependency management, no matter what environment you're p…

Lines of code can be a very good measure. You can have an app that is small and easy to fit into the mental model. Or you can wrap it up in huges framework and get lost between the abstractions. We have a saying to shoot sparrows from the cannon, and often using web frameworks looks like doing exactly this: you take trivial case and make it complex just because it is implied that frameworks are necessarey. Doing that you also kill accessibility (remember it? was a thing several years back), load times, etc.

Re: You probably don't need a JavaScript framework

#310

Post by Can_Not » Sat, Apr 30, 2016, 5:20 PM UTC

natrius wrote: post #5

I don't use React for speed. I use it because manipulating the DOM to make it reflect the application state is hard . It's something a program should do for me. React is that program.

I don't think it's hard. If you really think it's hard, I think you can study React's architecture and discern that you can accomplish what you want with React--or with smaller, different libraries in accordance to your use case.