311–320 of 356 posts
Earlier quoted context omitted.
Sure, you may well end up writing one, but it's likely to be a fraction of the size. My current entire app is running at half the size of jquery, which is getting me awesomely quick page loads even on poor mobile connections. The dev time was longer, but not crazily longer, and the surface area for testing is somewhat smaller
In reality JavaScript size means very little when a single image might be 500k.
I still remember doing a PoC for an end-to-end secure messaging app with web support, around 3 years back. It was written in plain JS with jquery and one or two libs for crypto bolted on. Simple, easy, but not very maintenance friendly written. Took around 2000 lines all in all. One of four clients (Android, iOS and a bot framework in Scala/Java). Then the web-boys came in to rewrite my... well, contraption. In came…
> The web-boys however, didn't understand asynchronous messaging, cryptography and eventual consistency very well Would it be fair to say you didn't understand the web frameworks very well? I'm not sure that lines of code is a great measure here. What about test coverage? Maintainability? NPM is a package manager - anyone would advocate using that over manual dependency management, no matter what environment you're p…
This is precisely the kind of generalisation that many experienced developers will rightly object to.
There is absolutely nothing unreasonable about manually downloading a specific version of a small number of self-contained libraries, and just using them either directly or integrated into some sort of bundling process. This has significant advantages in terms of simplicity, reliability, and transparency compared to the who-knows-what that NPM and its ecosystem will generate only to achieve the same end result.
You only really need to use NPM if you're working with lots of small packages and/or packages that have many small dependencies of their own, but either way, now you have two problems.
Earlier quoted context omitted.
A counter-point to your argument: In-house coding standards smells a little bit of NIH syndrome. Odds are good that even if you are not a "young, inexperienced" developer, widely-adopted coding standards (that most frameworks probably use) have had more thought and reasoning put into them than you would ever be able to do on your own. So I agree with your overall point of "don't just blindly adopt something", but the…
> naively doing everything your own personal way (including at the team/company level). You, and my downvoters, all assume (naively) that any in-house standard must somehow be different than "widely-adopted coding standards (that most frameworks probably use)". Obviously, that need not be true, and in my limited 40 years of experience, it rarely is. Not sure how you even got there.
If you were implying that those two things might be identical then you did a bad job of conveying that (and then why even comment?)
Earlier quoted context omitted.
> The web-boys however, didn't understand asynchronous messaging, cryptography and eventual consistency very well Would it be fair to say you didn't understand the web frameworks very well? I'm not sure that lines of code is a great measure here. What about test coverage? Maintainability? NPM is a package manager - anyone would advocate using that over manual dependency management, no matter what environment you're p…
Lines of code can be a very good measure. You can have an app that is small and easy to fit into the mental model. Or you can wrap it up in huges framework and get lost between the abstractions. We have a saying to shoot sparrows from the cannon, and often using web frameworks looks like doing exactly this: you take trivial case and make it complex just because it is implied that frameworks are necessarey. Doing that…
?! What web frameworks kill accessibility, exactly?
Earlier quoted context omitted.
> but at the end of the day if your page is >1mb I'm probably not going to wait for it to load Average size for the most popular sites has actually grown to ~ 2.5-3MB. And since they're the most popular, it shows that people DO wait just fine for them to load.
Switch "most popular" to "your site" and it will probably change user's desire to wait for it.
Also what I left out in my argument is that while popular already, they still might get increased in traffic if they were lighter.
Earlier quoted context omitted.
> "They did invest lots of time to learn about all those tools and libraries" Unfortunately that claim doesn't hold up to what I suspect is happening most of the time. At least in my experience at work I've seen tech leads or someone similar introduce frameworks without so much as "apparently it's quite good, so let's use it". One case in particular, Angular was chosen and turned out not to be suitable - it ran very…
"At least in my experience at work I've seen tech leads or someone similar introduce frameworks without so much as "apparently it's quite good, so let's use it"." I completely agree. Web people quite often commit to frameworks based on their marketing copy and maybe one guy they read on the internet saying "seems pretty AWESOME after I've played with it for two days!" and a testimonial or two. Of course, I've seen de…
It isn't just a web thing, but it is way worse in the web world. How many of the cases you described were for web shops?
Earlier quoted context omitted.
How does a LAMP/RAILS app share server side rendering code with the client? It doesn't, because I don't need/want it to. Any data that needs to be passed to the client is rendered as JSON. Client-side get committed to the database via AJAX (to my buzzword-o-rific REST api), or with good-ol' POST. How does a LAMP/RAILS app share data models between the server and client? Again, not needed. How does a LAMP/RAILS app pr…
We didn't collectively decide to move rendering to the client side for no reason. It is unquestionably more complex to build a SPA than to have a traditional web app. We did it because users demand it. A SPA feels substantially faster and more reactive. Users notice. If Gmail used your approach, it never would have succeeded. > How does a LAMP/RAILS app provide search engines with indexable dynamic pages? Uh, through…
You don't need one, but if you don't eventually adopt one, you'll end up writing one.
Earlier quoted context omitted.
> The web-boys however, didn't understand asynchronous messaging, cryptography and eventual consistency very well Would it be fair to say you didn't understand the web frameworks very well? I'm not sure that lines of code is a great measure here. What about test coverage? Maintainability? NPM is a package manager - anyone would advocate using that over manual dependency management, no matter what environment you're p…
NPM is a package manager - anyone would advocate using that over manual dependency management, no matter what environment you're programming in. This is precisely the kind of generalisation that many experienced developers will rightly object to. There is absolutely nothing unreasonable about manually downloading a specific version of a small number of self-contained libraries, and just using them either directly or…
I'll probably do that in my "utility" library to keep my actual application project as light as possible. But I'm not going to add a dependency for 4 lines of code, as much as I may appreciate the effort you took in providing them. See https://github.com/btomala/akka-http-twirl/blob/master/src/m... for a recent example.
Earlier quoted context omitted.
I'd like to correct some misconceptions you seem to have regarding React. > unless you are using React in a javascript runtime, in which case you're probably fine React is written in JavaScript. It runs exclusively in JavaScript. If you've somehow managed to run it outside a JavaScript runtime then I'd actually be delighted to learn about how. > all I really give a shit about is its shadow DOM implementation React do…
Well, react-rails is how. And it's messy as hell.