4 ms·

I think that its time that the enterprise switches to full stack Typescript as a much better solution for developing enterprise software. Why use two languages

by vfc1 8y ago

I think that its time that the enterprise switches to full stack Typescript as a much better solution for developing enterprise software. Why use two languages and two different ecosystems for the backend and for the frontend, when we can use only one? It makes hiring a lot easier too. Let's face it the Java ecosystem is stagnated and has lost a tremendous amount of mindshare in the last 7 years. The level of modularity that they are trying to achieve has been available in Node since 2009, while all the language features that they are trying to implement are already there in a Typescript in a much better form. The Java ecosystem did not manage to produce a good frontend development solution, and that was its downfall. Things like JSF and later GWT did not deliver on the promise of abstracting away the browser for non-frontend developers, and the result is that you have to be both a frontend developer (HTML/CSS/Javascript ) and a Java developer in order to build UIs in Java.

inglor 8y ago
> The Java ecosystem did not manage to produce a good frontend development solution, and that was its downfall. Most people writing Android apps are doing it in Java. The switch to Kotlin was as much about Sun and Google as it was about Java being outdated.
JustSomeNobody 8y ago
> Why use two languages and two different ecosystems for the backend and for the frontend, when we can use only one? Why use a hammer and a screwdriver when you could just use the hammer? Do people really make blanket decisions like this for their projects instead of properly evaluating what the project's actual needs are?
joncampbelldev 8y ago
A language with no built-in multi-threading capabilities is unlikely to suit every backend. Running multiple copies of the same lightweight process works quite well for stateless http interaction (request -> database -> response), but it's a lot of overhead to cross process boundaries every time you want to run something in another thread. I also have a question about the loss of mindshare. What new technologies are unaccessible from Java, but are accessible from at least 2 other languages (one of which is TypeScript / JavaScript)? A loss of mindshare would likely mean smart people aren't around to build libraries / integrations to the latest hotness. My background: Originally a Java developer, now mostly Clojure. Also a Javascript (mostly react) developer.
devman2 8y ago
Why Typescript and not just JS? Static typing for a dynamic language in a dynamic environment while using many npm libraries that can return anything unexpected? You'll need tons of testing to be sure. Typescript is highly overrated, proper testing makes the difference, not Typescript IMHO. Btw, Typescript is Microsoft, just as Github is soon, and I really having a hard time to get rid of the aversion I have for that company.
Darkstack 8y ago
>I think that its time that the enterprise switches to full stack Typescript as a much better solution for developing enterprise software. We use TypeScript for our frontend (Angular 5), I find it better than plain JS but the language has some weird paradigms, NPM is driving me crazy. Our backoffice is in C#, and i will never trade the safety of C# for TypeScript. >The Java ecosystem did not manage to produce a good frontend development solution, and that was its downfall. Agree. (haven't done Java since ages, but the support of java EE in GlassFish/Jboss/Tomcat was a mess too)

by vfc1 8y ago

inglor 8y ago

> The Java ecosystem did not manage to produce a good frontend development solution, and that was its downfall. Most people writing Android apps are doing it in Java. The switch to Kotlin was as much about Sun and Google as it was about Java being outdated.

JustSomeNobody 8y ago

> Why use two languages and two different ecosystems for the backend and for the frontend, when we can use only one? Why use a hammer and a screwdriver when you could just use the hammer? Do people really make blanket decisions like this for their projects instead of properly evaluating what the project's actual needs are?

joncampbelldev 8y ago

A language with no built-in multi-threading capabilities is unlikely to suit every backend. Running multiple copies of the same lightweight process works quite well for stateless http interaction (request -> database -> response), but it's a lot of overhead to cross process boundaries every time you want to run something in another thread. I also have a question about the loss of mindshare. What new technologies are unaccessible from Java, but are accessible from at least 2 other languages (one of which is TypeScript / JavaScript)? A loss of mindshare would likely mean smart people aren't around to build libraries / integrations to the latest hotness. My background: Originally a Java developer, now mostly Clojure. Also a Javascript (mostly react) developer.

devman2 8y ago

Why Typescript and not just JS? Static typing for a dynamic language in a dynamic environment while using many npm libraries that can return anything unexpected? You'll need tons of testing to be sure. Typescript is highly overrated, proper testing makes the difference, not Typescript IMHO. Btw, Typescript is Microsoft, just as Github is soon, and I really having a hard time to get rid of the aversion I have for that company.

Darkstack 8y ago

>I think that its time that the enterprise switches to full stack Typescript as a much better solution for developing enterprise software. We use TypeScript for our frontend (Angular 5), I find it better than plain JS but the language has some weird paradigms, NPM is driving me crazy. Our backoffice is in C#, and i will never trade the safety of C# for TypeScript. >The Java ecosystem did not manage to produce a good frontend development solution, and that was its downfall. Agree. (haven't done Java since ages, but the support of java EE in GlassFish/Jboss/Tomcat was a mess too)