I leveraged the Flux architecture powered by the
immensely popular Redux library. For a cleaner
integration with Angular 2’s injector and TypeScript’s
type system, I wrote a class-based wrapper around Redux
that exposes state changes using RxJS observables.
Consumers can subscribe to these observables and use the
Store class to dispatch state-changing actions.
This reads like a Markov chain generated from a pool of top voted Hacker News Javascript submissions.
Hah. Just the other day I was swearing about the Javascript trend that there is always an obscure thing X that solves obscure thing Y. And then there's huge hype about it.
I know what you mean, and yet this buzzword heavy cosmetically obscure quote, when realized, results in an IMO simpler, clearer, and more elegant end product and developer experience. Funny, that.
I hate to be cynical, but reading an article like this makes me chuckle to myself thinking about how much vitriol is still spewed at Java for its over-engineering dark ages.
I start to have flashbacks when an innocent sounding article like this has so much word soup that it has to be cross-referenced against half a dozen other technologies.
For Javascript's sake, I propose we skip the phase where we implement Enterprise JS Beans, and go straight to Spring JS so we can all finally get some work done.
"All problems in computer science can be solved by another level of abstraction...except for the problem of too many levels of abstraction." [1]
BTW, if you want less framework-ness. Try a lightweight vdom lib. I worked with Mithril [2] for a while but after a few projects decided that MVC was poorly suited for front-end components. I'm writing what IMO is a great vdom view layer that's extremely fast, ~8k min, flexible (imperative/declarative), pure js and pleasant to use [3]. Feedback welcome :)
perf is 2x mithril and 1x inferno at high mutations and "only" 0.5x inferno at low mutations. "only" because domvm gets 70/s vs inferno's 135/s on my i5 cpu on dbmonster at 1% mutation.
however, domvm views support isolated redraw and even granular node-level patching. so you can optimize much faster if needed
I've done a ton of professional development in Angular, and a fair amount recently in React. I've enjoyed them both a lot.
When I think deeply about it though, I'm not sure that any of it is better than what I experienced on a pretty big GWT project back in 2010. Yes, everyone was horrified that I was compiling Java to JavaScript. But everything just worked. I had a nice MVP architecture set up, and dependency injection using Guice. Maven was a minor pain at times, but mostly just worked to handle dependencies and get things built. Debugging in Eclipse while the app was running in the browser just worked. I really liked UiBinder templates. It definitely didn't feel like heavyweight Java. Just a bunch of lightweight components communicating asynchronously though an event bus.
The JavaScript ecosystem has definitely made some huge strides over the past couple of years. Time will tell if we see enough ROI on the complexity explosion to make it worthwhile.
> When I think deeply about it though, I'm not sure that any of it is better than what I experienced on a pretty big GWT project back in 2010. Yes, everyone was horrified that I was compiling Java to JavaScript. But everything just worked.
I used GWT in 2008 - 2010 and I would 1000% agree with you.
I'm currently working in a large team (100 ish Devs) for a large project written in 95% JS so I have something legit to compare with my previous experience.
GWT goes like this: Maven + MVP + EventBus + minimum DI + JUnit trumps the fiasco I'm dealing with JavaScript ecosystems nowadays.
It's sad that GWT didn't win mindshare due to a few reasons:
- Bad Rap: Java in 2006-2010 was getting a lot of heat from Rais, Google Wave was a flop (it was the most-talked GWT project)
- Back-end Dev rarely wants to touch Front-End development and Java developers are largely Back-end Dev
- Front-end Dev hates "enterprisey" so they refused Java and its ecosystems
- In general, front-end community didn't have a solid grasp of good software practices hence perhaps they don't quite understand the benefits of GWT (feels like I'm throwing blanketed statement but bear with me).
GWT was ahead (and probably still!) of everything:
- Dealing with Sprites and Resources a LOT easier than anything in front-end stuff we have to deal these days
- i18n framework built-in (have you ever seen a JS solution for i18n? doubtful)
- Pruning dead code!
- Static Analysis via Java
- Good Solid unit-testing framework again via Java (no QUnit vs Jasmine vs Mocha)
- That debugger .... very sexy!
- SASS? LESS? Nah... GWT has a good solution for that...(ClientBundle)
- Sane and Stable Date and Number formatter
Hm.... I'm re-thinking of using GWT again for my side project....
Oh man, I forgot about sprites and resources! Those were so nice to deal with.
I hear that the current dev builds of GWT support Java 8 syntax, and last I checked I saw quite a few Google developers still working on to to add some much improved JavaScript interop. So although it hasn't gained huge mindshare, it at least looks like it is far from dead.
Checking it out for a side project sounds like a really good idea.
Not too long ago Google use GWT for INBOX which brings familar face back to the community, notably Cromwell. Maybe that's the reason behind some contribution from Google.
As a JS lover, it makes me sad how convoluted the tool chain has become in recent years. All the devs who use these tools keep telling themselves and anyone who will listen how simple and efficient their stack is - despite relying on 5-8 different libraries, frameworks, patterns, etc.
To be fair, not everyone is suggesting you need a scripted build system, but you do need some sort of build step, because <script> tags just aren't sufficient for anything beyond a trivial app. (Also ultimately, you do need to minify your code for production).
This build step can just be 'browserify main.js -o bundle.js'. This is where I suggest people start or go back to if they are intimidated by all the various options.
> This is an artifact of the maximum complexity of front end apps having risen dramatically in recent years.
Front-end apps aren't more complex. Back in 2006-7 people were already writing complex front-end apps with frameworks like GWT or ext-js. What changed is front-end developers dropped the widget oriented frameworks for a lower level approach (stateless components). But the complexity of the apps have not risen.
You don't need IoC containers with javascript, it's useful but not mandatory. Angular2 tries to be some kind of kitchen sink of web frameworks but is losing its pragmatism in the process. I can guarantee that it will be drag its adoption speed.
You have 2 possibilities yes, but afaict Angular 2 doesn't push you to use 'its way', unlike the early days of Angular 1 where 'the way' to do state was $scope.
So I could see how you could comfortably use Angular 2 with Redux as long as your team was on-board to always do state the Redux way.
As somebody who has been writing an Angular2 app in ES6, it kind of saddens me that Google has gone all-in on Typescript despite it's glaring departure from future web standards.
Specifically, the parameter annotation syntax they use is much different from that proposed in the future ES7 spec.
I really like Angular2 but it's hard not to feel like it was created as a promotional tool for Typescript adoption.
Types in JS are mostly 'window dressing' to protect devs from themselves and allow for better autocomplete support. They come with a performance overhead so they'll be disabled in production anyway.
Anyway, it's very interesting that Op went with Redux. Redux is pretty game changing in terms of reducing the feedback cycle between changes. Hopefully, better Redux support in NG2 is forthcoming.
Types come with a performance overhead and will be disabled in production?
Sorry, I don't understand that. Typescript transpiles to plain JS, so there are no types at runtime no matter whetzer you are developing or in production. And therefore there is also no performance overhead. The only overhead I can think of is if you are transpiling code at runtime instead of build time using some JSPM plugin - but then the overhead is not related to types but to transpiling (it would also be there for typeless coffeescript transpiling).
And I also thought that typescript decorators are explicitily following the most recent ES7 decorator proposals and are even marked as experimental in TS to be able to react to changes if the ES7 syntax changes.
