flavoie

angular :https://ng.ant.design/docs/introduce/en

vue : https://www.antdv.com/docs/vue/introduce/

I don't know how fast they will sync with 4.0 though.

I tried to use it in svelte, only loading the css/less from the react project, but with a svelte component. It works quite easily. The problem is that I would have to reimplement all components.

Saying that, I'm wondering why there is not a separated project for style and other for implementation.

If you add up yearly fuel cost (with real number you make, not the official one), maintenance cost ($ and time wasted). Not sure it hold true.

With my commute, suburban+urban with high traffic. Definitely not true. The bolt will be way cheaper.

It will be also quicker, even if it was not meant to be.

Highly disagree about performance. I find it more fun to drive than my 2011 305Hp mustang.

No lag, always full torque.

Because they never market it seriously. Where I live, it was a challenge to try one, even harder to find a salesman that can sell you the car. Nearly nobody knows about that car.

It's the only car in the industry that took seriously sustainability. (Sustainable textile, recycled material, end of life reusability and recycling. etc.)

The efficiency is excellent, about 5kwh less per 100km than a tesla. It drives great, it's powerful, fun to drive. I haven't found a i3 owner that didn't like his car yet.

With the range extender it removed range anxiety without add long recharge time on a trip. (granted with more frequent stop)

I bought a used one last week. Maybe it's the honey moon, but it's the best car I have ever own, by far.

The lack of leadership from top executive made the car unpopular, not the car itself. This also led to a lot of employee turnover because the lack of seriousness about the i series.

They have decided to make it in a standalone package so it can evolve independently. Like xamarin is not part of .net

Its not about being supported or not. It's just an external. it's not up-to-date with java 11 https://openjfx.io/

You can also use clojure with it if you want a lisp dialect.

> Seems to me that using a switch over another structure for performance at the expense of readability or maintainability

But is not more readable or even more maintainable.

Plus there is absolutely no optimization involved, it's just another way of expressing it.

I don't think it's "better", it mostly depends on what you want to achieve.

Users, except the tech savvy one, will not notice if you do a nice job. (hard to miss with UI framework like fabric, semanticUI, etc..)

If you want a small application that start fast and/or use system look and feel. A react-native approach (like https://proton-native.js.org/) will be better.

If you plan to customize/brand your apps and the app will run for a long time, it doesn't really matter. The downside is that it will take more memory.

Also, v8, constantly improve, reduce memory usage and optimize javascript performance. Soon it will be easier to run faster code with webassembly. It's even possible now to compile your typescript code with AssemblyScript, or do it the hard way with C, C++ or Rust. It's only a matter of time before the performance between the two will be reduce.

As for the problem mention about the whole browser ship with every apps. Maybe we will see a solution similar to adobe air in the future or a way to strip down blink based on the app requirements. Technically a browser is just a standardized drawing library, like flutter uses skia, Qt it's own or GTK uses cairo.

I switch my old old MBP for a HP Spectre x360 running Fedora. http://store.hp.com/CanadaStore/Merch/Product.aspx?id=2SP85U...

Build quality is good for a PC, but doesnt match my old MBP (a bit less robust). Also Apple put an anti glare on the screen, I don't think HP ever heard of that. Even if there the screen can be brighter, end result is worst.

Everything works fine except the webcam.

But if you're a Mac OS power user, there is some things you'll greatly miss.

First, the keyboard shortcut. OS X uses emacs shortcuts all over the place, consistently. CTRL-K will do the same thing in the terminal, in your mail app or in your web app. Same thing for CTRL-E, CMD-[XCV], CMD-Arrow(s) etc... When you are use to this, it's quite powerful and convenient. Also you're Mac keyboard has less keys because it doesn't required them.

On linux, it's the same shortcut you'll find on Windows and its mostly inconsistent. To do the same action the shortcut changes depending on the running application. Emacs’ in terminal, windows’ in Mail. Sometime copy/paste is CTRL+[CP], sometime you need to add the Shift key. Same thing for all shortcuts. When you're used to Mac power and simplicity, this is quite frustrating.

Plus, if you write in multiple languages, on the Mac keyboard you can write letter like è, ñ, ... only by using the option key. On linux you have to switch the keyboard layout or remember the hex code.

After 8 months, I’m still more efficient on a mac keyboard.

One other thing to keep in mind is the trackpad. On linux it's painful. There is two software solutions, none works correctly. Palm rejection doesn't work well or it doesn't work at all. The only partially usable solution is to use disable the trackpad when the keyboard is in action. This is a Linux limitation, not a trackpad issue. Terrible! Simply terrible.

I don't know how much these details worth, but in the end I'm not sure I made the right decision to switch.

" Similarly, sub-zero temperatures scare people to warmer areas, leading to a brain drain and serious demand for startup-orientated marketers."

Living in one of the cities, sub-zero might have an impact but I don't think it's the brain drain main reason. For aspiring founder, I think it's more related to insufficient founding. For engineers, I think the very low salaries is more to blame. Even if cost of living is a bit lower, the difference makes no sense at all.

touch on Linux is also the reason I keep using chrome

I don't understand why it's such a big deal with the GC.

Ok if you want to build drivers or OSes related stuff.

For AAA games, I can understand, but they will not switch to a new language as long as there is no engine like Unreal or Unity3D (GCed) that worth the switch. And the rest are indie and a GC will not affect performance.

For web services, GUI application, the GC would be desirable because it will enable the developper to work on the business model and not the computer model and it will removed stupid memory management kind of bugs. Plus, 1200 fps vs 1120 fps is not faster since we can't see the difference.

Is it that the D's GC is really slow or really memory inefficient?

I just start recently a file manager in Electron just for fun. I decided to use electron for a couple of reason.

My everyday work is in Java, JavaScript everyday, I wouldn't use Java in my free time for sure. But I do like JavaScript now with Babel/TypeScript. I did in the past worked with wxWidget and pyGTK but I found that building UI with React is more convenient and flexible.

UI performance are on par for this type of application, plus fetching file information from node is also pretty fast. But if I ever encounter performance issue, it's quite easy to redo the bottleneck in c/c++ with node. And pretty soon in the browser with webassembly.

Memory consumption is less than my Finder process (with all the opened helpers). But if I compare application like VS, VSCode and Intellij. Electron memory usage should be in between a C++ and Java apps.

The challenge would be to make it start/open really fast (now for the prototype it's like 1 second). But I guess it's possible to do the same thing as Nautilus/Windows File Manager/MacOS Finder and have a background process running.

Before the line between language and framework were more sharp. But I think with the evolution of the language and framework like electron, the line is getting a bit more blurry. Great apps could be written in electron as they can be written in a native framework. End users will be the real judges.

At the current exchange and the salaries that are higher in the US, you can nearly double your salary. Lets says you can have 100k USD, exchange to Canadian gives you 145k CAD. In a city like Montreal where you can have a maximum of 85k CAD in most places (yes I know some pay more, but it's still not that common), this make a huge different.

Best is to work remotely, but if you move across for a couple of years, when you come back, this is a new house paid cash.

I can understand it's hard for people with family, but otherwise I really don't understand why young engineer stay here.

Do they have a clear roadmap to reach 1.0?

I'm curious if they tried Cython. I've read that you can achieve up to 35% speedup just by compiling python code, plus you can type pyx file to get near C performance.

I never tried it, this would have been a nice use case.

Plus, with Haxe and openFL, you will be able to ship native c++ build of your game for free (same code).

If only Haxe could add something more uptodate for multicore concurrency than thread.

It's what make language that compile to JS worth using.

I've start using LiveScript on a side project and TypeScript at work. I can now use the future without browser compatibility nightmare.

Is Guile only for GNU system? Can it be embedded in OSX, iOS or Android application?

Seriously? Every time I heard someone mention Go, they linked it to google to make it sounds as big as possible.

notes at the end : """ [3] This begs the question of why he said this. The reason he gave at the time was that most of his time was being taken up dealing with multi-language integration issues. However, this was belied by the following fact: shortly before the review, I met with the integration engineer and offered to help him with any Lisp-related issues he was encountering. He replied that there weren't any that I could help with. So while there were issues that arose from the fact that Lisp had to interoperate with C, I do not believe that a good-faith effort was made to address those issues.

Postscript: Many of the multi-language integration headaches were caused by the interprocess communication system that allowed Lisp and C to communicate. The IPC relied on a central server (written in C) which crashed regularly. Getting rid of Lisp did in fact alleviate those problems (because the unreliable IPC was no longer necessary). It is nonetheless supremely ironic that the demise of Lisp at JPL was ultimately due in no small measure to the unreliability of a C program. """

A page dedicated to landoflisp on sbcl would great. clisp looks like more trouble to install on my mac than the sbcl package.

You can also take a look at qooxdoo. http://qooxdoo.org/

It's feature rich (more than cappuccino at this time), it has good documentation, it provides a nice unit test framework and it's easy to use.

One thing that worth noting, is that framework like capp/sproutcore/qooxdoo are design with all the widget in mind(not the case with jQuery). That provide a more coherent api, everything is test against each other, it's easier to build, maintain and update. But all of this at the expense of being a little bit bigger (kb).

One advantage of cappuccino is the GUI builder Atlas, but only if you're on a Mac and all your team members are on a Mac. There is no announcement yet if or when it will be available on Windows and Linux.