Search Hacker News by keywords, user, score, etc.
Subscribe to new search results by RSS or JSON

Location: Boston, MA

Remote: Yes

Willing to relocate: No

Technologies: I'm a product marketing executive and not a developer or admin but have gotten hands-on with vSphere, Azure, AWS, Kubernetes and languages like Python, RoR, Angular, bash, PowerShell

Resume & Email: see profile

Spent 6 years in Marketing at a B2B software startup then another 4 years after that helping integrate the startup after acquisition by large-cap public company. Now I'm looking to get back to a startup and lead/build a product marketing function for folks solving interesting problems. Reach out if you need a tech-savvy marketing leader focused on messaging & positioning, GTM strategy, competitive intelligence, content, and enablement.

Location: Nebraska, USA (currently working remotely for Oracle)

Remote: Yes, also open to hybrid/in-office

Willing to relocate: Yes, to SF or Seattle

Technologies: Java, Terraform, C#, .NET, Angular, TypeScript, SQL

Résumé/CV: https://buckcronk.com/resume/

Email: early.clay7910@buckcronk.com

Hi! I'm Buck, a software engineer with 6 years of experience building cloud services and enterprise web apps, and I'm looking for my next backend or full-stack role, with an eye towards moving West. At Oracle, I currently work on a serverless function for generating documents (https://docs.oracle.com/en-us/iaas/Content/Functions/Tasks/f...), which has been fascinating, as I've gotten to learn the internals of the DOCX and XLSX formats while also using Terraform and custom tooling to deploy and maintain the product in dozens of cloud regions. Before this project, I also worked on the Database Tools Service (https://www.oracle.com/database/tools-service/), a cloud service for creating reusable database connections and executing SQL, helping to integrate with internal platforms, maintain the service, and deploy it to many regions. In general, I'm known for solving problems thoroughly, maintaining high standards in development and reviews, and helping out teammates and customers whenever I see the opportunity. If any of that sounds interesting to you, I would love to hear from you!

SEEKING WORK | EU | Remote | Senior Front-End / Full-Stack Developer (Angular, React, Next.js, NestJS, Tailwind, TypeScript) with 9+ years of experience in EU/US startups and enterprises (fintech, e-commerce, KYC, green-tech). Front-end/UI focused but full-stack capable. Built and launched products end-to-end — including AI-powered SaaS. Thrive in async-first, remote teams; comfortable with EST hours.

  Location: Prague, Czech Republic (EU)
  Remote: Yes (preferred)
  Relocation: No, but open to occasional office visits
  Tech: TypeScript, Angular, React, Next.js, RxJS, NgRx, SCSS, Nx, NestJS, NativeScript, Tailwind, CI/CD, REST, MongoDB, PostgreSQL, Jest, Figma
  APIs: Stripe, OpenAI, AssemblyAI, Deepl, Discord, Twilio, etc.
  Email: oletrn@gmail.com
  Résumé/CV: https://www.linkedin.com/in/otyurin/

Venture-minded Product Lead / Technical Product Manager with 9+ years in SaaS and full-stack development (TypeScript, Angular, React, Next.js, NestJS). Experienced in bridging business and engineering, launching 0→1 products, and integrating AI into real-world workflows. Multilingual communicator (English, Russian, Japanese, German, Czech). Seeking opportunities in async-first, remote teams.

  Location: Prague, Czech Republic (EU), comfortable with EST overlap
  Remote: Yes (preferred)
  Relocation: No, but open to occasional office visits
  Focus: Product leadership with technical depth — bridging business and engineering, aligning stakeholders, translating vision into clear product roadmaps, and guiding SaaS development.
  Tech: TypeScript, Angular, React, Next.js, NestJS, Tailwind, Nx, CI/CD, MongoDB, PostgreSQL, Docker, AWS, Heroku.
  APIs: Stripe, OpenAI, AssemblyAI, Deepl, Twilio, Slack, etc.
  Product: Jira, Miro, Notion, Prototyping, Wireframes, Figma
  Résumé/CV: https://www.linkedin.com/in/otyurin/
  Email: oletrn@gmail.com

Location:Atlanta, GA Remote:Yes Willing to relocate: No Technologies:Java, SQL (SQL Server Management Studio), JavaScript, Angular, HTML/CSS, Git, VS Code, IntelliJ, Rider, Postman, Chrome Developer Tools, Jenkins Résumé/CV:https://acrobat.adobe.com/id/urn:aaid:sc:US:3f318ca5-362e-41... Email:kiarra.gibbs@gmail.com

Detail-oriented QA Engineer with 4 years of experience across QA, product consulting, and technical support, specializing in both manual and automated testing. Achieved a 28% expansion in regression coverage and reduced API defect leakage by 22% through WebdriverIO automation, Postman validation, and CI/CD integration. Proficient in Java, SQL, JavaScript, Angular, HTML/CSS, and tools like Jenkins, Git, and Chrome DevTools, I bring technical versatility and an automation-first mindset. I’m eager to apply my expertise in test automation, defect management, and agile development to drive software quality at scale.

in a decade+ old fintech monorepo w/ microfrontends + BFFs + mixed stacks/design systems (react, angular, express, apollo, chakra, tw) the cruft builds up fast.

every time we migrate stuff (like the recent shift to next.js), old apps/libs don’t always get cleaned out. after years and years it’s an npm landfill. knip was basically the bulldozer.

Let us know when Kotlin Native finally becomes Kotlin Virtual Machine.

Big words matter, because there is a whole list of megacorps that rather keep using Java alongside C and C++ to implement their JVMs.

If Kotlin is so great where is the KVM taking over the world, outside ART, when no one is forcing its adoption like on Android?

Actually, is Kotlin Native finally good enough for JetBrains to implement a KVM, without having to rely in something writen in Java with all the related flaws?

I use Typescript where it is imposed upon myself, like Angular and Next.js, when I can have my way of Web development, it is plain Spring MVC or ASP.NET MVC with vanilajs.

Everything has a "day and age".

I'm not saying COBOL is a bad language, far from it, which the billions of lines of code running production proably also attests to. The first COBOL program i ever edited, in 2008, was last edited in 1987. It had run flawlessly every day for 20 years. COBOL when invented was invented to allow business people to express business logic programatically, which is also why it has such a large footprint in finance, insurance, etc.

I'm not saying Java is a bad language either. Java is great, much like COBOL was, and like COBOL, Java still evolves today. It has flaws, but so does every other language, and most of the flaws in Java are understood. There is literally also nothing you can't do in Java that you can do in <insert fashionable language of the year>.

We probably shouldn't write web frontends in Java, and most people figured that out a decade or more ago, including the financial institutions.

The typical flow in a financial institution is something like "Angular (in some form) => Java Backend => COBOL on mainframe => DB2", where "=>" can be anything from REST to message queues (i was tempted to write MQ, as most will likely be IBM MQ, but others exist and are used).

Most companies migrating away from mainframe (and thereby often COBOL), have also started implementing microservices instead of giant monoliths, which is what has kept the mainframes of the world running for so long. Most companies i've worked with, have had 45,000 - 90,000 COBOL programs running every night, with almost as many running on demand, and each and every one depends heavily on the output of the previous part of the chain.

Thost giant chunks are now being migrated to microservices with well defined couplings, meaning that when it eventually becomes time to migrate away from Java, it will be somewhat easier as you can eat the elephant one mouthful at a time, and not have to reimplement 50+ years of legacy code and conventions in one go.

I've said it before, and will gladly say it again, if you choose a COBOL career today, you will most likely never be unemployed for long until you retire.

First, there's an open PR for support for local models: https://github.com/angular/web-codegen-scorer/pull/17

Second, I can't say for sure this time, but the Angular team has been using emojis to lighten up bullets before AI generated became a thing.

(Disclosure: I work with the Angular team)

No way to measure it directly, but it did write 4kLOC of mostly working angular... whether non-max would manage the same feat in the same time is an open question.

I worked with large React and large Angular (1 and 2+) codebases. I even migrated projects between them.

I genuinely don't understand how Angular is considered simpler than React.

Both have a build step. React hasn't needed a "generator" for years now (if you mean stuff like CRA). With tools like Vite or RSBuild, it's like 2 lines. Yeah, the JSX needs to be compiled, but so do templates, custom CSS dialect, and TS's old/non-standard decorators in Angular.

Angular has way more quirks and reactivity foot guns than React. I think major React adoption painpoint is hooks, but while they are clunky, they're way "easier to hold" than most Angular tools.

Same when it comes to state management libraries in angular, but I digress.

Java / Spring Boot + Angular is a very common stack i.e.

React is not huge. It’s just a library that converts strings to tags. Oh you want to use React? You want JSX — the only use case for the React library? You want routing and URLs and history and state management and … ok you don’t want a virtual DOM but you need it. And you need Babel and a build tool and a generator framework (because piecing it all together is too hard) and tree shaking and CSS (in JS!) and lots of weird and complex lifecycle hooks.

React is both bigger (in terms of bytes) and more complex than Angular.

So, to answer your question, React is more complex than just about everything. I’d like to see you find a more complex framework.

I have been using the Umbraco CMS since 2013, and they moved from AngularJS 1.x to Lit for the backend technology. While it was frustrating at first, due to a lack of documentation around the specific CMS APIs, I can see that it was a great choice to move towards a more "standard" technology that is somewhat agnostic of a full library. Working with web components makes so much more sense to me than the way AngularJS works, as well as the React and Vue tutorials I've followed. If I found a killer feature implemented in React or Vue, I could still make use of my Lit web components without having to toss out everything and rebuild.

> Author claims to have been around for 17 years, doesn't have a single project of note and makes naive claims.

Plenty of such people out there.

This guy appears to just personally dislike Rust for reasons undisclosed and tries to rationalize it via posts like this one.

It's like with this former coworker of my former coworker who was really argumentative, seemingly for the sake of it. I did some digging and found that his ex left him and is now happily married.

Turns out that when he was criticizing the use of if-else in Angular templates what he was really thinking about was "if someone else".

Ah, the good old squeak/smalltalk days. A few years back I worked on signals (or rather a static analyser for the editor to support signals) in squeak/smalltalk. The kind of signals those indie frameworks like angular and svelte now adopt trying to solve the problem of changepropagation you outline in your paper.

What i'm getting at is: For the places where other tools are better (like the UI example), we already have other tools (signals, observables, effects, runes,...). And for the places like client/server-communication: This is kind of where "call/return" usually shines.

Why anyone would choose to use the Razor syntax at any time is beyond me, let alone for the web. There is no need to make it so complicated, HTML is interpreted.

As the article says :

> HTMX leaves it up to the developer to impose discipline on their code, however they see fit.

He said that like it's a bad thing. I really dislike those frameworks like Angular for example who simply say "You need to do it the Angular way". That just slows down innovation or clever ideas that solve little problems. Instead if there is a slow framework (looking at some peoples react implementations, Cloudflare recently) Well you probably wont consider it or just see it as a "quirk" of the framework.

Google says ~1.5x-1.7x, which would be the same factor for the angular density.

> That is some out of the box thinking!

Thanks. I'm just parroting some lines I read a decade or so ago on a website that I didn't manage to dig up again. (I wonder if it's still online?)

> I would say the key thing with Mercury is the ability to dig fast.

Why? What are you afraid of?

First, night lasts 88 (earth) days on Mercury. So if you start digging at dusk, you have plenty of time.

Second, Mercury's daytime surface temperature is around 430C (~ 800F ~ 700K). We have plenty of materials, like steel, that can withstand these temperatures easily. Even aluminum only melts at 660C.

So you make a parasol out of steel and span it over your equipment. Important: you make the parasol just big enough to shade your equipment, but otherwise let it see as much of the sky as possible.

Mercury has no atmosphere. So during the day you normally have a small patch of the sky at around 5772K, the sun. The sun has about ~6.6 times the angular area on the sky as from earth. The rest of the sky looks as if it's about 3K in temperature, ie very cold. The effect averages out to Mercury's 700K surface temperature.

The parasol itself will attain the same average temperature as the rest of Mercury's surface (because it's exposed to the same conditions).

But for anyone in the shade under the parasol will replace a patch of sky at 5772K where the sun used to be with one at only 700K where the parasol now blocks the view.

If your parasol is supposed to cover more than just a single point with its shadow, than it needs to be big. From the perspective of each shadow covered point, the parasol will have a bigger angular area than the sun it shades.

So you not only replace some 5772K area with 700K, but also some of the previously 3K area with 700K. Overall, you can probably set up things so that you get something like a balmy 15C on average.

> I would say the key thing with Mercury is the ability to dig fast.

To come back to this: Mercury has lower gravity than earth, so I expect that 'soil' will probably not be as dense?

> I don't know how he'd be deciding which oncoming cars are equipped with this feature, as it's still uncommon.

The technology is required on some types of headlights (which you can recognise), because…

> Better -something- that's trying to mask low beams than the alternative (nothing).

…they also made low beams notably brighter and reach further (= extended the angular output). The alternative isn't nothing, it's less bright low beams.

This is just math, not physics. Suppose you have a thing vibrating in a periodic manner. You might imagine that it will vibrate the air so that the sound pressure is some periodic function of time. Fourier transform that function to get a spectrum, and it will have discrete peaks at the fundamental frequency (1 / period) and at integer multiples of that frequency. You don’t even need to decompose into sine and cosine functions for this to work — all that’s really going on is that you have f(t) = f(t + period), and you’re turning f into the sum of a bunch of other functions g_1, g_2, etc, all of which have the same property that g_i(t) = g_i(t + period). Of course, if a function g has the property that, for all t, g(t) = g(t + period/n) for any integer n, then you can iterate that property n times and you’ll also have g(t) = g(t + period). And these functions with the fundamental period, half the fundamental period, one third the fundamental period, etc, are the fundamental tone and its overtones. You could decompose into square waves or just about anything else and you would get the same result.

(In any discussion of Fourier transforms complete with equations, you’ll usually see a bunch of factors of 2π because the frequencies are angular frequencies. This is done for mathematical convenience and has no effect on any of this.)

We are talking about a different time and different market. Google had the top brand overall back then but just in terms of frontend frameworks their brand became mud and no one trusted them after they spent the last year or two moving into angularjs and now they needed to rewrite everything. So they rewrote what they had in React instead of AngularJS. Facebook had the more trusted brand over Google and other frameworks.

Prompts? React and Angular came out over 10 years ago. The left pad incident happened in 2016.

Let me assure you, devs were skeptical about all this well before AI.

Yes, but it is not syntax. It's a contract with the library. React is completely usable using vanilla JS syntax. Same cannot be said for Vue and Angular. It feels a bit like talking about apples and oranges in this thread.

Merits yes technical merits no.

Products rarely win because of technical merits. Products win with marketing. Technical merits can add another layer to the marketing but without facebook's brand people would still be on angular.

My java apps from uni days still work on windows and non-arm macs. With a little tweaking for opengl links, arm works too.

My old uni android apps still work on android last i checked. With a recompilation my ios apps work on ios too.

However, with absolutely zero work, ALL of my web stuff across all time works just like it used to even the angular 1 stuff.

It is why i love web so much. It is the ultimate distribution platform with so little needless churn.

No React won and I choose it in 2015 because FB used it for their own app while Angular was by google but never really used by their top engineers so it was crappy. I think they still use Clojure compiler to this day. FB had correct incentives to keep it stable and good. Now that Vercel overtook I am more sceptical of incentive alignment

That someone can initialize a state in if block is not something good. React won with Angular 1.0 because noobs abused two-way binding making fking mess everywhere. Now in react they abuse useEffect but it’s a bit easier to control. I work currently in Svelte and never use 2-way binding and are careful to package state mgmt well but I like it. It’s similar to react with mobx but more performant although has no good component libraries. SvelteKit is also generally fine

I don't really see that, aside from the 1 to 2 jump, angular has been very steady and stable in their approach and and upgrades.