I have fully-vested options in a private company which expire in Dec 2023. A company has reached out to me saying they have a buyer for the shares. The shares are worth > $300k.I'd like to sell because they expire in Dec 2023 and I don't know if there will be a liquidity event before then, however they want to take a 5% cut.Is this a normal cut for a middleman in this type of transaction? Is...
Learned Atari basic from a 2 page leaflet that came with my 800XL when I was 8, then progressed through True Basic and GFA Basic.
Freenet is designed for sharing information, not archiving it. You can't have both.
The system did not and could not store information permanently, if it did it would fill up, which is a non-starter when it depends on people volunteering their hard disk space.
I don't know about going ballistic, but since this issue is addressed directly in their papers (section 3.4 of the linked paper) I can see us getting irritated by people re-asking questions that have already been answered.
Fortunately, that's not so - Kweb has a neat way to handle it - outlined here: https://www.reddit.com/r/programming/comments/a4dtp2/kweb_a_...
> In my opinion, we can't say the separation has been "eliminated" if I'm constantly having to ask myself "should I handle this event on the server or the client via `onImmediate`?"
Well, I said "virtually eliminated" :)
I think it's an exaggeration to say that the programmer must constantly ask themselves this, it's only relevant when adding an event listener. You'll get along just fine if you never used onImmediate, it just means your webapp may not feel quite as snappy as it could be.
To me this seems like a very small price to pay to avoid having to bifurcate your application across client and server - particularly given that it's not even compulsory, it's an optional optimization.
> What seems more likely to happen, is that inexperienced developers simply won't ask the question at all and months later the customer will ask why their dashboard page is taking 60 seconds to load. The senior engineers will be tasked to fix it only to find out that the page is making dozens or hundreds or thousands of N+1 round trips to the server.
An unnecessary roundtrip may add 200ms of latency across a typical internet connection to the speed with which the page responds to an event, but I can't think of any circumstances under which this would delay the page render.
Moreover, a website built without onImmediate should work just fine, it just might not quite match the performance of a well-written client-side app.
> This has been my experience being asked to come in to fix MeteorJS apps. Teams of web developers not understanding that the client/server interface is not free and that poor engineering practices have severe compound effects.
There is only so much a framework can do to save programmers from themselves. In this case the risk is that the app may feel a little more sluggish than it otherwise would, a difference that users might not even notice.
It may be possible to automatically identify candidate event handlers which don't appear to be modifying server-side state and provide a nice list to the programmer, but I'd likely only invest time in this if it proved to be a significant issue in practice.
The reason is it depends on some stuff like coroutines - and since Scala deprecated their delimited continuations plugin way back when, I don't believe Scala has any equivalent feature.
May I ask why you ask?
https://github.com/kwebio/core/tree/master/src/main/kotlin/i...
Also, if you use IntelliJ IDEA then the IDE will do a lot of the work for you in figuring out the API.
This is because Kweb doesn't entirely abstract away the client/server separation in one important sense. When you attach a callback to something you normally do it like this:
button.on.click {
header.text("They clicked!")
}
button.onImmediate.click {
header.text("They clicked!")
}
Does that alleviate your concern? If not, can you elaborate on where you think the bottleneck is likely to emerge?
Here is kerax:
var lines: seq[kstring] = @[]
proc createDom(): VNode =
result = buildHtml(tdiv):
button:
text "Say hello!"
proc onclick(ev: Event; n: VNode) =
lines.add "Hello simulated universe"
for x in lines:
tdiv:
text x
setRenderer createDom
fun main() {
Kweb(port = 2734) {
doc.body.new {
button().text("Say hello!").on.click {
println("Hello simulated universe")
}
}
}
}
Wicket suffered because it straddled the transition from pure HTML to HTML+AJAX. It could do HTML+AJAX, and their solution was elegant, but it was an afterthought and Wicket wasn't really designed around it.
Kweb was designed from the ground-up for this world and this affords it many advantages.
You are correct that, since kwebsites are server-driven, there is no significant offline capability.
But then the requirements of many websites often rule that out anyway, my strong suspicion is that this won't be a dealbreaker for many people.