What is your take on Meteor JS?

[akamaozu]

Vanilla JS isn’t that scary, but no doubt frameworks reduce what you actually need to write to get things done.

[logbon72]

@akamaozu

Conventional JS/HTML is trash. You put globally accessible callbacks in your html. You store state in dom. You modify the dom atomically. The least amount of shift is a positive thing only if what you’re shifting from is good in the first place. What you’re holding on to is familiarity, not necessarily what’s best for you

Contrary to what you might think, it’s control, not familiarity that will keep me stuck to the traditional HTML/JS. I prefer learning from first principles, I write many languages at the same time and will like things to remain consistent in a single project. The problem with frameworks is that they are generally opinionated, but as though that is not bad enough, frameworks like ReactJS alter the syntax of their base language. That’s my beef. For me that’s a big shift. I don’t want to have to readjust all my tools and editors to accommodate a new framework when another one can come up tomorrow to displace it and become the new cool. If I can get another framework to get my work done and done effectively, without that overhead, I’d go for it.

However, if the benefit of learning a new framework overweighs the benefit, I’ll definitely make the needed shift. For example, my next JS project will definitely be in ReactJS rather than Angular, because Facebook has released React native for Android, for me that is worth the jump.

@akamaozu

There was no way I’d have been able to open up the app to more people without the server consistently going down. The service would never be able to sustain 100 users. That’s a very very small audience, imo.

Background queues would have saved you the stress of over-architecture, all you need to do is create a background thread to handle this, and the thread will have its own execution pool with limits, etc. I am all for microservices too and many of the apps I design these days are designed to be easily decoupled if need be, however, this statement

Microservices are the ideal architectural design for apps

is misleading.

[akamaozu]

C’mon @logbon72 I’m not picking a fight with you over these things. I’m just telling you how I see things.

@logbon72

The problem with frameworks is that they are generally opinionated, but as though that is not bad enough, frameworks like ReactJS alter the syntax of their base language.

@adim86 will vouch for my dislike of frameworks. React isn’t a framework. It’s a library for managing your views. React is written in plain Javascript. All that JSX stuff is trash to me. It’s good that there’s syntactic sugar but I’d rather write the code in its ugly raw form myself. Point is there really is no shift to use React. You’re just making a JS representation of your HTML.

@logbon72

For example, my next JS project will definitely be in ReactJS rather than Angular, because Facebook has released React native for Android, for me that is worth the jump.

In the DOM i know exactly what problem React solves for me.

1. It keeps state.
2. It updates in batches, as opposed to atomically.
3. It times the updates with the browser rendering cycle.

These are real problems with working in the browser. Touching the DOM is literally the slowest thing you can do in web development. I profiled an action that does comparisons over a complex data structure and renders the result in the browser. The longest calculation time was 2ms, yet the operation takes anywhere from 5ms to 65ms depending on the speed of the browser.

Yep. Touching the DOM to create nodes slowed the performance down that badly.

React minimizes and optimizes those with the three things I listed above. You can do all three by yourself in Javascript. It’s just a lot of work to do it so its a lot less effort to use React.

@logbon72

Background queues would have saved you the stress of over-architecture, all you need to do is create a background thread to handle this, and the thread will have its own execution pool with limits, etc.

There was a queue in the monolith version. Also, used Node for this. Background thread, execution pool … nonexistent.