91–99 of 99 posts
Earlier quoted context omitted.
I've seen people change Java code in production to fix a bug and recompile it. This is hardly a behavior that exists only in dynamic languages.
That's a different issue entirely. The article is talking about the quality of frameworks and libraries in JS.
Earlier quoted context omitted.
> Next, the dynamic nature of JavaScript is to blame. You can't easily extract and compile just the functions you need. Definitely check out rollup, if you haven't heard of it. We (the JavaScript community) are working towards solving this!
Thanks for the tip, rollup looks really powerful. This and related comments remind me that the latest ECMA stuff offers a brighter future. The challenge is getting there... Can/will jQuery work with rollup and all the other new module work? Or does it have to be effectively rewritten?
Earlier quoted context omitted.
Agreed. Transpilers are saving you nerves initially at the expense of making you want to commit suicide later. Like when you need to debug in real time, or check underlying "native" objects, or when a library the transpiler is relying on has a bug. IMO transpilers are a Faustian deal. That's what my experience has taught me, your mileage may vary of course.
I disagree. I have been developing an IONIC application with JSweet. My experience is that when I want to refactor the code (for example, just renaming the data objects because the customer changes its mind about how to name something), then you are happy to have JSweet and you can make the code up-to-date in no time. The more the application gets complex, the better it is to have a transpiler to help you update your…
But I am not here to argue specific examples. Sure, I definitely agree with you that Javascript is the worst offender in the transpiler world. I do however not see the connection between using a transpiler and having it easy when refactoring. If you mean that the transpiled language has an easier to parse AST and is thus much more prone to automated refactoring (Eclipse's "Rename Method" for example), I won't argue that; I know it can be true.
Nothing of what I said will stop me from trying Elm (transpiled to JS) for a hobby project though.
There is another upside to modules being easy to make and publish - they are also easy to change. The query parser you want isn't able to handle nested objects and arrays easily - fork it, add your small piece of code (to what is hopefully an already small module), use it with a direct reference in your package.json, send a pull request upstream. The fact that libraries don't handle your specific edge case/ special n…
Js has fragmentation but what do you expect with the largest repo of packages?
Earlier quoted context omitted.
I disagree. I have been developing an IONIC application with JSweet. My experience is that when I want to refactor the code (for example, just renaming the data objects because the customer changes its mind about how to name something), then you are happy to have JSweet and you can make the code up-to-date in no time. The more the application gets complex, the better it is to have a transpiler to help you update your…
I know nothing about JSweet but I have a 7-8 years of Java background and I can tell you right now that nothing in the Java world is a magic bullet. But I am not here to argue specific examples. Sure, I definitely agree with you that Javascript is the worst offender in the transpiler world. I do however not see the connection between using a transpiler and having it easy when refactoring. If you mean that the transpi…
I think that Christian Maioli Mackeprang is right. Some languages focus on instant productivity. They are really good and powerful to sketch a program in a few lines of code. But this quality comes at the expense of other important features that are really important for a language/development environment. People need to consider this or we will end up with poor programming environments and languages that are great for prototyping, but that don't scale up for complexity...
Earlier quoted context omitted.
No by URL I meant the URL of the service that would provide the autocomplete or the validation. Like:
I'm not sure how either of these would help: - validation: Fundamentally, to be able to trust the input, the server needs to validate it in its final state. The only reason validation should be done on the client is to reduce the latency from the time the user inputs the data to the time the validation result is reported, so the user can fix their input faster if it fails validation. Sending it to a URL before form s…
And client side validation is not a substitute for server side validation, merely a better UX.
Earlier quoted context omitted.
I think it's rather that the java and .net framework are pretty good out of the box. So there is only a need for additional framework for certain corner cases. And then some get bought by Microsoft and integrated out of the box, like the datavisualization libraries or xamarin. JavaScript on the other side is a language that only its conceptor could love. All these frameworks are sort of required to be barely producti…
Javascript has a terrible embarrassment of a standard library. Things that should just be baked into the language are not, which has lead to attempts to rectify that shortcoming, like jQuery, Underscore and LoDash. Because this standard library isn't implemented in the browser itself, where it belongs, people have gotten upset about downloading a few hundred kbs of a general purpose utility library, and instead reimp…
Of course, its not exhaustive by any means. But your general everyday stuff is covered.
One factor that leads to fragmentation is this "theme" that I seem to see over and over that when a project is popular the creator gets to be the github maintainer and take credit for it's success as a large and popular project, which by itself is a good thing. The bad part is that when the maintainers make unpopular decisions like disabling all functionality by default and relying on submodules, or not wanting to fi…
I blame Github, in particular its "stars" feature. It makes putting out code a popularity contest. "Why should I make someone else's project more popular? I'd rather spend my free time making myself popular."
If you like someone else's code and it has helped you out in a difficult situation, why won't you star that project ? Sure, you can choose to spend your free time in whatever way you feel like. But I think contributing to other repos, fixing bugs is what the community is all about.