News for hackers. Stuff that matters.
Re:Netflix: Removing client-side React.js improved performan... by bigmanwalter on Friday October 27, 2017 @11:54AM (#15569600)
That's completely untrue.

I've built both SPA and traditional fullstack applications similar to the mentioned architecture (although I prefer Python over PHP).

Fullstack is a fraction of the complexity, with much more power. You can even use a simple library like PJAX to get all the same speed boosts an SPA offers without introducing any of the additional complexity.

To be honest, I don't see what React offers beyond what you get with a templating language like Handlebars, and a few lines of jQuery for initializing components.

This is, of course, for database heavy applications where each action requires the backend. If you're building a game, or an app that's mostly offline, SPA can be helpful.

Re:Netflix: Removing client-side React.js improved performan... by davidpatrick on Friday October 27, 2017 @12:23PM (#15569852)
SPAs arent meant for solving the issue of offline apps and building games in web browsers. Their target was to address the difficulty of building, maintaining, extending an ever changing UI in a corporate development environment.

Having worked on a ui in this setting, built with erb, jquery, and pjax... It is not about the degree of difficulty building it, but extending/modifying it, and collaborating with multiple crews in the same codebase. These are problems enough teams have experienced that they have moved away from the approach of jquery+handlebars.

Now granted, SPAs have a bandwagon effect because of where the job opportunities are, so you get people using them not to solve those problems, but to align their technical skills with employable skills.

Re:Netflix: Removing client-side React.js improved performan... by always_good on Friday October 27, 2017 @01:14PM (#15570316)
I have a hard time believing that you built a non-trivial SPA that you consider easy to maintain without an abstraction beyond jQuery.

There's just inherent complexity in software, so it's like suggesting that you built an application without ever writing code outside of main() (functions are for hipsters).

Re:Netflix: Removing client-side React.js improved performan... by bigmanwalter on Friday October 27, 2017 @02:06PM (#15570791)
I mean, you're welcome to have a look at it https://github.com/IEMLdev/Intlekt-editor

An example of how I put together a component is here https://github.com/IEMLdev/Intlekt-editor/blob/master/src/sc...

- My "view" function takes a template string and replaces the node's content whenever "render" is triggered.

- I create a "model" object which triggers a "render" event anytime it changes. You can also give the model object methods which act as Redux-style reducers.

- The controller method is a shorthand for registering multiple jQuery events at once.

That's pretty much all you need for a complex app. It's the entire React-Redux architecture à la jQuery + ES6.

Re:Netflix: Removing client-side React.js improved performan... by always_good on Friday October 27, 2017 @03:19PM (#15571384)
That's quite a complicated, embedded framework.

If that's "just jQuery", then React is "just ES6". I don't understand the distinction. Every abstraction is built on the layer below. You just rolled your own bespoke one instead of using one that already existed.

> I don't see what React offers beyond what you get with a templating language like Handlebars, and a few lines of jQuery for initializing components.

You say that like that's all your framework does, but I see more than that.

Seems you're mistaking different trade-offs for objective improvements, something that almost rarely exists in software despite what you read in HN comments.

Re:Netflix: Removing client-side React.js improved performan... by bigmanwalter on Friday October 27, 2017 @04:09PM (#15571801)
The idea behind React is pretty cool, that all DOM transformations happen in the template. But that's all it is.

There's no need for a vdom for the most part, template strings and innerHTML are fast enough on their own.

I just find React to be an overly complicated way to achieve its goals.

   var model = { text: '' }

   var component = $( '.component' ).on( 'render', function() {
       $(this).html( `<div>${ model.text }</div>` )
   })

   update( 'text', 'Hello world' )

   function update( key, val ) {
       model[ key ] = val;
       component.trigger( 'render' )
   }
That's React in 8 lines of jQuery. My framework is just a minor extension to this concept.
Re:Netflix: Removing client-side React.js improved performan... by tomasroggero on Friday October 27, 2017 @04:31PM (#15571969)
> That's React in 8 lines of jQuery

No sir, that doesn't include server side rendering or diff rendering either (meaning changing a bit on the top component would re render all markup, not just what has changed)

Stop trying to over-simplify. The problem being discussed here is not React vs jQuery. It's what we do and the decisions we make as engineers to provide a good experience based on performance which is OUR side of UX.

Re:Netflix: Removing client-side React.js improved performan... by bigmanwalter on Friday October 27, 2017 @08:37PM (#15573364)
I mean, you can use either the of the morphdom or setdom libraries to do the diffing if you don't want to replace all the HTML, but the concept remains the same.

I'm not convinced by arguments such as "when you're a large team it's necessary". Scaling teams has more to do with project structure than what rendering library you use.

Likewise, it's much easier to tweak performance when you aren't depending on a monolith like React or Angular.

Re:Netflix: Removing client-side React.js improved performan... by tomasroggero on Friday October 27, 2017 @04:29PM (#15571949)
I'm sorry bigmanwalter but you're working on a team of 3 people, not 100+ engineers working in the same codebase.

And you've created your own abstraction beyond "jquery bits for each component".

This is proper vanillaJS engineering, I do the same, it's just not what you're selling here.

Re:Netflix: Removing client-side React.js improved performan... by bigmanwalter on Friday October 27, 2017 @08:40PM (#15573379)
Well of course I've created my own abstraction... that's what programming is.

I prefer to keep my abstractions simple and light, and preferably built using lower level libraries. If I can build a powerful component system in 150 lines of jQuery (and it would be barely more in vanilla js), I much rather do that than than import a 30kb + library.

There are plenty of 4kb react alternatives to choose from. Most with vastly simpler APIs. Choo.js or Mithril come to mind :)

Re:Netflix: Removing client-side React.js improved performan... by cname on Friday October 27, 2017 @01:34PM (#15570508)
> I don't see what React offers...

It sounds like the sites you've worked on didn't have enough UI complexity to make something like React necessary. Even for a relatively simple admin or dashboard type site, using a more modern framework/library will make it much easier to build and maintain.

Re:Netflix: Removing client-side React.js improved performan... by bigmanwalter on Friday October 27, 2017 @02:08PM (#15570814)
I use a modern batteries-included fullstack framework. It's incredibly easy to maintain :)