For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | more drbw's commentsregister

So pretty much the Blazor Server approach in the Dot Net world then?


Blazor Server and Blazor WebAssembly needs to be marketed separately. Most people have heard about Blazor WebAssembly but are unaware that LiveView-style web development is possible in the .Net world using Blazor Server.


Yes, yes they do. I don't know why you'd name pretty much the exact opposite techs the exact same thing.


I don't use Blazor, however when I went to get basic info about it every article I have read were very clear that there's 2 ways to dev a Blazor app.


It's also not unlike JSF in the Java world, which went out of fashion 10 or so years ago, and for good reason: relying on a framework to paper over the distinction between client and server side turned out to be much more complicated and fragile than a cleanly defined separation. I haven't seen any authors or users of these recently developed server-side-first frameworks discuss this prior art, but I'd be interested to see if they've come up with a way around what seemed like a fundamental problem in the approach.


As former JSF framework tech lead built on top of Richfaces, the major problem with JSF was its lifecycle model and the fact that Sun et al only defined the basic infrastructure and lead to a forest of frameworks that could hardly interoperate among themselves.

To the point that on my follow up project I ended up recomending for JSP with tag libraries instead, regardless of Sun advising them as deprecated and replaced by JSF.

WebForms never felt as complex as JSF.

I feel JSP like models with component libraries, or MVC are more closer approaches to the whole Web programming model.


Yes, basically. Fun fact: Blazor and LiveView were developed independently, around the same time as each other! Just two similar implementations in disparate communities.


Guess that was due to browser-land innovations that made this a possibility.


As the article says

> The details of how AlphaFold 2 works are still unknown, and we may not have full access to them until their paper is peer-reviewed (which may take more than a year, based on their CASP13 paper).

So it's not particularly surprising that we haven't heard much yet.


Yeah, it's practically archaeology now! It is very fast for doing some things, though.

If anyone's interested in it from a Dot Net perspective, ExcelDNA [0] was excellent when I used it a few years ago.

[0] https://excel-dna.net/


Try this episode of PBS SpaceTime which goes into the dichotomy between GR and QM: https://www.youtube.com/watch?v=YNEBhwimJWs.


No, but now I'm thinking about the early days of Slashdot, when "imagine a beowulf cluster of those" was a common in-joke. Along with the obligatory dozen claiming to be "frist".


I actually learned to code on a Beowulf cluster. The first programs I wrote to completion were on an LP mud that ran on a cluster in the creator's basement. Not because it was necessary for a mud with never more then ten users at once, but just because.


Pretty much - I started work before even internal email was a thing, so everything was done on paper. And often hand-written paper at that. Hell, I made the first Word template for a work-item ticket! Before that we had custom forms to fill out.

Even better, the developers worked in a different building to our users, so there would often be a couple of days lag to getting a response. If you needed a quicker answer, you had to phone them, or schedule a meeting if you needed to explain something in more detail.


A person so inclined can still order interoffice routing envelopes ("hundred milers") from most stationers. For the yoots, those were string-tied manilla envelopes with twenty to one hundred little addressing boxes that be re-used until there was no more room to cross out the previous addressee and add a new one.


Found one of those in the stacks of papers from my father's time at IBM. Funny how paper-based information technology was back then - the first thing that comes to mind are the punch cards, but also later program listings were printed out a lot.

We used stacks of "endless paper" core dumps / assembler listings when painting rooms, as you could just unfold a huge stack of paper to protect the floor from paint splatters.


The model I used (less than 10 years ago) had a grid of punched holes so you could quickly tell if there was anything in it.


As recently as 2008, I actually used those interoffice routing envelopes to submit the receipts for my expense reports. Then they introduced a new process involving scan and email.


this is still more or less how the US Air Force operates


I spent most of the money I'd saved from my summer job during my first year at university on a 42MB hard drive for my Amiga just so I could play Civ I without continually swapping floppies.

... and now I feel old.


Or use something like Nexus or Artifactory to host a private copy of dependencies.


I haven't used SSIS since about SQL2008 - back then it terrible to use with version control - not only was it a huge blob of XML, it had more xml escaped and shoved into attributes of the main document! Whats more it seemed to re-allocate the GUIDs of the elements every time you opened a diagram, so there were always changes...

Sounds like it's improved a bit since then.


Aren't things like $filter, $orderBy etc. straight out of the OData standard[1].

[1] https://www.odata.org/


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

Search:

HN For You