[HN Gopher] TeaVM: Build Fast, Modern Web Apps in Java
___________________________________________________________________
TeaVM: Build Fast, Modern Web Apps in Java
Author : homarp
Score : 160 points
Date : 2021-01-31 11:34 UTC (11 hours ago)
(HTM) web link (teavm.org)
(TXT) w3m dump (teavm.org)
| CamouflagedKiwi wrote:
| > Its close relative is the well-known GWT
|
| The thing that is (somewhat) well-known for being an awful mess,
| which Google eventually realised and moved away from? Those who
| do not learn the mistakes of history...
| cromwellian wrote:
| Only the UI toolkit part was a mess. Google still uses Java to
| JavaScript compilation, through GWT's successor J2CL.
| flowerlad wrote:
| The hard part about WASM is passing data in and out. You can't
| pass JavaScript numbers, strings, arrays or objects, because WASM
| only understands bytes. Does TeaVM make this easier?
|
| Update: TeaVM does make it easier:
| http://teavm.org/docs/runtime/jso.html
| villgax wrote:
| Lol Java in 2020 for performance & that too with front-end? I can
| only imagine the wait-times between changes to source.
| MaoTheMeow wrote:
| Java is too slow. Just because modern hardware allows for
| software to be very heavy doesn't mean that it should be
| acceptable for you as a developer to produce heavy software.
| coldtea wrote:
| It's 2021. 1999 wants its arguments back.
|
| At the language/runtime level Java has been faster than
| anything else we have used on the Web with huge success (faster
| than PHP, Ruby/Rails, Python, Node, for example) even since
| 2000, and is as fast or faster than Go. It's also used in HFT -
| where ultimate speed means a lot.
|
| Seriously, your argument sounds like the first year CS student
| argument of yore, where they hear that assembly is faster, and
| want to rewrite everything in assembly (fortunately today's
| first year CS students are more well informed).
| gdubya wrote:
| It's 2021, but I agree with the rest of your post :)
| coldtea wrote:
| Damn, it's the second time I type 2020 past 1st Jan.
| oweiler wrote:
| Which type of slow?
| ta988 wrote:
| Don't engage just someone repeating the same FUD from 20
| years ago...
| patates wrote:
| I'm sincerely wondering how you came to that conclusion. Java
| has one of the fastest VMs, but maybe you mean the startup
| speed?
| throw2838 wrote:
| Slow startup from command line
| coldtea wrote:
| Which is relevant for a server how?
| forgetfulness wrote:
| This is on the comment thread of a tool to make client-
| side applications.
|
| However, it's all besides the point because this tool
| takes Java (JVM) bytecode and translates it to
| WebAssembly, there's no JVM involved for end users at any
| point.
| JAlexoid wrote:
| Is sub 100ms not enough these day?
|
| Sure... IntelliJ IDEA startup isn't instant. Atom's startup
| isn't instant. QT Creator's startup isn't instant. GIMP
| starts in a few seconds... etc.
| pjmlp wrote:
| All free JDKs now offer AOT compilers and JIT caches.
| pharmakom wrote:
| JVMs that most people use are optimised for repeated
| execution of the same code paths on long running processes.
| If this isn't your use-case then lots of tuning work is
| required.
| dukeyukey wrote:
| That fits the common Java use-case of servers and desktop
| applications. Not so much for Lambda instances or command-
| line tools, but Java isn't highly used there anyway.
| JAlexoid wrote:
| I don't know where you're getting this...
|
| Lambda instances run really well with JVMs(the whole COW
| memory architecture)... and even CLIs run well enough.
| pjmlp wrote:
| Like using the AOT compiler or JIT caches provided in
| recent versions, they are no longer features only available
| to customers of commercial JDKs.
| skjfdoslifjeifj wrote:
| The free AOT compilers have atrocious compile times (far,
| far worse than even Rust or Scala) and don't support all
| of the features so library support is extremely fragile.
| A lot of extremely popular Java libraries make extensive
| use of runtime reflection and none of the AOT compilers
| handle it well without a lot of extremely error prone
| manual configuration.
|
| I actually like Java and the JVM but if AOT compilation
| and efficient memory usage is what you want Java is
| definitely not the language to use.
| imtringued wrote:
| Yes, GraalVM requires a new sub ecosystem of libraries
| that are built with it's native image feature in mind.
| That means no more Spring, no more Hibernate and so on.
| Old codebases will not benefit and new code base require
| abandoning your existing Java expertise.
| skjfdoslifjeifj wrote:
| I agree. My main issue is with the Java zealots that come
| into the discussion and make it seem like anyone can just
| take their existing Java application and use it with an
| AOT compiler. The reality is that you will most likely
| have to make changes to your code, do a significant
| amount of configuration, and heavily modify or remove
| dependencies. Furthermore, you are isolating yourself
| from the huge Java community because very few people are
| using any of the existing AOT Java compilers.
|
| They try to paint an extremely rosy picture of the
| current situation when the reality is that it's a very
| long way from the experience you get in Rust, Go, D, C,
| C++, Haskell, Ocaml or any of the languages where AOT is
| considered the default.
| sitkack wrote:
| > main issue is with the Java zealots
|
| Any sufficiently large population will have someone who
| will literally say anything. And the common outrage trope
| on the internet is to rage against a straw man.
|
| Now I haven't used GraalVM in production, but in having
| played around with it and doing new code from scratch, I
| found AOT compilation to be really good.
|
| I think the change will come faster than you think.
|
| You can build your leaf, domain level code into a native
| shared lib and still use the reflective code at the top
| level to compose the application.
|
| https://www.graalvm.org/reference-manual/native-
| image/#build...
|
| If Java gets CTFE (compile time function evaluation),
| constexpr for C++ folks, much of the need for runtime
| reflection would disappear.
|
| There is no reason that JITed reflective code (along with
| VM) can't be combined AOT code in the same program. You
| can already do this in Graal via front ends for llvm-ir
| and wasm.
|
| As it is now, you can already mix Rust, C, C++ trivially
| with bytecode via LLVM ir. And for languages that compile
| to Wasm, GraalVM has a front end for that as well.
|
| https://www.graalvm.org/reference-manual/wasm/#embedding-
| web...
| kitd wrote:
| _If Java gets CTFE (compile time function evaluation),
| constexpr for C++ folks, much of the need for runtime
| reflection would disappear._
|
| Just to remind people that Quarkus has a "pre-compile"
| stage that allows code to wire itself up using
| reflection, annotations, config properties, etc, before
| the full compile. This makes start-up times much faster.
| pjmlp wrote:
| Thanks for the compliment, I deliver software solutions
| in Java, C#, JavaScript, TypeScript, Swift, Objective-C,
| C++.
| BoyRobot777 wrote:
| > no more Hibernate and so on
|
| Quarkus, Redhat's, native first frameworks works fine
| with Hibernate and GraalVM. One of contributors gave a
| [talk](https://www.youtube.com/watch?v=za5CSBX-
| UME&feature=youtu.be)
| pjmlp wrote:
| They work perfectly fine with JIT caches.
|
| Plus not everyone is fan of Spring and Hirbenate.
|
| The first I used only once in 20 years of Java projects,
| the second is the first to go away when I get called to
| optimise database performance in Java applications.
| pjmlp wrote:
| Hence JIT caches.
| hestefisk wrote:
| Slow is pretty relative. What's your use case? Start up time is
| not as good as native, agreed. Arithmetic? Hotspot is pretty
| darn fast. Developer speed? A lot better than C/C++ at least.
| karmakaze wrote:
| This idea of 'heavy' is very fuzzy, though I agree. Most of the
| slowness I encounter though is with specific frameworks, not
| the language/jvm.
|
| I do sometimes use Go for its contiguous memory layout and
| await JEP 169: Value Objects from Project Valhalla.
| skjfdoslifjeifj wrote:
| > Most of the slowness I encounter though is with specific
| frameworks, not the language/jvm
|
| Part of the problem is that those also happen to be the
| frameworks that the vast majority of the community uses.
|
| The Java zealots also tend to ignore all of the problems
| associated with AOT Java compilers and the fact that it will
| most likely be a few years before value objects are finalized
| and in a released version of Java. Even then, a ton of Java
| developers won't be able to use any features beyond Java 8 or
| 11 since a lot of companies don't want to give up the ability
| to easily use their libraries on Android.
| cangencer wrote:
| I'll do a shameless plug of our modern Java benchmarking story
| here for the doubters: https://jet-
| start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1
| speedgoose wrote:
| I complain all the time about the memory consumption of Java
| software, they behave like they are the only ones running on a
| computer, but not the speed. The JVM is actually pretty fast.
| For sure it's a bit slower than native code but if your Java
| code is slow, I'm sorry but it's your code and using C++, C,
| Rust or whatever else faster will not make your code fast.
| imtringued wrote:
| My biggest issue with the JVM is the RAM consumption. Every
| other language, even JS beats it. GraalVM's native image
| feature is the only way to fix this and that is pretty sad
| that it took them multiple decades to fix such a glaring
| flaw.
| KronisLV wrote:
| Yep, here are some sources to back up the claim that Java
| performance is pretty okay.
|
| TechEmpower benchmarks: https://www.techempower.com/benchmark
| s/#section=data-r19&hw=...
|
| Language benchmarks game: https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
|
| And just because i found it pretty interesting, here's a
| summary of a study that not only measures memory consumption
| and execution time, but also how much energy certain
| languages required: https://jaxenter.com/energy-efficient-
| programming-languages-...
| gman83 wrote:
| Yet we're all using Electron apps every day.
| pjmlp wrote:
| Yes, xcode is the living proof how blazingly fast an IDE
| written in native languages is. /s
| macspoofing wrote:
| Is this a Java alternative to Blazor?
| shannah78 wrote:
| Yes, you could describe it that way, I suppose. TeaVM is just
| the "VM" part of it. The developer has a "sister" project
| called "Flavour" that provides a UI framework.
| https://github.com/konsoletyper/teavm-flavour
| comick wrote:
| Forget about web development for a second.
|
| TeaVM is primarily a JVM byte-code to JS (and WASM, and plain C
| code) compiler. It is so effective at this, that not long ago I
| was able to bring a byte-code only proprietary JVM library to the
| web and it just worked. This thanks to an almost complete
| classpath library (based on Apache Harmony) and a macro system
| [1] that allows to produce POJO to JSON conversion code at
| compile time.
|
| [1] http://teavm.org/docs/runtime/metaprogramming.html
| svrma wrote:
| How does Java pricing work these days (after being bought by
| Oracle)?
| skizm wrote:
| Every seems to be being snarky, but on the off chance you care
| about the actual pricing, and assuming you're talking about
| Oracle's JDK and not OpenJDK: Oracle's JDK is free to use. You
| can pay for support if you want, which gives you the bleeding
| edge security patches immediately (without support you can
| upgrade every six months to get the all patches). The pricing
| for support is calculated by CPU core count I believe. So if
| you're using Java in production on 100 cores, that's going to
| be more expensive than 10. I don't have the specific numbers
| off the top of my head though.
| andylynch wrote:
| It's worth pointing out that with Oracle's new Java licensing
| model whether something is free on charge depends on a number
| of things including how Oracle thinks it's being deployed.
|
| The Oracle JDK is indeed free of charge for developing
| aplications, _but_ running that app using Oracle Java on a
| server as opposed to a desktop needs a paid license
| subscription & generates exposure to Oracle license audits.
|
| Many, many firms are now using OpenJDK and the like, and have
| policies against even downloading Oracle's version.
| svrma wrote:
| I was not trying be to snarky. I was genuinely curious to
| know how it is priced after the oracle acquisition. As a
| language that I am most used to, I wanted to evaluate how
| much it'd cost (a rough estimate based on cores/users) if I
| were to launch a web service based on Java.
| JAlexoid wrote:
| Since Java is free to use and is primarily developed as a
| GPL software - there are no licensing costs, that you would
| care about.
| andylynch wrote:
| Not if you want to use Oracle's JVM to run something on
| anything but a laptop or desktop. They will absolutely
| want you to pay for that and will make sure you do.
| andylynch wrote:
| Oracle actually publish their price list for Oracle Java
| here - https://www.oracle.com/uk/corporate/pricing/#java-se
|
| In short, starts at $25 per processor per month, discounts
| starting at 100+ . Look at using OpenJDK/ Amazon Corretto
| instead
| ternaryoperator wrote:
| OpenJDK is Oracle's free, open-source implementation of the
| Oracle JDK. It is where Oracle does all of its JDK
| development. You can use it with no restrictions. If you
| want to pay for support, you can pay Oracle or any of
| several other companies that package up and support the
| OpenJDK. If you choose to pay Oracle, you'll get the Oracle
| JDK which is identical to the OpenJDK except for a couple
| of error messages and the ID string.
| Tomte wrote:
| You can use OpenJDK (via adoptopenjdk, Redhat or many others)
| and it's free.
|
| Or you pay Oracle for support. Or some other company.
|
| Oracle isn't special.
| coldtea wrote:
| Well, on the other hand OpenJDK is 99% Oracle's work
| repackaged.
|
| If Oracle decided to stop putting out new FOSS-licenced
| versions, there would be no new OpenJDK releases (since all
| the core Java devs are Oracle employees).
|
| So it's like a no-community project, where you get a dump of
| FOSS code every now and then from a vendor.
| JAlexoid wrote:
| A correction - all the core Java developers are paid by
| Oracle to develop Java. I doubt that Oracle would win
| anything, by abandoning OpenJDK.
|
| And now - they can't. Companies that are able to maintain
| Java are X times larger than Oracle and the core team would
| easily be rehired by IBM, Google, Aamazon, Facebook, Apple,
| etc...
| geodel wrote:
| None of the companies you listed would gain much over
| current model. They would rather move to different
| technologies in case Java is abandoned.
|
| > Companies that are able to maintain Java are X times
| larger than Oracle
|
| With exception of maybe IBM which anyway is crapping out,
| none of the other owe their business success to directly
| to Java based product or services. If Java were to be
| abandoned they can easily migrate / rewrite their
| internal tools / products to a different platform even if
| it takes 5-10 years. It is not like current prod systems
| will stop working just by announcement.
|
| Also to think further Oracle abandons Java , Amazon and
| Google would have huge incentive to either charge lot
| more for Java on cloud or redirect their customers to
| alternatives.
| hocuspocus wrote:
| In recent Java versions, there's roughly 20% of external
| contributions:
|
| https://blogs.oracle.com/java-platform-group/the-arrival-
| of-...
|
| Oracle seems to pursue GraalVM EE as a way to monetize
| Java. It would be insane for them to change the license,
| piss off companies with deep pockets, risk a hard fork and
| see most employees working on the JDK leave.
| coldtea wrote:
| > _In recent Java versions, there 's roughly 20% of
| external contributions:_
|
| Have to check your link to find out, but is it by number
| or by impact?
|
| (Asking cause many projects have seemingly many "external
| contributors" but if one looks almost all real work
| happens by a core team, and the external contributors
| just do some change here and there, or even clerical
| work, like fixing comments and documentation and such).
| rpdillon wrote:
| The post measures by issue count, though not all issues
| are equal.
|
| > Of the 2,136 JIRA issues marked as fixed in Java 15,
| 1,702 were completed by people working for Oracle, while
| 434 were contributed by individual developers and
| developers working for other organizations.
| exabrial wrote:
| Free forever. It's open source.
| pjmlp wrote:
| After being rescued by Oracle, after all no one else wanted to
| buy Sun, not even Google (hoping it would just sink most
| likely).
|
| Java is as open source and still has multiple implementations
| available, even Microsoft is now a Java vendor (after having
| bought jClarity).
|
| Basically you want free beer like Linux? Get a distribution
| from OpenJDK.
|
| You want support Red-Hat/SuSE style? There is Oracle, and a
| plenty of other vendors happy to sell JDKs with support.
| pwdisswordfish5 wrote:
| > Basically you want free beer like Linux? Get a distribution
| from OpenJDK.
|
| After the Oracle lawsuit, why should people feel safe
| believing that Oracle will respect the terms of the license
| instead of trying to extract more money and subject you to a
| costly lawsuit?
| JAlexoid wrote:
| Oracle's lawsuit was for modifying the license.
|
| GPL with Classpath exception covers you well enough.
|
| Google skipped on the GPL license, so they don't get the
| benefits of that license.... unlike all Java users.
| pjmlp wrote:
| The same way they felt safe after Sun won over Microsoft.
| tw25980549 wrote:
| ... what? That's a non-answer.
| pjmlp wrote:
| Sure it is, Android Java === Google's J++, and the hammer
| shall fall just as hard.
|
| Google had the opportunity to own Java, decided it wasn't
| worth the money, so now they should suffer the long due
| penalty.
| tw25980549 wrote:
| That's still not an answer. You're avoiding the question
| and... I don't know, answering some other question that
| no one asked, it looks like.
|
| If a company has the option between OpenJDK and its
| "free" license or paying Oracle for a different license,
| why would anyone feel safe choosing the former, given
| that when you deal with Oracle, you deal with the risk of
| wasting as much money or more to defend yourself in court
| than the price of Oracle's paid option? Open source
| licenses are only as good as as the belief by the
| licensing party that the terms of the license mean
| anything.
| pjmlp wrote:
| My dear, Oracle SDK == OpenJDK + JFR license + support.
|
| If you don't want to give money to Oracle, there are
| plenty of other companies to choose from, including
| Amazon, IBM, Microsoft, Alibaba, SAP, Azul.
| tw25980549 wrote:
| Once again, you have avoided the question (although
| you've spiced it up this time with some additional
| condescension).
|
| You listed OpenJDK as a viable "free" option. Defend it,
| or don't, but stop trying to pivot the conversation while
| pretending that changing the subject is a valid answer
| answer to the thing that was asked.
| krisgenre wrote:
| AFAIK IBM did want to buy Sun but backed out because of
| potential antitrust reviews.
| pjmlp wrote:
| Indeed, and no one else, specially not Google.
| macspoofing wrote:
| >After being rescued by Oracle
|
| Java was not rescued by Oracle. There was never any danger of
| Java going away or not having a proper sponsor. If anything
| was 'rescued', it was the SPARC/Solaris division of Sun.
| ksec wrote:
| At the time, and that is still the case today, Sun / Oracle
| was the single largest contributor to the Java Ecosystem.
|
| Java will surely live but will it thrive without all those
| investment?
| pjmlp wrote:
| Sure, where are the post Java 6 FOSS contributions from the
| community, if I may ask?
| tezza wrote:
| Amazon Corretto - Free
|
| Java 8,11 supported by a big firm (Amazon)
|
| https://aws.amazon.com/corretto/
| svrma wrote:
| Thanks! I haven't heard about this.
| themaninthemud wrote:
| Maybe having a SSL cert would made it more presentable for a web
| framework. Maybe
| chrismorgan wrote:
| I have Firefox's "HTTPS-only" mode enabled. teavm.org is only
| served on HTTP. This gave me a rather bad first impression of a
| thing for making modern web apps--TLS is table stakes that you
| should _never_ be without.
|
| (I tend to find something HTTP-only about once a day, normally on
| sites that have been around for over ten years. Normally I'd just
| shrug if it's a content site, but this being for making web apps,
| I figured it was worth commenting on.)
| josho wrote:
| Tell me again what the threat mode TLS protects against for a
| marketing site?
|
| The only thing I can think of is my ISP injecting some HTML at
| the top of the page. Something that I haven't seen for years.
| nayuki wrote:
| Letting the ISP inject stuff _is_ the threat model, and it
| has happened in real life. https://www.theregister.com/2015/0
| 3/27/github_under_fire_fro...
|
| Every connection that happens over unsecured HTTP is a
| connection that can be hijacked by middlemen for nefarious
| purposes, both for spying and for attacking.
|
| Encrypting as many connections as possible is a form of herd
| immunity. Encrypting even unimportant "marketing" websites
| protects everyone on the web by raising the cost of
| interception and lowering the benefits.
| jtheory wrote:
| 100% yes.
|
| It's also about the entire internet & its users, not just
| threat models on specific sites.
|
| We can't ask the general public to consider threat models
| and _evaluate_ what sites should need HTTPS or just HTTP.
| General, non-technical intuition is basically useless for
| this eval; it 's not a good path.
|
| It's much smarter to just make HTTPS the default, make it
| easy & free for any site to provide it, and then let
| browsers show big warnings for any site that's not secured.
|
| (Browsers are moving this way already)
| ev1 wrote:
| My ISP injects HTML and scripting onto the page (US).
|
| In many countries MITMing your page and replacing its
| contents, or using it to serve malware to targets is a
| frequent case.
| dariosalvi78 wrote:
| Java applets reinvented
| jtheory wrote:
| Nah.
|
| Java applets involved running an actual JVM on every client
| computer, which meant basically doubling the risk surface of
| the browser... plus you had a completely different UI (that
| couldn't match the browser UI) sitting inside a web page.
|
| I confess I wrote a bunch of Java applets back in the day; but
| I can't say I'm surprised they died, and I don't think they'll
| be back.
| abiro wrote:
| How does this compare to Google Web Toolkit?
| phpisatrash wrote:
| > _without the difficulties of a JavaScript development stack._
|
| Yes. It's very difficult to write a full stack application using
| JavaScript. I cannot find tools or frameworks.
| dexterdog wrote:
| Finding them is not the problem. Figuring out which one to use
| is.
| speedgoose wrote:
| I don't know whether it's sarcasm or not.
| throwaway-42808 wrote:
| The frameworks and tools aren't all that stable, reliable, or
| intentionally designed compared with what Java programmers
| might be used to. I don't fault anyone for trying to get off
| the bus.
| isbvhodnvemrwvn wrote:
| I don't see how using TeaVM, which is not stable at all, has
| very little activity (a handful of commits since summer) and
| is going to be extremely niche since most people don't have
| that weird aversion to modern JS tooling, is a solution.
| forgetfulness wrote:
| Is JS tooling less of a Rube Goldberg machine nowadays? I
| remember that the people I knew who got into it but not fully
| used to use these humongous auto-generated boilerplates that
| glued together webpack, gulp, babel, had build processes
| involving native dependencies that would fail with weird
| errors vaguely related to Node JS versions, and this all to
| develop in the frontend.
|
| Compare: Clojure. You have the project.clj file and put your
| dependencies there. The you do lein run or build a fat jar
| and run it like java -cp your.jar your_app.core. The end.
| gdubya wrote:
| Not really (any less). A couple of years ago we migrated a
| project from Spring + GWT to Spring + Vue. The Vue part is
| nicer, but everything around it feels messy. The team is
| primarily backend / java developers (we had a frontend
| expert at the time too), but we felt that the JS frontend
| part shouldn't be that hard to master. Maybe Vaadin would
| have been a better option after all?
| yepthatsreality wrote:
| No it's even more so with the rise of framework frameworks
| like Next.JS and Cypress. These frameworks are just
| wrappers around other frameworks. JS will never escape this
| as its primary reason for existence was a glue layer
| between Browser and HTML/CSS.
| nicoburns wrote:
| I've yet to see a single professional software company
| use these eztra layers. Though there are no doubt some
| most people are still using React, Vue or Angular
| directly.
| aphexairlines wrote:
| Here are a few software companies moving to next.js.
|
| https://nextjs.org/case-studies/hulu
|
| https://nextjs.org/showcase/uber
|
| https://eng.lyft.com/changing-lanes-how-lyft-is-
| migrating-10...
| dmingod666 wrote:
| After all the shebang out comes an html with tables instead
| of divs.
| michaelcampbell wrote:
| divs + css in yet another file, you mean. Tables at least
| do something in and of themselves; divs do not.
| nicoburns wrote:
| Thw humungous auto-geberated boilerplates are rude goldberg
| machines. But you don't need those at all. A simple webpack
| config (including setting up babel, typescript, etc) is
| less than 100 lines (not nothing, but comparable to build
| scripts in other langauges).
|
| It's worth noting that there is some inherent complexity in
| the web platform due to the fact that you are generally
| targetting multiple platforms. Server side code has it easy
| here (and indeed Node.js generally needs little in the way
| of build process)
|
| Regarding error with native NPM dependencies (usually when
| switching node versionw, or switching between macOS node
| and linux node in docker): this can almost always be solved
| witha simple `npm rebuild` once when you change node
| version.
| holoduke wrote:
| Come on. Even if you dispise the js world, plenty of examples
| of well written JavaScript frameworks and successful end user
| products.
| throwaway-42808 wrote:
| Sounds easy enough: Use the well written frameworks as
| needed, and you can make successful end products too.
|
| What would be your advice to someone seeking to do this?
|
| e.g. - is it simply a matter of intelligence, perseverance,
| attitude? - is there a technical or social practice you
| find helpful?
| pjmlp wrote:
| My last four projects, changed from Angular 6 and Ionide, just
| Angular 6, followed by Vue.js, now doing one with React.
|
| Who knows what the FE team will remember to come up on the next
| assignment.
| bestinterest wrote:
| Soon it may be Svelte for me as it simplifies the React data
| model for me a lot... But there goes all the ecosystem again
| for React/Angular/Vue libs and docs. Then we repeat until
| someone figures out a better way to develop on the web (aka
| whats after Svelte?).
|
| I'm hoping https://hotwire.dev/ solves some of my issues, I
| hope to see it picked up in SpringBoot/Quarkus community
| more.
| marktangotango wrote:
| I used to work at a large F500 corp and managed a legacy app
| that used raw js/jquery on the front end. Every two years
| like clockwork we'd get a mandate that "all apps will now use
| X" where X was [ext-js, ember, angular]. As the person in
| charge of the app I ignored all those directives and saved
| myself a boatload of work. App is still using jquery today
| last I heard.
| dmingod666 wrote:
| Genius
| pwdisswordfish0 wrote:
| Why does everyone keep lumping jQuery in with vanilla JS,
| in exalted reverence, as if jQuery wasn't a massive source
| of bloat during its heyday? The practice of pulling in all
| of jQuery just to add an event listener for showing and
| hiding a div is _why_ web development looks the way it does
| today. Normalization of deviance is the vehicle, and jQuery
| was the payload.
|
| I come across stuff "only" using jQuery today, and every
| time, I end up ripping it out because it's totally
| unnecessary and often ends up being the _source_ of
| breakage and logic errors. What 's worse is that its APIs
| are awful, and it's impossible to debug in its blob form.
| The fix always ends up being to just get rid of it.
| JAlexoid wrote:
| That's not the point of the comment above.
|
| FYI: The point is that every year or two you get a new
| "revolutionary" framework. Unless you're working full
| time on FE - you're not going to be "in with the cool
| kids".
| SamoyedFurFluff wrote:
| I don't think this is the definition of difficult the author is
| using. I find JavaScript intimidating and difficult due to too
| many tools and frameworks. I cannot rely on any of their
| documentation, either on their site, or the peripheral
| collective experience of stack overflow, to be accurate to the
| actual thing I'm trying to use. This makes it difficult to me.
| SomeHacker44 wrote:
| The obvious way to me for full stack JavaScript is to use
| JavaScript on the server with node.js and JavaScript on the
| client via a... Browser.
| franklampard wrote:
| the word GWT gives me PTSD
| manishsharan wrote:
| How big is the js for ToDoMVC generated by TeaVM ?
| exabrial wrote:
| This is pretty danged slick. I especially like the API to create
| your own components very intuitive.
|
| One rotten egg I can spot: "Supported subset of Jackson". Ow.
| Jackson is unfortunately a land mine, rattled with CVEs over the
| years. This was mostly fixed by taking the best ideas from
| Jackson and standardizing them as JsonB, which not have several
| good implementations. I would highly suggest they drop Jackson
| support in flavor of JsonB just so the Jackson libs don't have to
| be on anyones class path.
| willvarfar wrote:
| Any more details? A quick googling doesn't find many talking
| about comparative performance and security of Jackson vs jsonb
| vs gson?
|
| Have seen Jackson in parts of my code base (internal, but
| still)
| jillesvangurp wrote:
| These 3 issues basically.
|
| https://www.cvedetails.com/vulnerability-
| list.php?vendor_id=...
|
| As Jackson is used in Spring, you can assume most banks, big
| corporations, etc. use it. So, update your dependencies and
| it's fine.
|
| Gson is kind of to be avoided for the simple reason that it
| seems to be no longer maintained by Google. I've used it in
| the past and its fine but wouldn't pick it for something new
| because of this.
|
| If you are using Kotlin, kotlinx serialization is worth a
| look. I've been using that recently. One of the nice things
| is that it relies on compiler plugins and code generation
| rather than a lot of reflective magic at runtime. From a
| security and performance point of view, that's a good thing.
| abeppu wrote:
| Anyone who has actually tried this have any comments?
|
| I think it's interesting that they seem to position themselves as
| an alternative to programmers of jvm languages needing to switch
| to javascript for browser-side work, but they don't make a clear
| comparison to eg scala.js or kotlin js, where js code is
| generated, but not from class files.
|
| I've tried playing with those, and one source of challenges is
| working with js libraries, which need some wrappers expressing
| method signatures, which is sometimes a challenge. TeaVM has a
| bunch of annotations for js interior, as well as the ability to
| deal with js code as just strings. But I can't see that it
| clearly solves the issues I find most annoying about scala.js or
| kotlin js. Is this only a great fit if you're in a polyglot jvm
| team that also wants to run that code in the browser?
| pojntfx wrote:
| I've used it because my uni still forces us to use Java
| (https://github.com/alphahorizonio/jnebulark) but the
| experience hasn't been that great for the actual framework
| (bindings are way to hard to do; I haven't found a way to do
| Promises yet, see https://github.com/alphahorizonio/jnebulark/b
| lob/main/src/ma...). In general, docs are lacking quite a bit
| as well (you have to use the development version for most
| things now, which isn't in sync with the docs). We just took
| the sane route, wrote the backend in TypeScript (and ported to
| Java for Uni), and used React for the frontend. The WebAssembly
| support of TeaVM is fun to use for small modules though, we
| integrated it into a WIP project:
| https://docs.webnetes.dev/getting-started/develop/java.html
| shannah78 wrote:
| "I haven't found a way to do promises yet". TeaVM provides
| Java wrappers for most JS APIs, including promises (https://g
| ithub.com/konsoletyper/teavm/blob/master/core/src/m...). If
| you require an API that doesn't have a wrapper yet, it is
| dead simple to create your own wrapper. Or just use the
| @JSBody annotation to write your own ad-hoc Javascript.
| shannah78 wrote:
| > Anyone who has actually tried this have any comments? I
| manage a Java/Kotlin WORA toolkit called Codename One that
| deploys to all the major platforms (iOS, Android, Windows, Mac,
| Web, etc..). We use TeaVM for our web platform, and it has been
| fantastic. It was the first solution to provide support for
| threads in JS. (i.e. Your java programs can use
| synchronization, and they will work properly when deployed to
| the web).
|
| The performance is very good (we tried other options to get a
| web port working before we found TeaVM, and none could
| compare).
|
| The developer is responsive to bugs - but it has been rock
| solid for us. At this point the JS port is one of our most
| stable platforms.
|
| The development environment is also nice to work with. I work
| with all of the native SDKs that we deploy to, and TeaVM is my
| favourite. In particular, the JS<->Java interop is smooth and
| easy with minimal boiler plate. On most platforms, using a
| native API is at least a little painful - with some boiler
| plate necessary. On TeaVM it has annotations to be able to
| "drop into" javascript without a lot of fuss.
| jillesvangurp wrote:
| TeaVM is nice if you want to bring existing Java code depending
| on the Java standard library to a browser. Kotlin-js does not
| do that. You only have the Kotlin standard library if you
| target kotlin-js (well plus all the multiplatform stuff that is
| getting released lately). Multiplatform is the reason why this
| is getting interesting. There are a lot of good quality
| libraries that just work on kotlin-js now.
|
| I've been using kotlin-js lately for browser development (with
| the Fritz2 framework). It's fine and improving rapidly. Just a
| year ago, this would have been a bit of a rough experience
| doing anything with it. But I've been using it since two months
| and have not really encountered any major issues. The Kotlin
| 1.4 release really improved things. And we indeed have a lot of
| Kotlin code for Android and our server so that made that an
| easy choice for us.
|
| It's early days for WASM and languages like Kotlin and Java but
| I'm guessing that a lot of stuff is going to happen there in
| the next years. In the end you need more than a compilation
| target: you also need platform integration, development tools,
| and libraries. Kotlin-js is getting pretty nice for each of
| those and with all the multiplatform stuff coming out, you
| don't really need or miss a lot of the npm stuff. But if you
| do, it's fairly easy to deal with that as well (e.g. we
| integrated leaflet just a few weeks ago).
|
| WASM support in Kotlin is still pretty immature. They recently
| kicked off an effort to improve support for that in the
| multiplatform gradle plugin. But there's still a lot of work to
| be done there. But, long term, I'd expect to compile to that
| rather than to Javascript.
| paulgb wrote:
| To piggyback on your request from someone who's tried it, I'm
| also curious about how this deals with the fact that Java is
| garbage collected but wasm (in itself) is not. Did they
| actually port a GC to wasm, or do they work around this in
| another way?
| shannah78 wrote:
| The WASM port is experimental. The Javascript target produces
| better performance. For JVM languages it will always be the
| case that the Javascript target performance better than the
| WASM target, mostly because of GC. For the WASM port the
| developer wrote his own GC.
| pjmlp wrote:
| Targeting WASM is just like targeting a CPU, most of them
| also don't have hardware support for GC algorithms.
|
| Most anti-GC FUD regarding WASM and GC kind of stems from
| people not getting how GCs are implemented.
| [deleted]
___________________________________________________________________
(page generated 2021-01-31 23:01 UTC)