Hacker Newsnew | past | comments | ask | show | jobs | submit | dewanto's commentslogin

Google strategy is WebApps.

Apple strategy is NativeApps with AppStore.

Microsoft strategy is half-half.

...

Google workers complain Safari bad. That's their job. So, business as usual


Please don't read my short summary before you vote, it's only my humble opinion...

https://bit.ly/IOBuildWWDC


If transpilers are not a good tool, what about compilers? Do you want to stay on assembler?

IMHO transpilers, generators and compilers are the standard tools for developers today and abstraction level is the key to become better... I cannot imagine, if we still have to use Assembly lang to program today...

It is definitely difficult to build a good abstraction level and the compiler / transpiler / generator which fits the requirements. But this is the best way to bring the abstraction level up...

Just my 2 cents.


Never said they are a bad tool. Just unnecessary for me if i happen to know the native language those tools are trying to get around. Your extreme example with assembler doesn't fit in this picture, as the degree of improvement of a high level language compiled to assembler and machine language can't possibly be compared to java transpiled to javascript...


Agree that the level of abstraction is different...

Maybe one day JavaScript will become as manageable as TypeScript and Java ;-) Until then I prefer Java for professional products which need to be good maintainable... and for those JavaScript "speakers" TypeScript is a good way to make the apps maintainable...


... If you are coming from JavaScript is TypeScript surely much "nearer" than Java... but if you are from Java why not stay in Java (with transpiler)?


I come from both. I find that learning a new language is much less difficult than learning the new ecosystem. If I'm going to write front-end code, learning the front-end idioms is more effort than the differences between Java and Javascript. If I want to use somebody's widget from NPM I'm going to have to learn Javascript anyway.

That said, the best reason to continue to write Java is that I can share business objects between front and back end. That fact is what led to node.js, which is an abomination upon the earth. It's the worst of both worlds and yet its existence is inevitable. Similarly, I've been writing Javascript lambdas because that's what Netlify supports easily, and the horror overwhelms me.

I am so sorry Java didn't win on the browser side. In a slightly different world the JVM accessed the DOM natively, but in the end Javascript felt like "native" webapps to users where Swing and AWT didn't. In the end, that's what I wish to produce: apps that the users feel comfortable with, no matter what terrible language I have to do it in.


If you have to learn to use NPM, then it is really tough :-) Sofar I always use the available UI component frameworks (DominoUI, GWTBootstrap3, ...) and I never have to use NPM to download the JS libs, Maven only ;-)

Agree, that at the end the our target should be the users and they don't care about the technology you use in the implementation. But from my point of view, we also don't have unlimited resources. So it plays a role whether you have a full stack which you can use from client (web browser) to the server and this is where GWT / J2CL / Spring Boot have their "power".


Actually debugging on Web browser with sourcemaps is very easy and transparent, also with Java see this screenshot: https://miro.medium.com/max/1400/1*zeTE0robP4_HQ2gc6WAVUQ.pn...

Just the same as debugging in TypeScript or JavaScript.

Very comfortable...


The view on the right is obfuscated: you're looking at the Javascript names of the variables, not the original. If you want to use them on the console, you need to write Javascript, not Java.

Better is to use a native Java debugger[1], but there are still a lot of pitfalls.

[1] https://gist.github.com/hpehl/bd00b22586d0c75d37d5fe7f0cfcd8...


Thanks for the tip, I actually could always understand the variable names although they are not "original" ;-)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: