Whatever issues you had that caused a block to be “killed” after editing was entirely unrelated to the two different methods of writing the block that you have outlined.
Building a custom block using the following method
(https://github.com/WordPress/gutenberg-examples/blob/master/03-editable/block.js)
of attributes with the –es5 flag appears to be more stable in terms
of backwards compatibility. If I were to make changes to the render
template
(https://github.com/WordPress/gutenberg-examples/blob/master/03-editable/index.php)
it wouldn’t break the block.Using the ‘React’ method
(https://github.com/WordPress/gutenberg-examples/blob/master/03-editable-esnext/src/index.js),
in my past experience, has caused issues. If I build a custom block
using this method and a change has been made to the block’s code, it
‘kills’ the block. There is no backwards compatibility from what I can
tell.
The code in those two method is, for all intents and purposes, the same. They are just using different syntax.
The ‘React’ method (they’re actually both React) is using some newer JavaScript features, but those are just nicer ways of writing the same code that work in newer browsers. That method also uses JSX for the render functions. This is just a different way of writing those functions which can be turned into functions exactly like the first example by a build process.
The issue you’re describing is going to be a challenge of developing blocks regardless of which method you use. When a post built with the block editor is saved, the final output of your block is just saved into the post content as HTML. When the post is loaded back into the editor, your block needs to be able to parse that HTML and reconstruct the block data so that it can be edited again. If your block has changed since that HTML was published, it may not be able to do this and there will be an error. This is the expected behaviour.
The proper method for handling block updates without breaking existing posts is to ‘deprecate’ the block. The official documentation, with code examples, for that process is here.
If you encountered this issue when using ESNext, but not ES5, then that is more than likely a coincidence. It would have had more to do with what you were doing than which method you were doing it with, as this behaviour is a consequence of how block data is stored, and nothing to do with the JavaScript version used to write the block.
It’s worth pointing out that this is not a unique problem for the block editor. If I write a bunch of code in any system that works with data in a certain format, and then I update that code in a way that changes the format, I can’t expect the code to just automatically work with data in the old format. You need to think of the HTML your block outputs as a format, and approach developing your block accordingly.