HN user
Hi, I'm Eric
eric at tacinsight.com
What router are you using? One in the svelte ecosystem or a vanilla js router?
Also in the process of writing an app that has no ssr needs. There are some minor annoyances with SvelteKit and interested in other options.
RE: Microsoft
1) MSFT has already used React for far longer than 2 years.
2) They have basically never used the technologies you mentioned (WPF, Silverlight, WinUI). They offer them as UI toolkits that run in their Windows environment and that’s it. Their failure to market and support these technologies is independent of what they do for their own development strategy.
3) They bought GitHub and effectively own electron now. Many of their biggest apps are on electron (Teams, VS Code, Azure Data Studio).
We were on Hasura Cloud and really did not have a problem with it. But we moved away to self-hosted Hasura for more control over deployment and cost as we have 10s of same-schema MSSQL databases that we were orchestrating and the management and synchronization of metadata was becoming a bit of a pain.
They just announced dynamic connection routing[1] which is a feature we have sorely needed as it would allow us to run a single instance. Fantastic stuff.
It is marked as "cloud / enterprise" only feature. Fine. Just yesterday we began to explore moving back to the hosted cloud service to prepare ourselves for availability of the feature.
And then today they announce this pricing change that 10x's the amount we would pay! On top of that the max for dynamic connection routing for the Pro plan is listed at 1! What's even the point???
Our opinion of Hasura has always been high and we've been quick to recommend it. But with the strategy and pricing in flux it's hard to justify picking it for future API needs. They seem to pushing aggressively towards Enterprise or bust deals which is a shame because the features they are gating off behind the Enterprise wall are fundamental to many application architectures.
[1] https://github.com/rakeshkky/graphql-engine/blob/dynamic-con...
No, it's not a bad thing.
It's how (nearly) everyone using React (or any frontend framework) + Tailwind will structure their code. And I'm not sure the author is arguing against Tailwind's utility in static styling scenarios.
I think the article's author would argue that once you move beyond static classes that Tailwind's class building becomes messy.
So <SideBarItem padding={4} active={true} /> would be cleaner in the authors mind if the exposed props get applied by some other tooling better suited for dynamic styling instead of simple string manipulation.
There is some merit to that argument. Building the class string can be cumbersome in some scenarios. But Tailwind "clicks" for me where other solutions do not. So I do it anyways.
We (tacinsight.com) are rebuilding our entire front end from scratch and are looking for a senior javascript engineer. Preferably with prior experience in a large React project.
This is a greenfield rewrite of a tightly coupled ASP.NET frontend to React+API.
Email in profile if interested.
Sort of. But not an embedded browser. And .NET instead of JS.
There are some promising developments with Blazor and .NET MAUI. But it all seems too speculative to build on at this point.
We have a Windows POS app for mines, quarries, sand and gravel, etc.
When we broke ground on this version Microsoft was hardcore pushing UWP. We were building for the future so we built our app within the constraints of UWP with the expectation that it would grow with Microsoft’s vision…
Fool me once, as they say. UWP is dead.
We are currently redeveloping the entire thing with a series of Win32 base classes and intend to layer on a WPF front end for now. WinUI is early and promising. But so was UWP.
Long term we’re exploring outside the box UI options like running a local server and popping a browser. C# and .NET are very powerful. But the fractured landscape for desktop development gives little hope for the future.
If your goal is to build a rich UI, then you may have to suffer through learning whichever flavor of XAML you decide to go for. But if your goal is to interact with local hardware functionality I’d probably steer clear and use WinForms, a browser interface, or a console interface.
Can this CRDB Serverless offering handle the burst connections of a serverless function based app? Are pooling or query queueing features built in?
Or would users face connection limits at some upper bound until the old function connections get spun down?
It's very polished. Kept up to date. Follows best practices for RoR. The author is one of the most active RoR community members.
edit:
If you like PHP then https://spark.laravel.com/ is an official Laravel project. I haven't used it but I've seen discussions where folks recommend it.
Intrigued by this approach!
Is the source shareable?
We have an enterprise app that was originally built as a UWP application via Xamarin.Forms (Hot mess, I know. But the decision predates me).
We've been prototyping a rebuild in React and Electron but if we could port into WebView2 and reuse a lot of our existing business logic with a port into a local api layer a lot of time could be saved.
I'm a web guy, so not sure how the nuts&bolts of this would work. Does the WPF app bootstrap a REST API on localhost on startup that is callable?
We have layered Hasura over an existing set of SQL Server databases to provide a public facing API for our product. [1]
Overall the experience has been fantastic. The performance and authorization scheme is very good. It has allowed us to wash our hands clean of bespoke endpoint writing for our enterprise customers with complex integration requirements (for the most part... waiting on mutations!).
One thing I wish was handled differently would be Same Schema, Different Database support.
We have multiple multi-tenant databases as well as many single tenant databases. All share the exact same table structure. As it stands, we have to maintain a separate Hasura instance for each of these databases as the table names conflict and there is no way to rename or reference them differently. That leaves us with the minor annoyance of needing to instruct users on their appropriate server prefix (server1.fast-weigh.dev/graphql vs server2.fast-weigh.dev/graphql... etc). Yes, we could proxy in front of these and route accordingly. But that's just one more layer to deal with and maintain.
It sure would be nice to have a single instance to maintain that could handle database availability based on the role of the incoming request.
Even with the minor inconvenience of multiple instances, I 10/10 would recommend. It's a huge timesaver assuming you've got the data access problems it seeks to make easy.
REST itself is such an amorphous term nowadays that it's tough to even measure/define this. It seems to now mean basically any multi-endpoint based JSON API.
GraphQL is trendy and might take over "REST" for startups soon if it hasn't already. But in real-world adoption in established companies and dev teams I'm not sure that it ever will. REST / typical JSON APIs are so prevalent because they are fully backend agnostic and so darn easy to write (Note: not easy to write well). GraphQL has some architecture and typed overhead to learn prior to spinning up an endpoint and the underlying logic to stitch together the data. With REST, it's just HTTP call, backend processes call, return JSON, done.
I'm totally sold on server rendered, HTML over the wire web apps. What I'm not sold on is websockets for the transport layer.
Unless you truly need real-time, I'd argue that something like HTMX (https://htmx.org) is a much simpler and more reliable route. Simple HTTP calls keep the request stateless and give architectural freedoms that shouldn't be taken for granted.
https://miragejs.com/ is a great complement to frontend first development. Some folks on my team use it and love it. I tend to dev from back to front so I don't run into the need as much. If I do I typically just mock a JSON response in my frontend call function. Depending on the need I'll sometimes set the call to return an error response as well.
Looks like their product is built specifically for Slack.
I'd be interested to take the pulse of HN:
When you are looking for a new Windows app, does opening up the store even cross your mind?
I nearly always go to a web search + download first. Or if it's something dev-centric I look at scoop or chocolatey. The Windows Store is far, far behind in my mindshare.
There are a few glimmers of hope though. Python has begun to distribute via the store which is cool. And the Linux distros available are helpful in some edge cases or for a quick dev environment.
I get that it isn't supported. We have followed the recommendations mentioned in the docs but found the usage of these workarounds to be sorely lacking in performance and reliability.
Anyone with inside knowledge of Firestore care to comment on the ETA of more advanced query functionality?
We have played with Firestore quite a bit, but rely heavily on the ability to do aggregate queries. Reading all of the documents and performing this on the client side is nowhere near good enough. Nor is triggering functions to update a "count" or "sum" property on a doc.
Edit: Looks like a PM answered on another thread...
"It's a point of internal discussion on scalable ways to achieve this, but nothing we can promise. We definitely see the need for it."
C# ASP.NET Core Razor Pages SQL Server Dapper vanilla JS
Azure for hosting and peripheral services
It is truly a breeze to put together server rendered apps with this stack. I come from a JS heavy background but find myself so much more productive with C#.
It's not trendy, but that's mostly because it's Microsoft. But it is powerful and productive.
This is also great for avoiding binge drinking. I did this in college and it's incredibly hard to drink to the kind of excess most college folks do when you're needing to pee ever 15 minutes.
timdev2 sums up my original sentiment quite well. Is spinning up and maintaining a DB architecture doable? Of course... But there are so many complexities involved for real production that it would greatly slow us down.
If we had staff to dedicate directly to this then it wouldn't be an issue. But paying for a managed service that gives us production grade data access is a no-brainer for any non-trivial application we build.
I for one have always liked the simplicity of DO for hosting but I've never wanted to take on the full liability of self-rolling a DB server (and backups and replicas). So everything my company has I've put on heroku or azure. This has potential to be really significant as I'd wager there are a lot of folks in similar situations.
I'm surprised there isn't more about Buffalo in this thread. It's creator (Mark Bates) has stated inspiration from the rails world, but has focused on building Buffalo to be very flexible.
It provides a nice boiler plate for the modern web app and pulls together a lot of the single packages mentioned here so you don't have to worry about wiring things together.
I've built a few small apps with it and thoroughly enjoyed the dev process.
(GoBuffalo.io)
https://www.nanobox.io is also a great option for Rails... or many other languages & frameworks.
Contained developer environments, simple command line deploys to VPS, and a free tier that can handle most hobbyist application needs.
I deploy Rails & Elixir / Phoenix apps with Nanobox
I'm glad there is another random highlighter out there.
Medium & kin infuriate me with the popup toolbar.
I for one really like the name and URL and don't mind the name collision.
It's something that is bound to happen. There are a finite number of words, names, and spellings to make use of.
Gophers tend to roll their own and forego larger frameworks.
Piecing together libraries can absolutely be daunting, but once you get a starter app built your productivity will go way, way up.
I'd really recommend this (paid) course at https://www.usegolang.com
It walks you through pulling in different libraries (Gorilla Mux, GORM, etc), gluing them together, and structuring your code in a maintainable way.
A couple of other folks have mentioned Buffalo. It's a great ecosystem for building applications quickly, but I would strongly urge you to go through gluing the packages together yourself first to really understand what is going on underneath the magic.
Edit: On smaller screens it's ok, because the text falls in the lighter blue color.
Suggestion: Take a look at the contrast on your header text. The dark lettering is extremely difficult to read. It looks like the text explains the entire company's premise... so I'd think you'd want it as readable as possible.
Fellow Knoxville TN resident here. It's been really sad (but most certainly not surprising) to see law makers be influenced by Comcast/ATT.
Comcast's recent Gig advertising around here is almost laughable. We've called in to discuss upgrading but their sales and support are clueless.
Side note: As I was trying to comment on this my business class Comcast connection dropped. Go figure.