News for hackers. Stuff that matters.

orhanhenrik

Re:RemoteMac.io – Dedicated Mac mini on Thursday November 08, 2018 @04:00AM (#18405156)
1249 is for the expensive 2018 base model. The 29.95 price is for the cheaper old (not 2018) model. It will definitely be paid back much faster than that.
I imagine they are ditching the MacBook and just keeping the air and pro lines. It’s easier to distinguish the two, rather than “just MacBook” vs “MacBook Pro”. I also think air->new air is a better improvement to brag about than MacBook->new MacBook.
Re:Evergreen: a React UI Framework built by Segment on Wednesday October 17, 2018 @02:44AM (#18236700)
What’s nice about it is that a lot of projects use the same util, meaning it is very easy to read or edit if you are familiar with the library. If everybody writes a custom function you will need to learn how to do classNames separately in every project you work on.
Exactly the same happened to me about 1-2 years ago. It was quite stressful, but at least I got the money in the end.
Re:React Server on Sunday August 14, 2016 @07:25AM (#12285171)
The difference is that a "react server" can actually render the dynamic react content. I don't know of a way to do this in django, unless you are able to run javascript code somehow. If you do this, you are kind of making your django app a "react server" though, since it renders all of your react components.

What usually happens in a react app is that the server delivers static content (html, js, css). When everything is loaded, react starts working on the browser and renders / fetches data.

If the server that delivers the html doesn't just deliver a static page, but actually fetches data and renders it first, the browser can instantly display the data and react is smart enough to know that it doesn't even need to do a new render, because the components are already rendered to html.

Re:React Server on Friday August 12, 2016 @11:35AM (#12276490)
I have not looked at how this framework does it, but I have built a nodejs server that does similar things myself. Some advantages:

- The server can render the full page in html for the client, which means the website is viewable even without js (or before js has loaded, for example on slow network)

- The server can preload all data the client needs. The webapp might need to fetch data from 3 API endpoints. Having a server do this and pass the results to the client on load is much more efficient. If the client (browser) loads it, the following happens: html loaded -> js loaded -> start calling APIs. If the server does it, the client instantly has access to this data.

Rendering all the html can be a bit heavy on a weak server though, but you get the advantage that you quickly notice bottlenecks in your rendering. You can also implement some caching on your server to make it faster.

Re:JSON Web Tokens vs. Sessions on Sunday June 19, 2016 @08:09AM (#11932701)
And then your non tech savvy mother sends you a link to this cool website, and you're logged in with her credentials..