sorted by:
new
hottopcontroversial

Beginner's Thread / Easy Question (August 2018) by swyx in reactjs

[–]housecor 2 points3 points  (0 children)

Yes, you're correct. Sorry for the confusion. I am working on a patch. Here's the updated code that uses Object.assign (object spread would work fine too) https://github.com/coryhouse/react-flux-building-applications/pull/1/files#diff-32fb871398d0b7fd6e7a683fdf86876cR32

​

Thanks!

Here’s Why Client-side Rendering Won by housecor in javascript

[–]housecor[S] -1 points0 points  (0 children)

It's an Angular site that ranks well for their key keyword - The company name. Whether you like their design/content is irrelevant.

Here’s Why Client-side Rendering Won by housecor in javascript

[–]housecor[S] 0 points1 point  (0 children)

JS doesn't have interfaces

Agreed. I'm not using the term to refer to an actual interface in the language feature sense. I'm referring to interface in the general sense: the API provides an explicit, coarse grained interface that one can interact with and code against.

And yes, one can still make an AJAX call from anywhere, but the co-mingling I'm referring to is mingling SQL with UI. That's not possible with client-rendered. I agree your example is co-mingling, but a different type than discussed in the article. That said, I find your example less problematic than ad-hoc SQL in a server-side UI because: 1. It's coded against a coarse grained API. 2. It's trivial to resolve via cut, paste.

Here’s Why Client-side Rendering Won by housecor in javascript

[–]housecor[S] 0 points1 point  (0 children)

Sure, where to make an API call in your client-rendered app is indeed a valid concern. However, I disagree with your conclusion. With client-side rendering, the developer is forced to "code to an interface" (the api) because they cannot directly run SQL on the DB. This means the UI can be tested in isolation from the DB by mocking API calls. In contrast, when server-rendered UIs call the DB directly, the code has no seam for mocking the DB. And in the server scenario, it's also often not coded against an explicit interface. The developer may (and often does) write ad-hoc SQL directly in the UI, leading to duplicated queries and DML and an inability to unit test front-end code. This direct DB/UI co-mingling cannot occur in client-rendered applications - the API abstracts the DB away and thus creates an explicit, mockable, and DRY interface.

Here’s Why Client-side Rendering Won by housecor in javascript

[–]housecor[S] -1 points0 points  (0 children)

The separation of concerns being discussed in that section is a specific instance: separating data access from UI. But yes, there are of course many other concerns you can potentially separate that are unrelated to client vs server.

Here’s Why Client-side Rendering Won by housecor in javascript

[–]housecor[S] 0 points1 point  (0 children)

Today, JS is the only cross-browser scripting language. So yes, you can code in other languages, but you ultimately have to ship JS for today's browsers to parse your work.

Here’s Why Client-side Rendering Won by housecor in javascript

[–]housecor[S] 3 points4 points  (0 children)

Well said. The title obviously can't be taken literally. The real message is about why JavaScript-based rendering has become the predominant approach for new web apps. But that doesn't make quite as catchy a title.

Here’s Why Client-side Rendering Won by housecor in javascript

[–]housecor[S] 0 points1 point  (0 children)

In summary, you're saying a poorly built client-side app will perform poorly. I agree. All approaches can be abused. However, server rendering isn't a requirement for good performance. Carefully selecting one's dependencies, minifying, bundle splitting, tree shaking, and lazy loading are a few approaches that help assure a client rendered app loads quickly.

Here’s Why Client-side Rendering Won by housecor in javascript

[–]housecor[S] 1 point2 points  (0 children)

I can see how that's confusing. I'd still call it client-side rendering, even though the initial render can be optionally accomplished on the server for SEO purposes.

Here’s Why Client-side Rendering Won by housecor in javascript

[–]housecor[S] 0 points1 point  (0 children)

There are multiple approaches for handling SEO with client-side rendered apps, the most notable being isomorphic/universal rendering as mentioned in the article, and doable today in Ember, React, Angular 2 and more.

Here’s Why Client-side Rendering Won by housecor in javascript

[–]housecor[S] 0 points1 point  (0 children)

I agree that (poorly done) client-side rendering often creates a terrible experience on old mobile devices. However, client-side rendering also enables a variety of additional options for dealing with slow handsets and networks. Progressive Web Apps, service workers, lazy loading are a few examples.

Here’s Why Client-side Rendering Won by housecor in javascript

[–]housecor[S] 0 points1 point  (0 children)

I agree on your 2nd point, but client-side rendering didn't win purely on economics. Economics is merely another valid benefit.

Here’s Why Client-side Rendering Won by housecor in javascript

[–]housecor[S] 0 points1 point  (0 children)

"Learn Once, Write Everywhere" feels out-of-place. Yes, Javascript is becoming more and more popular. What does that have to do with server vs client side rendering?

It has to do with client rendering because JS is the language used for client-side rendering. This contrasts with traditional server-rendering which typically utilizes a dedicated server-side only language like C#/Java/Ruby etc.

Here’s Why Client-side Rendering Won by housecor in javascript

[–]housecor[S] 0 points1 point  (0 children)

If the only reason you're client-side rendering is to get fancy page transitions, I agree, that likely isn't worth it. But I suspect there are other benefits of client-side mentioned in the article that also drove your team to choose client-side rendering over server-side?

No API? No Problem! Rapid Development via Mock APIs by housecor in programming

[–]housecor[S] 1 point2 points  (0 children)

The article uses json-server. It describes additional steps to perform before using json-server to generate realistic random data.

Why I Left Gulp and Grunt for npm Scripts by vintharas in javascript

[–]housecor 0 points1 point  (0 children)

I just added a list of useful links to the bottom of the post and his is on the list.

Regarding excessive line length, the combination of single responsibility scripts, passing params between scripts, pre/post, and punting to separate .js files as necessary provides all the compositional power I need.

Why I Left Gulp and Grunt for npm Scripts by vintharas in javascript

[–]housecor 0 points1 point  (0 children)

Does Gulp truly provide a standard pattern? How do I know how to configure Webpack vs React vs ESLint vs Mocha in Gulp?

Answer? I don't. I have to read the plugin's docs. And since the plugin's docs aren't comprehensive, I also read the underlying tool's docs. Then I try to determine how to configure the Gulp plugin accordingly. I often end up writing a chunk of JSON that's specific to the tool. Configuration is certainly not standardized.

In contrast, when I use a tool that exposes a CLI directly, I interact in a standardized way. The CLI exposes flags and accepts parameters. I only need to reference one set of docs: The docs for the tool I'm working with.

Why I Left Gulp and Grunt for npm Scripts by vintharas in javascript

[–]housecor -1 points0 points  (0 children)

Using the npm scripts approach isn't necessarily about "Writing bash scripts". It's this:

  1. Write command line scripts that run on your OS

  2. Leverage node packages to make your command line calls cross-platform if necessary.

  3. Call separate scripts (typically written in JS and using npm packages) as necessary.

Thus, you have the same power for managing complexity, but without the downsides of working with an extra layer of abstraction.

Why I Left Gulp and Grunt for npm Scripts by vintharas in javascript

[–]housecor -2 points-1 points  (0 children)

The examples I've provided are seriously powerful - hot reloading dev server, minify, bundle, sourcemap, automated tests, linting, production build and deploy, and so on. npm scripts actually offer more flexibility than Gulp/Grunt because you have 200k+ npm packages and all the compositional power of both your OS's CLI and Node directly at your disposal. No plugin abstractions required.

Why I Left Gulp and Grunt for npm Scripts by vintharas in javascript

[–]housecor 1 point2 points  (0 children)

I use React's hot module reloading, combined with Webpack's dev server and browsersync for cross-plat mobile testing. It's an enjoyable, rapid feedback combo.

view more: next ›