Announcement

Collapse
No announcement yet.

GitHub Completes Its Acquisition Of The NPM JavaScript/Node.js Package Manager

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • pal666
    replied
    Originally posted by utopik View Post
    Why would I code a web application with wasm ?
    you wouldn't. we were discussing c++. translation to wasm is job of compiler.
    Originally posted by utopik View Post
    Browsers are optimized to display html + css + JS so I use these languages.
    now browsers are optimized to run wasm, so i would use real language. but you didn't say "I use", you said "You have no choice than using JavaScript", which is demonstrably false

    Leave a comment:


  • Emmanuel Deloget
    replied
    Originally posted by utopik View Post
    Cpu usage can be high on Linux during animations, due to missing HW accelerations I guess. That's not inherent to css, on windows it should be HW accelerated.
    This specificity has been tested on firefox, safari, chrome, on Linux, Android, Mac OS, iPhone, iPad, Windows, where it makes sense of course (and you have HW acceleration for HTML rendering on Linux, although it might be experimental on some browsers).

    If that bother you that much and you are at ease with C/C++, then what prevent you from reducing energy consumption on Linux by contributing to Chromium/Firefox or any other open source browser ?
    Browsers are not my area of expertise and I don't have the time to dive into their code. I also don't like the music of Ariana Grande, and that does not mean I'm an expert in music and that I will send her fixes to anything she sings (you shall be aware that the idea of "if you don't like it, fix it" is a valid one only in a world where time does not exist ; those tend to be quite rare... ).

    Leave a comment:


  • utopik
    replied
    Originally posted by pal666 View Post
    for someone who doesn't know c++
    you even mention wasm below, what is preventing you from using it in browser?
    Why would I code a web application with wasm ? Browsers are optimized to display html + css + JS so I use these languages. If I need to develop a game in the browser, sure, I might use wasm or a game engine which will compile to wasm. If I need to reuse an existing C library, sure I could compile it to wasm and call it from my web application with JS. In order to manager rendering with wasm you will have no choice than using OpenGL/WebGL. I don't see how this would lead to less energy consumption btw, and you can say goodbye to accessibility features.
    Last edited by utopik; 18 April 2020, 01:46 PM.

    Leave a comment:


  • utopik
    replied
    Originally posted by Emmanuel Deloget View Post
    I'm perfectly fine with JS on client side, given the fact that a CSS spinner is already eating up to 30% of your CPU, sometimes even more ).
    Cpu usage can be high on Linux during animations, due to missing HW accelerations I guess. That's not inherent to css, on windows it should be HW accelerated. If that bother you that much and you are at ease with C/C++, then what prevent you from reducing energy consumption on Linux by contributing to Chromium/Firefox or any other open source browser ?

    Leave a comment:


  • pal666
    replied
    Originally posted by utopik View Post
    Implementing an API with Node.js is undoubtly far more elegant, less bug prones, and far more productive than with C/C++.
    for someone who doesn't know c++
    Originally posted by utopik View Post
    Want to run code in a browser ? You have no choice than using JavaScript.
    you even mention wasm below, what is preventing you from using it in browser?

    Leave a comment:


  • Zeioth
    replied
    Originally posted by uid313 View Post
    It's too bad the Node.js version that ships with Ubuntu 20.04 is old. Also the Node.js, npm and node-gyp depends on Python 2 instead of Python 3. 😢

    It's too bad that GitHub doesn't officially support GitHub for Desktop on Linux.



    If you don't like NPM there is Yarn, and if you don't like JavaScript there is TypeScript. But yeah, JavaScript sure have it wonks and wrinkles.
    You really want to work with virtualenvs when you use node. Same as python.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Vistaus View Post
    Because Google is usually the one wasting money on project that they know are going to fail or know beforehand that they will lose interest one day. Sure, there are MS examples of that as well, but less so than from Google.
    Not really, I would say they are more or less even, Bing, the VR thing, Windows phones, Windows 8, Windows RT, Windows 10 on ARM, Windows Store, the "limitless cloud storage" for Office 365 that was drastically reduced later, myspaces, MSN messenger, Internet Explorer, Edge (as a non-Chrome reskin), Skype...

    Leave a comment:


  • Michael_S
    replied
    Originally posted by AH88 View Post

    If what you're doing is a serious, long-term project, it's worth doing efficiently. If what you're doing is some disposable, short-term novelty, it probably doesn't matter much. Most people doing node.js projects fall into the latter category.
    Look at the state of the world - how many big, successful projects launched as C, C++, Fortran, Objective-C, Rust, or similar? They exist, but they're a tiny minority: kernels, compilers, video encoding, databases, runtimes and interpreters for other languages, graphics-intensive games.

    Know any source code hosting sites written front-to-back (save for the client side, of course) in C or C++? How about CMS systems? CRM? Webmail? Social networks? RSS Feeds? Blog engines? Configuration management? Continuous integration servers? Wikis?

    (Edit: how about all of the IaaS and PaaS projects?)

    Do you know any projects or companies that replaced all of the shell, Perl, and Python scripts in their operating system init process with C programs?

    My kids play dozens of games on their Android phones - but they're things with the graphical complexity of Angry Birds, and Candy Crush, and so forth. How many of those use the Android Native Development Kit? Probably none.

    From a moral perspective, an engineering perspective, an environmental perspective all software development is "worth doing efficiently". In the world we live, nothing done efficiently outside domains with severe performance constraints survive. They're always beaten by anything - no matter how trashy - that allows more rapid development iteration.

    Originally posted by Emmanuel Deloget View Post

    I agree with you - economic considerations and immediate RoI are often more important to companies than intelligent architectural and engineering choices. But then, give the very nature of the JS language, you're pretty sure at the very start of the project that the technical debt is going to be huge in the future so if you have any long term plan for the product, you'd better start with a language that allow you to have a tighter control over your code. You see, not only I consider JS to be a bad choice on energy consumption ground, I also consider it to be a bad strategy in the long term (again, server-side ; I'm perfectly fine with JS on client side, given the fact that a CSS spinner is already eating up to 30% of your CPU, sometimes even more ).

    RoR and python, while being slow, still have the advantage of being far more controllable languages, with better type systems and a more well-thought structure so it might make sense to use them. But as your user base grows, the limitation of the language will bite you - and if you're serious about serving hundred of throusands of users then at one time it will be cheaper to use a more efficient language than to continue to rely on these. Having more users/customers does not radically change the size of your team, but it changes the number of servers and their cost quite a bit . $5k for infrastructure cost per month is not that much, but imagine $500k. This number just means you grow your user base by a factor 100(*), which is not unprecedented for an Internet-based service. Suddenly, a rewrite that gives you a 10% decrease on the cost of your infrastructure generates $50K per month - and that becomes a viable project.

    In the end, you're right: economic considerations are the most important, and planning is king. You should carefully select your server-side language considering your target audience and your expected business plan. Making a choice without considering these is a bit irresponsible.

    (*) that's not really that. As your customer base grow, your infrastructure cost grows faster, especially if you own your servers and are responsible for their maintenance. But let's imagine we're in a perfect, linear world for the sake of the demonstration
    If your customer base goes up 100x then it becomes practical to rewrite your project in C - and that's exactly what companies like Google and Facebook do. Youtube was originally written in Python, I imagine they've rewritten it in something else. Facebook was originally written in PHP, they have rewritten a lot of their back end code in C++, written a faster PHP runtime, and I would guess are also incrementally converting the remaining PHP to C++.

    But for every project that achieves the infamous 'web scale' and gets a rewrite (or more likely, incremental transition) into something hyper-efficient, there are tens of thousands of projects that never need it.

    On the particular topic of NodeJS, I would guardedly agree that from a maintainability perspective it's not as good as Python or Ruby on Rails. But I completely believe thoughtful design and engineering discipline (good practices, code review, unit and automated testing) trump specific language concerns. A great team building a product in NodeJS will make something better than a decent team building a product in Python or Ruby.

    And of course Node has two other selling points, which you know: you can use the same language client and server so your 'full stack' engineers have less mental effort to translate back and forth, and there are compile-to-js options. That hurts your performance even more, but you can use almost any language you want on both sides that way.
    Last edited by Michael_S; 17 April 2020, 11:00 AM.

    Leave a comment:


  • Emmanuel Deloget
    replied
    Originally posted by Michael_S View Post

    In most of our industry, ease of development matters many times more than efficiency.

    Github launched on Ruby on Rails, and that might be their primary code even now - and it's slower than NodeJS. Gitlab also uses Ruby on Rails. Launchpad and Sourcehut use Python, which is also slower than NodeJS.

    At work my team costs the company about $100k per month in salary and benefits and the infrastructure that we run costs about $5k per month. If we rewrote everything in C - or Assembly, or C++ - we might get the infrastructure cost down to $1k per month. If we wanted that rewrite investment to pay for itself in, say, 5 years or less, then you're balancing $4k/month * 12months/year * 5 years = $240k savings against the engineering costs to switch to C. $240k savings / $100k engineering budget per month = 2.4 months, so unless we can do the rewrite in 2.4 months or less, it's not worth it. We have over half a million lines of code, we couldn't rewrite our code in any language, even the same languages we're using now, in less than three years.

    I understand your frustration. I'm frustrated too. But the problem isn't the tools or the engineers. The problem is the whole market. Doing things the right way gets you nowhere.
    I agree with you - economic considerations and immediate RoI are often more important to companies than intelligent architectural and engineering choices. But then, give the very nature of the JS language, you're pretty sure at the very start of the project that the technical debt is going to be huge in the future so if you have any long term plan for the product, you'd better start with a language that allow you to have a tighter control over your code. You see, not only I consider JS to be a bad choice on energy consumption ground, I also consider it to be a bad strategy in the long term (again, server-side ; I'm perfectly fine with JS on client side, given the fact that a CSS spinner is already eating up to 30% of your CPU, sometimes even more ).

    RoR and python, while being slow, still have the advantage of being far more controllable languages, with better type systems and a more well-thought structure so it might make sense to use them. But as your user base grows, the limitation of the language will bite you - and if you're serious about serving hundred of throusands of users then at one time it will be cheaper to use a more efficient language than to continue to rely on these. Having more users/customers does not radically change the size of your team, but it changes the number of servers and their cost quite a bit . $5k for infrastructure cost per month is not that much, but imagine $500k. This number just means you grow your user base by a factor 100(*), which is not unprecedented for an Internet-based service. Suddenly, a rewrite that gives you a 10% decrease on the cost of your infrastructure generates $50K per month - and that becomes a viable project.

    In the end, you're right: economic considerations are the most important, and planning is king. You should carefully select your server-side language considering your target audience and your expected business plan. Making a choice without considering these is a bit irresponsible.

    (*) that's not really that. As your customer base grow, your infrastructure cost grows faster, especially if you own your servers and are responsible for their maintenance. But let's imagine we're in a perfect, linear world for the sake of the demonstration

    Leave a comment:


  • AH88
    replied
    Originally posted by Michael_S View Post
    In most of our industry, ease of development matters many times more than efficiency.
    If what you're doing is a serious, long-term project, it's worth doing efficiently. If what you're doing is some disposable, short-term novelty, it probably doesn't matter much. Most people doing node.js projects fall into the latter category.

    Leave a comment:

Working...
X