Hacker News Reader

Comment by runin2k1 | Hacker News Reader

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.

View on HN

"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 :)

[1] https://en.wikipedia.org/wiki/Indirection

[2] http://mithril.js.org/

[3] https://github.com/leeoniya/domvm

I like it!

Can you add a comparison section to mithriljs and/or infernojs (the current leader in vdom performance)?

Also an example for routing would be nice.

Keep up the great work!

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

see here: http://mathieuancelin.github.io/js-repaint-perfs/

no routing yet, but some plans are brewing...wip :)

domvm looks like something I might use. I know javascript, but I never could wrap my head around the larger frameworks.

would be glad to answer any questions. feel free to open issues. the docs are sufficient but far from exhaustive.

No kidding.

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.

GWT was amazing at the start, I loved it, and I agree with all your points, some of these are things JS frameworks are just starting to reinvent.

But then the project got big and it was the worst coding experience.

The compile phase was taking way too long (5m), to the point that we had to buy SSDs for everyone, this was back in 2010.

And integrating 3rd party JS was bad, just like JNI. We were missing so much of what was offered with open source JS.

Those are definitely the issues that drove me nuts too.

Although if the community grew to the level of Spring Framework, I doubt integrating with 3rd party would be such a big issue.

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.

I'm kinda glad I left frontend dev just as JQuery peaked lol

It's not Real Programming [tm] unless there's a scripted build system. And a big conference.

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.

> 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.

Reply on news.ycombinator.com