41–50 of 335 posts
People are using it for applications too. Many websites are a combination of both:
A "frame" with navigational headers etc (application). And a document-view. This document view is what html was indented for.
The solution is to use this flex-box (which is simply tsacklayouts etc) for the application, and the document-flow for text.
edit: oh, and drop the javascripts
If it was up to facebook then react would be the only framework used on the web; problem solved right? In reality, there are different tools for different needs and if you don't understand the specific problems a tool was made to solve then of course you're going to find it confusing.
Just because a tool exists doesn't mean you have to use it. These tools were created to solve specific problems that the creators encountered, if you don't have that problem or don't like the solution then why did you pick the tool?
The most baffling part is the strange sense of entitlement as if people releasing their work for free on the internet is a burden to some because now they have to decide if they should use this free option.
If you want ES6, typescript, flow, components, css modules, SSR, hot code reloading, "universal" code re-use, postcss, bundling, automatic-code splitting, dead code elimination blah blah blah then that's on YOU. Don't blame the tools because you are enticed by their capabilities but not willing to understand why and how they work. If you don't care about that stuff then problem solved: don't bother with them.
Maybe somewhat related: can anybody guess what the idea behind the images in this article is? trans.gif is just a 1x1px invisible pixel.
Maybe somewhat related: can anybody guess what the idea behind the images in this article is? trans.gif is just a 1x1px invisible pixel.
Tracking scripts don't need to do anything but read the hit in the access log. That said, it's also trivially easy to output the bytes for a 1x1 invisible gif as the response from your tracking endpoint.
Choice quotes: > Directness is best in my experience, so a great photo, memorable illustration, or pitch-perfect sentence does most of the work. Beyond that, fancy implementation has never moved the needle much for my clients. > Last month, I had to install a package manager to install a package manager. ... I sure as hell know about spaghetti workflows and spaghetti toolchains. It feels like we’re there now on the w…
If I want to install Pip, Maven or what-have-you, I'd be using apt.
I completely share the thoughts of the author of this article. However, I'm not sure if his proposed solution would work for most people. It's not that I want or like to use npm etc. - I'm forced to use them as it's the new default way of working with almost anything useful in today's web development work. An alternative would be to start from scratch - and then reinventing all these things again, making another full…
I disagree with the often-heard premise that HTML is a somehow inferior tool for creating GUIs that we somehow ended up with despite better choices beings available. Yes, native GUI frameworks and widget toolkits like Swing, Qt, Cocoa and MFC have their place but it's precisely the nature and features of HTML (most notably: The link) that enabled most of the innovation we've seen on the web. If building web apps was…
Pick a book on GUI interfaces of the 80ies (for example: Computers Graphics by Foley & al), and see that pretty much all UI paradigms themselves were pretty much explored back then. The concept of the "hypercard" was already there.
HTML just improved on the presentation of it, often worsening everything else. Somehow web apps lowered the expectations of what a computer /should/ do so much that usability itself became an afterthought.
Some of the best designed apps on the web mostly ditch the DOM and layout everything in JS. Hardly "innovative".
This is my experience of web development, every time I return to it. I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered. JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don’t know much about programming language design, so they can’t see how bad it is, and they make matters w…
I didn't find JS any worse than Java, PHP or Python. They all have really ugly parts at least in JS they don't slow you down.
Earlier quoted context omitted.
I'm in a similar position, and I've formed the same impression. Furthermore, even though browsers are stuck with JS, given the influx of languages able to compile to JS (or even WebAssembly now) it feels like there should be plenty of options for those of us who would rather stay away from the craziness. Perhaps someone with more frontend experience could comment on what (comparatively) sane, simple and JS-minimizing…
Compiling-to-JS brings in its own set of crazy, and really almost never is worth it. In fact, the only two that make any sense are Babel and TypeScript, and that is only because are (practically) Javascript and because they are stable and widely used projects. If those two wouldn't hold, you'll quickly be running into a whole host of problems w.r.t. interoperability with the rest of the ecosystem, and you'll end up r…
I assume web assembly will bring sanity to the frontend PL world, which will be a step forward.
This is my experience of web development, every time I return to it. I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered. JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don’t know much about programming language design, so they can’t see how bad it is, and they make matters w…
I'm in a similar position, and I've formed the same impression. Furthermore, even though browsers are stuck with JS, given the influx of languages able to compile to JS (or even WebAssembly now) it feels like there should be plenty of options for those of us who would rather stay away from the craziness. Perhaps someone with more frontend experience could comment on what (comparatively) sane, simple and JS-minimizing…