261–270 of 323 posts
Earlier quoted context omitted.
> It's not like JS is specialized in some very small niche by design -- like e.g. COBOL is. Uhh, what? You don't consider "programatically manipulate the DOM in the browser" to be a niche?
Accessing the DOM is not really part of the language specification, but the browser API, no?
The more time goes by the more I feel crazy for missing whatever would motivate people to use js for anything more than is strictly necessary. Single threaded server??? I mean come on man, I understand you don't need parallelism for a lot of use cases but even if that fits your situation why javascript? It can't be that hard using a different language. I refuse to believe that.
The argument that people always throw at me is that too hard for people to know two languages, well, for frontend devs to know two languages. Now in a perfect world the frontend people who just can't figure out two or more languages would never touch the backend but the world of software now is "that'll do" not "what is the right tool." It's a shame to me really but I'm not a frontend dev for a reason.
This is ridiculous from the point of view any professional developer. I know that this is your point, and I'm just amplifying it. I (and many other professionals I work with) know - and use on a daily basis - so many more than 1 language that it's sincerely baffling to grok a world that promotes "One language fits all". That's without even considering the parlous state of npm and its libraries.
Earlier quoted context omitted.
I felt frustrated by the typical Node toolchain until I remembered the typical Qt toolchain for developing cross-platform desktop apps. I can't remember everything, but here goes. To compile a Qt app you need: - the meta object compiler (moc) to add dynamic features to C++ for Qt use - the Resource Compiler (rcc) to embed icons or sounds as arrays in header files - the Qt Quick Compiler if you are using QML files for…
I think it's more accurate to compare Node to C++, compare NPM to apt/yum/etc+CMake, and compare something like Electron to Qt. Of course, your point still stands. But's a tradeoff. C++/Qt has a ton of compile-time bloat, while Node/Electron has runtime bloat (see the Slack client using hundreds of megs of ram). And you can use bindings, like PyQt, where you have Python/Qt and then you get Python's dependency managem…
Comparing C++ to Node or Python doesn't help me. If I could write Python that run in the browser I wouldn't be commenting here.
Earlier quoted context omitted.
I'm sorry, what don't you understand? Complexity is best discussed by those who introduce it. To be clear: I said js is misplaced on the 'server' side and is a wart in general when applied in that context. Any educated comment on these sentiments?
> what don't you understand Exactly what I asked. > Any educated comment on these sentiments? Without clarity on the sentiments themselves there's not a lot to elaborate on without simply fumbling in the dark. If the concern, though, is that, in Node, you live and die by an asynchronous event loop, I'd say that's not a small footgun. I don't think that's in dispute. I'd also say that the presence of footguns doesn't,…
It is the poster child for the "If the only tool you have is a hammer..." maxim.
Its appeal derives almost completely from its presence in probably every major browser, where it was placed for DOM manipulation and was stressed way past its design envelope over time, leading to the increasingly dystopian web development landscape we progressively inhabit.
If it is ultimately victorious, it will be in spite of its design, not because of it. Those of us who are old enough to remember will cringe at the pain we endured over the years because of the widely used Intel 808x architecture as it evolved (small/medium/large/huge memory models, and segment registers, anyone?), not because it had the greatest merit, but because of its market penetration.
History repeats itself.
Earlier quoted context omitted.
That's exactly what it is. The fundamental issue is that the overwhelming majority of interactive websites today don't actually need to be interactive, and may even be better off as old-fashioned HTML pages served by the server. But people love over-complicating stuff, and when the end result is complex the toolchain has to be complex too, not just for one person but the whole team. Then you end up with developers wh…
I wish this "the web is over complicated" meme would die. The web at one point was only for hypertext. It is still fine for hypertext but it is now also an application platform and the browser a runtime and app container. Your solution to the JS ecosystem is to make news websites less interactive. I see why you long for simpler times but I don't see how that fixes things. For those of us who are building applications…
I'm not saying don't build applications. I'm saying web applications can be server-only and should not spill over into the client.
Again there are exceptions - things like control panels or consoles do benefit from being SPAs. But in a lot of cases there is also nothing wrong or insufficient or unsatisfactory (from a UX perspective) about clicking a link and having the server send you pre-rendered HTML. JavaScript can still be used as icing on the cake to enhance those interactions, such as by displaying a spinner on the submit button and disabling it once the user clicks it.
Earlier quoted context omitted.
That's exactly what it is. The fundamental issue is that the overwhelming majority of interactive websites today don't actually need to be interactive, and may even be better off as old-fashioned HTML pages served by the server. But people love over-complicating stuff, and when the end result is complex the toolchain has to be complex too, not just for one person but the whole team. Then you end up with developers wh…
In my experience, even conventional form interactions like a list view with mass actions can be impossible without Javascript, and then unwieldy without some sort of framework to keep the UI consistent and a pleasure to use for users.
The more time goes by the more I feel crazy for missing whatever would motivate people to use js for anything more than is strictly necessary. Single threaded server??? I mean come on man, I understand you don't need parallelism for a lot of use cases but even if that fits your situation why javascript? It can't be that hard using a different language. I refuse to believe that.
To me it seems that NodeJS solves a very specific problem; handling many simultaneous persistent network connections (i.e. websockets). I can't help thinking of NodeJS as fundamentally being a programmable socket server. I.e. its purpose is to solve a network problem, not a business logic problem.
The problem for me, when I work on large(r) apps that run in NodeJS, is that there is a certain "mental overhead" associated with it. NodeJS has this non-blocking IO, event driven architecture for a very specific reason which makes total sense when you solve IO problems (such as handling many simultaneous network connections) but this behaviour somehow seems to trickle down into business logic. With NodeJS I find myself writing non-blocking, event driven business logic because the environment in which my code runs dictates this. Somehow that doesn't make sense to me. To me business logic is inherently synchronous.
Now there are some really clever ways to compensate for this such as the Promise and with never versions of JavaScript there are even new language features to help battle what was originally known as the "callback soup". However, no matter how clever and admirable each of these features are, to me they seem to compensate for a fundamental problem in the run-time environment (NodeJS) that actually makes it not really suitable for anything CRUD and beyond.
Earlier quoted context omitted.
Sorry to say this, but this kind of statements don't really add anything to the discussion. _Only a sith deals in absolutes_. Recently, JavaScript has adopted lot of language feature from C#, Ruby etc., that make it really useful for most common tasks. And the community moves really really fast, hence adoption of new language syntax is quite fast. JavaScript has some killer platforms / apps, that are being used in pr…
It's not the technology surrounding the language, it's more of how the core language itself is flawed.
Earlier quoted context omitted.
> If you're better with screwdrivers, why struggle with a hammer? Hammers and screwdrivers are not general purpose tools in the way that languages are. For most things, most languages are just as fine. It's not like JS is specialized in some very small niche by design -- like e.g. COBOL is. > JavaScript has a painfully slow runtime. I call BS. v8 is one of the fastest dynamic runtimes, at 2x of C or so for lots of ta…
> It's not like JS is specialized in some very small niche by design -- like e.g. COBOL is. Uhh, what? You don't consider "programatically manipulate the DOM in the browser" to be a niche?
Anything it does related to that is just simple library code and methods on the "document", "element", etc objects -- and that's only when run in the browser where those are available (automatically "imported" let's say). Node doesn't even have the "document" object.
Earlier quoted context omitted.
Accessing the DOM is not really part of the language specification, but the browser API, no?
And the "Browser API" was invented to do what, exactly? And by what mechanism was said API exposed to developers? And whose cocktail napkin was the specification written on?
Whatever it was inveted to do is totally irrelevant, as the "browser API" is not Javascript the language/syntax but just an API (library/module).
In fact you could trivially implement it in all kinds of programming languages.