hex13

"Facebook has done a good job of deprecating and warning for the last few months, but not all libraries are well-maintained and if you depend on or have forked a great many ancient ones, you will be in for a bit of a slog.").

This is one of reasons to limit third party libraries you use along with React. Every dependency comes at cost. If you use React and React-Foo, React-Bar, React-Baz and dozen of other React based additional libraries, then upgrading all/troubleshooting can be painful. As it was ("We ran into an error which took us 2 days to track down to a library, ...")

besides - if you generate your SVG programmatically you can just return them in your render function:

function Foo(props) { return <svg> <circle cx="10" cy="10" r="100" /> </svg> }

Once the product-market fit is achieved (...)

it makes sense to start cleaning up the codebase.

This is very optimistic assumption that people will actually clean the codebase at some point. From what I've seen technical debt can stay very long time. Temporary hacks can become permanent.

Spikes/prototyping can be quite effective, but to be effective in writing spikes/prototypes a team must be disciplined to rewrite/refactor later. And from my experience teams are often not very disciplined and pile of spaghetti code begin to grow...

The problem with this approach is that if the tech debt

catches up with you faster than you can figure out the

product-market fit. In this case it gets harder and harder

to move and instead of going faster you go slower

Yeah. This is what I've seen. Even in startups quick and dirty code can be developed over months. And in such long time pile of spaghetti just piles up (people can make quite a mess in days. Imagine what they can do over months...).

Like they say "There are only two hard things in Computer Science: cache invalidation and naming things." ;) Apps without `refresh` claim to be ones which managed to solve caching problem properly (they usually didn't anyway)

I simply asked for the differences,

One of differences could be that Redux has only one object("actor") which can receive messages - that's store.

In actor model there are many actors which can both receive and send messages.

since Redux is much more prevalent.

Actually it's quite opposite. Redux is a library which was created not until 2 years ago and it is used only in JavaScript. Actor model and similar message-passing patterns are in use for decades and not only in JavaScript but in many programming languages. They are popular e.g. in game development for communicating between game objects.

There is this weird viewpoint in JS community that world is turning around JS and its ecosystem, and this is the newest popular library that dictates standards rather than decades of CS knowledge ;)

Redux is a chicken, actor model is an egg. Similar patterns were used decades before Redux was even born.

I think it really helps with maintenance and scalability of

projects down the road and saves you time later on.

It's popular argument but I don't think it's completely correct.

On the one hand principles of Redux (immutability, message-passing approach, separation model from the view) can be helpful, on the other hand huge amount of boilerplate and moving parts can only spoil scalability.

Besides Redux is very low level with very little abstraction (this is why some many abstractions over Redux appear - because Redux alone has almost none).

I think Redux has good foundations but it's poorly designed as a library targeted to average developer working on real projects. It feels more like some academic experiment, something more like proof-of-concept that library that solves real problems in elegant way.

I've created library `transmutable` for performing automatic copy-on-write behavior in JS (you just write imperative code which is transformed behind scenes into immutable updates https://npmjs.com/package/transmutable

This can avoid boilerplate traditionally associated with immutable updates in JavaScript, because you just write

    const copy = transform(original, stage => {
       stage.someArray[index] = 42;
    });

I never understood why to run Slack as desktop app if Slack can be run in a browser with the same GUI and features. Am I missing something?

In practice, though, very little code

written for Electron will run in a browser.

I think many things could run in a browser. All GUI, whole visual layer could run in a browser (maybe except system menus, but they could be recreated in HTML/CSS). All business logic also could run in browser.

Of course there are some other things won't run in browser, for example file system access (but this could be emulated by some kind of virtual file system). Or native NodeJS extensions (if application uses these). Or some system calls.

But these parts (not-compatible with browser) should be isolated from the rest of application and either ported somehow into the browser or just disabled in the browser version.

What I see is something else - projects are written in sloppy way, with bad architecture, where there is no respect for Single Responsibility Principle whatsoever. They are just written in non-portable way (it's matter of architecture rather than technology).

on the beginning I used getters/setters but I switched to Proxy because it allowed for simpler implementation and more flexibility.

I may consider to switch back into getters/setters, if support of Proxy is really a problem (although getters/setters have its limitations).

There is also Proxy polyfill, although it has the same limitations getters/setters have ("properties you want to proxy must be known at creation time"): https://github.com/GoogleChrome/proxy-polyfill

I've build a library Transmutable which falls into the third category :)

it allows to use immutable data structures in mutable-like way, using plain assignments: https://www.npmjs.com/package/transmutable (mutations are not performed but they are just recorded in ES6 Proxy, and object is cloned on commit (sort of copy-on-write), and mutations are then applied).

So it basically enables for writing such things:

    const copy = transform(original, stage => {
        stage.x = 10;
        stage.y = 20;
        stage.foo.bar = 123;
    })

Redux for sure. Smalltalk had message based system like Redux has (with the difference that in smalltalk this system was object oriented). But functional programming also existed in 1976.

"build on top of existing, well-defined codebases/APIs." is not necessarily easier than "engineer a complete, well-rounded, extensible codebase/API himself."

I think these are two different skills. Some programmers are better in building on top of existing codebases, some programmers are better in build things from scratch.

maintaining vs starting.

Eventually you are going to get bugs,

I read:"Sometimes you are going to get event bus." Indeed sometimes simple event bus (pub-sub etc.) could be sufficient for replace Redux. EventEmitter is already a dispatcher. And then you can easily listen to each event in your app, like in Redux.

I think the key to the scalable apps is good architecture (and correct design patterns), not framework.

And Redux is good as education tool. It encourages people to use one global event bus("dispatch" function), it educates about principles of functional programming. It shows people advantages of event sourcing and CQRS. I think the most value of Redux is that people got educated.

But I don't think Redux (at least Redux alone, without Redux-saga or other solutions) is good tool for use in production code. It's too low level. Too many moving parts. No clear way "what should go where". And JS sucks when comes to immutable code (either Object.assign / ... mess or necessity of using third part library like Immutable.js)

Additionally people don't know how to use it properly. Redux codebases are usually much worse than Redux really demands (e.g. people use ugly switch/case despite the fact in Redux docs there are instructions how to get rid of them: http://redux.js.org/docs/recipes/ReducingBoilerplate.html#ge...

what is "lifecycle component"?

It's interesting. What browsers do people use on this machines? Though according to wikipedia most popular browser is Chrome: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers

but it seems weird, because Chrome is such a memory monster (it usually takes almost all RAM memory you have on your machine and additionally disk space if you are running of RAM). I have 16GB ram and Chrome takes me 10GB of it and ~1GB of disk space.

I upvoted you.

BTW how to downvote comments on HN? I sometimes "flag" them to mark as downvote, but I'm not sure if flag is the same as downvote.

I've been downvoted because HN has Dislike Button which encourages people to downvote things they personally don't like instead of making constructive arguments ;)

Ok, maybe I will reconsider C++.

But if you were building such app in C++ what third part solutions would you recommend for building multiplatform GUI? Qt? GTK? What is used now and what will be working/looking good on all three main platforms? (Mac/Linux/Windows)

I used Brackets maybe 2 years ago and it was very slow back then. Maybe now they have optimized it, I don't know.

There is one more thing. Developing in HTML5/JS (with all its ecosystem) is freaking fast in terms of developer productivity. You will probably build full fledge app in shorter time using JS than with C++. So you can deliver MVP to the market faster = profit $$$

And initial group of users are early adaptors anyway. They are usually eager to try new applications even if they are not perfect.

The problem is: "what next?", when users will start complaining about speed or other things.

Should company rewrite original HTML5 based MVP to C++ to gain speed?

Or should they optimize existing HTML5 solution? (many HTML5 apps are running with nearly native responsiveness).

Or something else? Or maybe HTML5 even for MVP is a bad idea?

I think Atom gave bad fame to the Electron (it's ironically because Electron was made for Atom).

Atom is bloated and slow and people think that each Electron(or Chromium) app is bloated and slow.

But for example VSCode is a lot faster (and consumes less RAM, from what I just checked) than Atom. So it's not Electron to blame...

TL;DR: they just invented internet forum/message board but with nicer GUI.

And it's good.

I think internet went wrong way to ditch traditional internet forums/discussion groups/ and internet communication started to be based on real time chats (Slack, Messenger, Skype etc.), but I'm glad that we're returning to the oldschool (I'm waiting for Facebook to introduce "threads/topics" on its groups, because now Facebook groups are less functional than plain old phpBB.

Yeah, this is also true. But "it depends" anyway.

BTW author of article mentions also incidental complexity of Java classes. It's worth consider too and maybe it's more accurate picture of problems with Java (and many other languages, it's more like poor design and "cult of complexity" than technology problems).

There are too many abstractions, classes, interfaces, inheritance, needless design patterns... it kills productivity and maintainability and ability to understand such codebases.

IDEs generate 90% of my Java code;

It's not generating code that is costly, but reading it. Understanding 100 lines of code is usually easier than understanding 1000 lines of code, understanding 1000 lines of code is usually easier than understanding 10000 lines of code etc.

So generally it pays of to keep codebase small and simple.

...and appropriate level of detail doesn't mean every detail should be documented. Sometimes it's better not to document some technical details (which will change anyway, and docs will be obsolete soon).

You could divide (in your head) contract and implementation details. Contract - what "unit" should do, e.g. factorial function should compute factorial for given numbers. But how exactly this is done is implementation detail (will be used recursion? do/while loop? will there be result caching?)

The trick is to omit implementation details from testing, because implementation can change, but after all fact(4) should return 24 no matter what.

So it's useful to think in categories of contract given unit should fulfill instead of testing everything for the sake of testing.